Debian GNU/Linux スレッド Ver.103

公式サイト
https://www.debian.org/sitemap

前スレ
Debian GNU/Linux スレッド Ver.102
https://mao.5ch.net/test/read.cgi/linux/1744820527/

むしろ更新が少なくてデスクトップでも快適

>>418
Testingもそこまで新しくないじゃろ！

RHELもUbuntuもCopy Fail対策のカーネルパッチまだ出てないのにTrixieは即効出た
Debian早い
Debian偉い

distrowatchのページビューで戦闘力主張してきたキチガイ民党のスメルを感じた

うむ
更新した

RHEL は出してるよ
https://access.redhat.com/solutions/7141931

>>422
Testing/forkyは先週から先週にかけてPlasma-6.6.3が降ってきたくらいの遅さですね
それまで6.5.4だったかな
さっきspacebar-6.6.4が降ってきたからそのうち全体も6.6.4に上がりそう

>>423
bookwormはまだのようです

>>423
ふーむ🤔

>>420
見づらい分かりづらい使いづらい

FOSSならLemmyだよなあ

Linux - Lemmy.World
https://lemmy.world/c/linux

たいてい半日〜1日でどのディストリもクリティカルなパッチだったら降ってくる
多少のズレは誤差じゃね

早ければ早いほど他に手を回せてるとは思う
ある種のバロメーターやな

大本のパッチがあたるのが3〜4時間後、そこからメンテナが気がついて対応するまでの時間でしょ
1日内なら遅くも無いと思うが
どこも潤沢な予算や人員確保してるわけでもないのだからこんなもんで上等じゃないの

>>419
けっこう多くてびっくり！

>>435
Debianが?
ラズパイでしょ

デスクトップ環境 Vote数 (パッケージ)
Sugar 2 (suger-session)
FVWM-Crystal 16 (fvwm-crystal)
Budgie 85 (badgie-core)
Enlightenment 107 (enlightenment)
LXQt 2073 (lxqt-session)
LXDE 2514 (lxpanel)
Cinnamon 8629 (cinnamon-desktop-data)
MATE 9262 (mate-settings-daemon-common)
Xfce 23928 (xfconf)
KDE Plasma 29634 (plasma-workspace)
GNOME 57587 (gnome-desktop3-data)

Debian Popularity Contest ( popcon.debian.org ) に参加している端末の統計から
Debian以外も含むがほぼDebian
実数はこの倍か

https://popcon.debian.org/by_vote

ウィンドウマネージャ Vote数 (パッケージ名)
UWM 1 (uwm)
aewm++ 3 (aewm++)
MIWM 3 (miwm)
w9wm 3 (w9wm)
9wm 4 (9wm)
wm2 6 (wm2)
VTWM 7 (vtwm)
FLWM 8 (flwm)
LWM 9 (lwm)
CWM 11 (cwm)
Blackbox 21 (blackbox)
sawfish 42 (sawfish)
ratpoison 47 (ratpoison)
dwm 51 (dwm)
JWM 54 (jwm)
Twm 75 (twm)
niri 79 (niri)
Hyprland 90 (hyprland)
Enlightenment 107 (enlightenment)
xmonad 134 (xmonad)
Labwc 184 (labwc)
Window Maker 193 (wmaker)
FVWM 253
IceWM 283 (icewm)
Fluxbox 347 (fluxbox)
Awesome 425 (awesome)
Sway 1068 (sway)
i3 1843 (i3-wm)
Openbox 5381 (openbox)

おまけ

>>436
ラズパイがそんなに多いわけがない

arch
何がいいのん?
>>435

Archの派生のForumやwikiで情報が分かりやすいからArch wikiを使うなら、そのままArchでいいやになった

this includes security fixes for CVE-2026-31431

patched kernels are: 5.10.254+, 5.15.204+, 6.1.170+, 6.6.137+, 6.12.85+, 6.18.22+, 6.19.12+, 7.0-rc7+

archはsteam deckで採用されてるから伸びてるだけ
Linuxディストリのプレインストール機をMSが妨害してる理由がそれ
売れたら支配がとけちゃうから

Valveはローリングリリースのディストリが欲しかったのか知らんけど
個人利用ならdebianでいいや楽だし

何がいいかはArch使ったらわかるYO!

https://imgur.com/wEkZScP.jpg
https://imgur.com/qgLh1fT.jpg

Archユーザーはattention seeking kid
うざいガキ
キモいヲタク

>>444
ディストリビューションをうまくまとめているなｗ
ここじゃなくて、オススメLinuxディストリビューションスレに書いた方が良かったのに

左下の人ストールマン？

>>444
gNewSenseが亡くなって、後釜はTrisquel OSとGNU Guixか
赤眼鏡の人は何なの？ｗ

>>444
gNewSenseが亡くなって、後釜はTrisquel OSとGNU Guixか
赤眼鏡の人は何なの？ｗ

古いmemeやな
俺はこれに騙されてウブンチュから入った

arch使ったことあるけど
これは"使わないほうがいいやつだ"と直感した

Linux界隈の入口はMintとDebianの2強

でたなミント厨
お呼びじゃない

いやDebian信者ですが

ミントはLMDEがあるから実質的な子分

Debianも入り口になれるか
いいことだ
Snapが無いだけLinux MintはUbuntuよりマシ

https://imgur.com/a/8qjznQA

マカー憤死

マカー憤死勢はMSの工作員だと思ってる
実際にはUnix Linuxのいい宣伝塔

味方はGNU Hurdだけ
他に挙げるならBSDと…ReactOS？

>>445

まんねり工作員、臭すぎ

バトルはじめるのは全員工作員

いや臭いのが工作員

Win11上のvmware workstatinで動かしてるbookwormをtrixieにアップグレードしたんだが、
起動diakが見つからないで立ち上がらない。
まあvmwareだがらすぐ元に戻せんるんだけど。
もうdebian卒業しようかな。

# update-grub
だけで治るような

>>464
update-grubやっても結果は同じ

どこで止まるのか知らんけど
grub自体が稼働しないなら
# grub-install
も必要かもしれない

grubが稼働するけどカーネルが見つからないのなら
# update-grub
が必要

カーネル稼働するけど初期ルートファイルシステムが
見つからないなら
# uodate-initramfs
が必要そう

# update-initramfs
ね、正しくは

あんまり疑いたくないけど
リリースノート読んでそれに従って
アップグレードしましたか？
https://www.debian.org/releases/stable/release-notes/index.ja.html

apt のリポジトリ元の設定を書換えて
# apt update
# apt upgrade --without-new-pkgs
# apt full-upgrade
だけで以前の個別コマンドが全て不要なはずなんだけど…

>>60
古いpcのbiosに残るバグをosが見つけたと言う意味らしい

vmで使うくらいなら別にwin11でええやん
めんどくせえ

>>468
それと同じコマンドでうpしたんだが。
rebootするとこうなる。
https://tadaup.jp/5VlwPRvh.jpg

not exsistて言ってるDISKはdebianの/のパーティションで、そのパーティションしかない。
reboot直前にUUIDみてもそのIDのままなんだが。

ｸﾘｰﾝ(…以下略)

カーネルとinitramfsがアップデートできたことを確認しました？
以前似たようなことが起きたときは自動ドライバビルドに問題があってそれが原因だった。
ほかには/bootが溢れたりとかもした覚えが。

gamescopeのビルドに成功したけど、これすごいな。

>>471
まさか今時Legacyブートじゃないんだろう？
UEFIにDebian表示してるの？

chrootで直せるかも知れないけど
この世に一つしか存在しないオレオレtrixieになって
今後訳分からない潜在的な副作用が出る可能性があるかも知れないｗ
13が使えるようになって欲しいだけならｸﾘｰﾝｲﾝｽﾄｰﾙが良いような

絶対に12→13アップグレードする任務が課せられてるならともかく

How to recover Manjaro's GRUB
https://en.linuxadictos.com/como-recuperar-el-grub-de-manjaro-explicado-por-el-bot-del-canal-oficial-de-telegram-del-proyecto-en-espanol.html

Debianのchrootは知らん

一番気になるのは/パーティションしかないそうで
UEFIだと/boot/efi にマウントするはずのEFIパーティションの存在
旧BIOS仕様の仮想マシン？

trixiインストーラーで起動して修復機能がないかな？
あるいは全部手でやるなら
上記のtrixiインストーラーでシェルを起動
/recoveryroot/
とかマウントポイント作ってそちらに復旧対象のパーティションマウント
chroot /recoveryroot
したうえで復旧できるはずだが

がんばって

debianかubuntuのlivecdでいいだろ。個人的にはarchのインストーラがリカバリには便利だと思うけど。
arch-chrootでrunやらsysやらも一発でマウントできるので。ちなみに、arch-chrootスクリプト自体はdebianのリポジトリにもある。

やっぱり教えない

教えて！

はい

>>286修正されたっぽいまじ感謝

mpv勝手に閉じなくなったな最近
これは進化だ
build from sourceのばやいです

>>477
もう15年前に初期インストールしたやつをうpし続けてきたのでBIOS仕様かも。
そろそろクリーンインスコかな。

それが原因でかつ仮想マシン仕様なら
なおさらクリーンインストール不要
https://www.debian.org/releases/trixie/amd64/ch03s06.ja.html

新ディスク作成してEFIパーティションを加えた必要パーティションの作成
システムデータの新ディスクへのコピー
EFIパーティションへのgrubインストール

これらはバックアップからの新ディスクへの書き戻しと同じなので
知っておいて無駄のない操作

463だけど、trixieにアップできた。
原因はlinuxカーネルが古かった。
アップする前のapt upgradeでlinux-image-amd64が保留になってたので、これをうpしてからやったら
trixieにアップできた。linux-image-4.x.-amd64が入っていた。

trixieにアップできたんだが、
立ち上げ時にdiskのマウント失敗して止まる。
░ The unit mnt2.mount has entered the 'failed' state with result 'exit-code'.
5月 06 10:03:03 tamajimu systemd[1]: Failed to mount mnt2.mount - /mnt2.

fstabからコメントで消すと起動できる。
fstabのコメントを外してrebootすると、1回目は起動成功するが、2回目は起動失敗する。
mountコマンドでマウントするとマウントできるのだが。

起動が成功するfstab
UUID=7385b4f3-dc92-4e23-b4c1-6572edf97db8 / ext4 errors=remount-ro 0 1
UUID=a72e6489-6bda-4d23-8625-a7fb6d39ef00 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
#/dev/sdb1 /mnt3 ext3 errors=remount-ro 0 0
#/dev/sdc1 /mnt2 ext4 errors=remount-ro 0 0
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,auto_unmount,defaults 0 0

良かったな。おめでとう

>>486
udev絡みなんじゃないかな
もしかするとsystemdも

/dev/disk/by-uuid/見てUUID指定でfstab記述しても駄目?

>>488
UUID=7385b4f3-dc92-4e23-b4c1-6572edf97db8 / ext4 errors=remount-ro 0 1
でマウントしてるのに、
lrwxrwxrwx 1 root root 10 5月 6 17:27 1579899d-c51f-4328-9aa9-72d4acea7621 -> ../../sda1
lrwxrwxrwx 1 root root 10 5月 6 17:27 7385b4f3-dc92-4e23-b4c1-6572edf97db8 -> ../../sdb1
lrwxrwxrwx 1 root root 10 5月 6 17:27 a72e6489-6bda-4d23-8625-a7fb6d39ef00 -> ../../sdb5
となる。
sdb1を外して起動すると
lrwxrwxrwx 1 root root 10 5月 6 17:17 7385b4f3-dc92-4e23-b4c1-6572edf97db8 -> ../../sda1
lrwxrwxrwx 1 root root 10 5月 6 17:17 a72e6489-6bda-4d23-8625-a7fb6d39ef00 -> ../../sda5
となってUUIDて変わるんだな。
UUIDが変わってもsda1はなぜかマウントできる。


fstabをUUIDで書いても/devで書いても、/mnt2がマウントエラーになる。
fstabでマウントするのやめようかと思う。

sda sdb間で過去にddとかでパーティションコピーして
それでUUIDが重複しているパーティションがどこかに存在しておかしくなってるとか?

sda や sdb の区別はカーネル起動時の認識や通知の順序によるもので
同じ構成でも順序が変わるし、別の構成(別ディスクが増えている)などでは当然変わる
# 別のUSB SSDとか一時的に刺してあるだけで順序とか変わるので
https://wiki.archlinux.jp/index.php/永続的なブロックデバイスの命名
これらを嫌ってUUIDやファイルシステムに設定できるタグ名で一意に決めるように
移行状況にある

実際にUUID重複のようだね
両方のディスク(関係ディスク全部)を接続した状態で
uuidを表示してみれば明らか
# blkid
# lsblk
両方のコマンド実行結果を貼ってみなよ

根本的解決はgdiskでパーティション切り直しで一意なUUIDを付け直す必要がある
その場しのぎだとファイルシステムのタグ名で乗り切れるけど今後別の不具合でるかも

あるいは gparted あたりだと UUIDのみの書換えとかできそう

blkid 見れば分かるように各パーティションは
UUIDとPARTUUIDと2つ持っているはずなのでご注意を

# あんまりドキュメントとか読まずに
# 試行錯誤というかゆきあたりばったりで
# 乗り切っている様子が伝わってくる
# 正に秘伝のタレ状態
# よくわからないけど動いてますじゃ怖ぇーよ

そもそも仮想で使う馬鹿が悪い

/dev/sdXn(ext2〜4)のUUIDを再生成したければrootで
# umount /dev/sdXn
# fsck -f /dev/sdXn
# tune2fs -U random /dev/sdXn
だけで良いのでは？(他のファイルシステムなら他のコマンド)
そして、新しい正当なUUIDをfstabに指定

違ったらゴメンね

>>495
悪いのは老化だよ
15年前に初期インストールしたやつをうpし続けてきた(今回もup乗り切って大満足)
linux-image-4.x.-amd64が入っていた(カーネルアップもしない。今回upしたから大敗北)
老人になると劇頑固になりこんなことに必死にこだわる

ああ仮想の話か
よく読んでなかった

「linux-image-4.x.-amd64」
これをさらっと読み流していた
9 stretch
10 buster
のどっちかのカーネルで
trixie 13に一気に上げてきたと

そりゃ動きそうだけどさぁ

そんな化石なんに使ってたのやら

>>489
いや
/dev/sdb1 /mnt3 ext3 errors=remount-ro 0 0
/dev/sdc1 /mnt2 ext4 errors=remount-ro 0 0
をUUIDで指定したらって事
連番デバイス命名はもはやobsolete同然だよ
udev rulesで固定に出来るけど馬鹿馬鹿しいよ

>>501
root@tamajimu:/etc/apt# /sbin/blkid
/dev/sdb1: UUID="1579899d-c51f-4328-9aa9-72d4acea7621" SEC_TYPE="ext2" BLOCK_SIZE="4096" TYPE="ext3" PARTUUID="00018eed-01"
/dev/sda5: UUID="a72e6489-6bda-4d23-8625-a7fb6d39ef00" TYPE="swap" PARTUUID="5fb8ce0a-05"
/dev/sda1: UUID="7385b4f3-dc92-4e23-b4c1-6572edf97db8" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="5fb8ce0a-01"
root@tamajimu:/etc/apt# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 20G 0 disk
tqsda1 8:1 0 19.5G 0 part /
tqsda2 8:2 0 1K 0 part
mqsda5 8:5 0 510M 0 part [SWAP]
sdb 8:16 0 3G 0 disk
mqsdb1 8:17 0 3G 0 part
sr0 11:0 1 1024M 0 rom

root@tamajimu:/etc/apt# grep -v "^#" /etc/fstab
UUID=1579899d-c51f-4328-9aa9-72d4acea7621 / ext4 errors=remount-ro 0 1

UUID=a72e6489-6bda-4d23-8625-a7fb6d39ef00 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
UUID=7385b4f3-dc92-4e23-b4c1-6572edf97db8 /mnt2 ext3 errors=remount-ro 0 0
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,auto_unmount,defaults 0 0

>>501
rebootするとここで止まるので、/etc/fstabの/mnt2の行をコメントアウトしてrebootすると立ち上がる。

░░ The job identifier is 74.
5月 06 22:35:15 tamajimu mount[589]: mount: /mnt2: fsconfig() failed: /dev/sda1: Can't open blockdev.
5月 06 22:35:15 tamajimu mount[589]: dmesg(1) may have more information after failed mount system call.
5月 06 22:35:15 tamajimu systemd[1]: mnt2.mount: Mount process exited, code=exited, status=32/n/a
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An n/a= process belonging to unit mnt2.mount has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 32.
5月 06 22:35:15 tamajimu systemd[1]: mnt2.mount: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit mnt2.mount has entered the 'failed' state with result 'exit-code'.
5月 06 22:35:15 tamajimu systemd[1]: Failed to mount mnt2.mount - /mnt2.
░░ Subject: A start job for unit mnt2.mount has failed

というかUUIDが間違ってるな。
5chに書いてて気づいた。

でも17時のときは
lrwxrwxrwx 1 root root 10 5月 6 17:27 1579899d-c51f-4328-9aa9-72d4acea7621 -> ../../sda1
lrwxrwxrwx 1 root root 10 5月 6 17:27 7385b4f3-dc92-4e23-b4c1-6572edf97db8 -> ../../sdb1
だったのに。

root@tamajimu:/var/log# grep -v "^#" /etc/fstab
UUID=7385b4f3-dc92-4e23-b4c1-6572edf97db8 / ext4 errors=remount-ro 0 1
UUID=a72e6489-6bda-4d23-8625-a7fb6d39ef00 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
UUID=1579899d-c51f-4328-9aa9-72d4acea7621 /mnt2 ext3 errors=remount-ro 0 0
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,auto_unmount,defaults 0 0

でやっと何回rebootしてもOKになったわ。
スレ汚しすまそ

連番デバイス命名はブートごとに変わると思ってください
ネットデバイス名も最近のはデバイスユニークになるように長くなってる

セキュアブートを無効にすれば UUID なんて無視できるんじゃないの

UUID使わないなんて時代遅れです

使わないやり方忘れた

一意が保証できるなら、ラベルでもいける。
けど、大昔のSCSIのバスIDとかポート番号のようなもので指定する時代はとっくに終わってる。
ファイバーチャネルやiSCSIなんかは、簡単に経路が変わるようになってるからね

やはりその都度ジャンパピンでやらねばならぬか

現状態でOSアップグレード後問題起こりそうな部分をレポートするコマンド用意してあるんじゃないのか?
それで、例えば
fstabなら　/dev/** はダメぽUUIDにしなさいとか(実アップグレード時に自動変換もできるよ)
カーネルなら今の古すぎ、最低でもxxに上げないとダメぽ(あげれないないならOSアップグレード止めれ)

個人なら手動で修正でも良いが、今やLinuxデスクトップは企業等でいっぱい・普通に使われているから自動でやりたいよな
で、もう、AI当たり前時代だから、Debian提供のOSアップグレード事前レポート作成コマンドがDebianのAIとやり取りして
秘伝のたれ状態のものでもスムーズにOSアップグレードできるようにして欲しいよな
金のあるUbuntuのところはAI活用頑張る宣言したが...

つかAIに状況をちゃんと説明できればほぼ個人で解決できるだろ

コンピュータのプログラムやソフトウェアと呼ばずAIと呼ぶ基準とかあるの？言った者勝ち？

あいあい

AI は知恵遅れ

今AIと呼ばれてるものはLLMだからしゃーない
みんなが思い描くAIのAGIには直結しない別物

AGIは完全自律式自己成長型でしょ
2年でフリーズしてちまちま直してくDebianは実質AIのようなもん？

AIなら設定とかディストリの方針丸ごと汚れたdebianめっちゃ手入れるだろうなぁ

DirtyFrag対策済みのカーネル来てるよー

これか

CVE-2026-43284
https://security-tracker.debian.org/tracker/CVE-2026-43284

CVE-2026-43500
https://security-tracker.debian.org/tracker/CVE-2026-43500