Hallo
Seit einigen Tagen schlage ich mich mit einem Problem beim booten herum.
Wenn systemd meine /home partition mounten will, kommt die Fehlermeldung :
Timed out waiting for device dev-disk-by\x2duuid-c57a4047\x2d41bf\x2d484b\x2da3e9\x2de81ed50534f6.device.
-- Subject: Unit dev-disk-by\x2duuid-c57a4047\x2d41bf\x2d484b\x2da3e9\x2de81ed50534f6.device has failed
Dasselbe für meine /home/opt partition und für swap.
Ich lande im emergency mode. Gebe ich dort strg+d ein, bootet der Rechner normal weiter und alle partitionen sind dann gemounted.
Ich finde einfach keine Lösung warum das passiert.
hier ist die Ausgabe von journalctl -b -p 3
-- Logs begin at So 2014-12-07 20:15:58 CET, end at So 2016-06-26 09:17:01 CEST. --
Jun 26 08:24:57 box systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-c57a4047\x2d41bf\x2d484b\x2da3e9\x2de81ed50534f6.device.
Jun 26 08:24:57 box systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-6d240a14\x2d9a87\x2d4b93\x2d9b4b\x2d6458a7f0ebaa.device.
Jun 26 08:24:57 box systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-33e7d251\x2df2c4\x2d4bb8\x2dbfba\x2d072b3300dd91.device.
Jun 26 08:25:02 box systemd[321]: emergency.service: Failed at step EXEC spawning /bin/plymouth: No such file or directory
Jun 26 08:25:25 box ntpd[1006]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jun 26 08:25:25 box ntpd[1006]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jun 26 08:25:26 box ntpd[1006]: error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jun 26 08:25:27 box ntpd[1006]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jun 26 08:25:30 box ntpd[1006]: bind(23) AF_INET6 fe80::216:76ff:febc:c9e5%2#123 flags 0x11 failed: Cannot assign requested address
Jun 26 08:25:30 box ntpd[1006]: unable to create socket on eth0 (4) for fe80::216:76ff:febc:c9e5%2#123
Jun 26 08:26:19 box pulseaudio[2220]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible caus$
hier ist lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 ext4 Debian 4ea712e1-25a7-4749-bbe9-0e6bb80b81d0 /
├─sda3 ext4 Home 6d240a14-9a87-4b93-9b4b-6458a7f0ebaa /home
├─sda4 ext4 Opt 33e7d251-f2c4-4bb8-bfba-072b3300dd91 /home/opt
└─sda5 swap Swap c57a4047-41bf-484b-a3e9-e81ed50534f6 [SWAP]
sr0
und hier meine fstab
UUID=4ea712e1-25a7-4749-bbe9-0e6bb80b81d0 / ext4 defaults,noatime,errors=remount-ro 0 1
UUID=6d240a14-9a87-4b93-9b4b-6458a7f0ebaa /home ext4 defaults,noatime,x-systemd.device-timeout=5s,errors=remount-ro 0 2
UUID=33e7d251-f2c4-4bb8-bfba-072b3300dd91 /home/opt ext4 defaults,noatime,x-systemd.device-timeout=5s,errors=remount-ro 0 2
UUID=c57a4047-41bf-484b-a3e9-e81ed50534f6 none swap x-systemd.device-timeout=5s,ssw 0 0
das x-systemd.device-timeout=5s habe ich eingefügt um die 1min30sec Wartezeit zu umgehen.
mein system ist:
System: Host: box Kernel: 4.4.7-rt16 x86_64 (64 bit gcc: 5.4.0) Desktop: Cinnamon 3.0.4 (Gtk 3.20.6)
Distro: siduction 14.1.0 Indian Summer - cinnamon - (201411230307)
Machine: Mobo: Intel model: DG965MQ v: AAD37419-302
Bios: Intel v: MQ96510J.86A.1250.2006.1005.1532 date: 10/05/2006
CPU: Quad core Intel Core2 Quad Q6600 (-MCP-) cache: 4096 KB
flags: (lm nx sse sse2 sse3 ssse3 vmx) bmips: 19200
clock speeds: max: 2394 MHz 1: 2394 MHz 2: 2394 MHz 3: 2394 MHz 4: 2394 MHz
Graphics: Card: NVIDIA GT216 [GeForce GT 220] bus-ID: 01:00.0
Display Server: X.Org 1.18.3 drivers: nouveau (unloaded: fbdev,vesa) Resolution: 1600x900@60.00hz
GLX Renderer: Gallium 0.4 on NVA5 GLX Version: 3.0 Mesa 11.2.2 Direct Rendering: Yes
Network: Card: Intel 82566DC Gigabit Network Connection driver: e1000e v: 3.2.6-k port: 40c0 bus-ID: 00:19.0
IF: eth0 state: up speed: 100 Mbps duplex: full mac: 00:16:76:bc:c9:e5
Drives: HDD Total Size: 164.7GB (53.5% used) ID-1: model: HDT722516DLA380
Info: Processes: 220 Uptime: 44 min Memory: 1023.0/3893.1MB Init: systemd runlevel: 5 Gcc sys: 5.4.0
Client: Shell (bash 4.3.461) inxi: 2.3.0
dist-upgrade gestern, der kernel hat CONFIG_FHANDLE =y gesetzt. Das selbe Problem tritt auch mit dem 4.4.5-towo.1-siduction-amd64 kernel auf.
Wenn ich /home, /home/opt und swap in der fstab auskommentiere, bootet der Rechner ganz normal, allerdings kann ich mich dann nur als root einloggen.
Für hinweise die zur Ergreifung das schuldigen führen können, wäre ich dankbar.
Ich kann dir zwar nicht helfen, aber ich hab seit dem systemd-update von gestern oder so auch heftig Probleme beim runterfahren. Da rassselts nur von Fehlermeldungen dieser Art. Meine Lukspartition wird nicht ordnungsgemäss geschlossen weil systemd das vor dem umount gern erledigen will. Muss aber dazu sagen das ich zfs als rootfs habe. Fakt ist aber das die Probleme mit dem letzten systemd-update gekommen sind.
...
I have no problems, I also don't use a separate /home, /home/opt and it is why I don't use them ... usually problems.
The only thing I have in /opt is firefox & thunderbird nightly's and wine-devel (which installs to that location as default)
Pretty simple basic setup
#Entry for /dev/sda3 :
UUID=83b72a7d-057d-451f-8cbc-27ec1519752d / ext4 defaults,relatime,errors=remount-ro 0 1
#Entry for /dev/sda10 :
UUID=b74a3410-bb7a-45cb-bfb8-21fccb3f9fb5 /disks/disk1part10 ext4 auto,users,rw,exec,relatime 0 0
#Entry for /dev/sda2 :
UUID=4182AD3F3349D507 /disks/disk1part2 ntfs-3g defaults,auto,users,locale=en_US.UTF-8 0 0
#Entry for /dev/sda5 :
UUID=1495E70670ADDCA3 /disks/disk1part5 ntfs-3g defaults,auto,users,locale=en_US.UTF-8 0 0
#Entry for /dev/sda6 :
UUID=b4885921-86d7-4f8e-ae2c-d15bd2db48fe /disks/disk1part6 ext4 auto,users,rw,exec,relatime 0 0
#Entry for /dev/sda7 :
UUID=48877323-265c-4860-8288-a05bde9679f4 /disks/disk1part7 ext4 auto,users,rw,exec,relatime 0 0
#Entry for /dev/sda8 :
UUID=11fed65c-ea36-4f41-898d-7c4e5c232ce7 /disks/disk1part8 ext4 auto,users,rw,exec,relatime 0 0
#Entry for /dev/sda9 :
UUID=c0c45e80-1ee3-462b-8ceb-32712c26db07 /disks/disk1part9 ext4 auto,users,rw,exec,relatime 0 0
#Entry for /dev/sdb1 :
UUID=192108a8-601e-4868-882d-97ad3042b5ee /disks/disk2part1 ext4 auto,users,rw,exec,relatime 0 0
#Entry for /dev/sdc1 :
UUID=0236d812-1bda-4b81-846a-19dff5d663b0 /disks/disk3part1 ext4 auto,users,rw,exec,relatime 0 0
#Entry for /dev/sda1 :
UUID=258e380d-f937-4179-89fa-ecd87628c789 none swap sw 0 0
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 swap 258e380d-f937-4179-89fa-ecd87628c789 [SWAP]
├─sda2 ntfs 4182AD3F3349D507 /disks/disk1part2
├─sda3 ext4 83b72a7d-057d-451f-8cbc-27ec1519752d /
├─sda4
├─sda5 ntfs 1495E70670ADDCA3 /disks/disk1part5
├─sda6 ext4 b4885921-86d7-4f8e-ae2c-d15bd2db48fe /disks/disk1part6
├─sda7 ext4 48877323-265c-4860-8288-a05bde9679f4 /disks/disk1part7
├─sda8 ext4 11fed65c-ea36-4f41-898d-7c4e5c232ce7 /disks/disk1part8
├─sda9 ext4 c0c45e80-1ee3-462b-8ceb-32712c26db07 /disks/disk1part9
└─sda10 ext4 b74a3410-bb7a-45cb-bfb8-21fccb3f9fb5 /disks/disk1part10
sdb
└─sdb1 ext4 192108a8-601e-4868-882d-97ad3042b5ee /disks/disk2part1
sdc
└─sdc1 ext4 0236d812-1bda-4b81-846a-19dff5d663b0 /disks/disk3part1
sr0
Hi Brummer,
probier mal die Partitionen per LABEL einzubinden, vielleicht hilft das.
LABEL=ROOT / ext4 defaults,relatime,errors=remount-ro 0 1
LABEL=HOME /home ext4 defaults,relatime,errors=remount-ro 0 2
Die musst natürlich mit tune2fs vorher setzen.
# tune2fs -L /dev/<device>
Ggf. würde ich alle betroffenen FS (nicht gemountet) einem fsck-Lauf unterziehen.
Zitat von: piper in 2016/06/26, 16:37:30
I have no problems, I also don't use a separate /home, /home/opt and it is why I don't use them ... usually problems.
This is the first time I've problems with that, and I use my /home /home/opt partitions +10 years across several installs.
Zitat von: bluelupo in 2016/06/26, 17:41:28
Hi Brummer,
probier mal die Partitionen per LABEL einzubinden, vielleicht hilft das.
Hab ich versucht, das ändert leider nichts.
Zitat von: bluelupo in 2016/06/26, 17:41:28
Ggf. würde ich alle betroffenen FS (nicht gemountet) einem fsck-Lauf unterziehen.
Auch das habe ich schon mehrfach gemacht, mit dem Ergebnis "no errors"
Wie gesagt, die Partitionen werden ja gemountet, und zwar wenn der boot Prozess in den emergency mode schaltet. Das wundert mich ein wenig. Das Problem ist so ungefähr vor 1-2 Wochen nach einem DU (ohne probleme) aufgetreten, genau weiß ich es leider nicht, da ich nicht so oft re-boote. (Üblicherweise vielleicht ein bis zwei mal im Monat.) Ich wollte dann einen Live-stick testen, da ist das Problem aufgetreten.
Hi brummer,
der Timeout beim Booten ist das Problem und deshalb auch der Emergency-Modus.
Jun 26 08:24:57 box systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-c57a4047\x2d41bf\x2d484b\x2da3e9\x2de81ed50534f6.device.
Jun 26 08:24:57 box systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-6d240a14\x2d9a87\x2d4b93\x2d9b4b\x2d6458a7f0ebaa.device.
Jun 26 08:24:57 box systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-33e7d251\x2df2c4\x2d4bb8\x2dbfba\x2d072b3300dd91.device.
Welche Werte hast du für DefaultTimeoutStartSec in der /etc/systemd/system.conf stehen
Bei sieht das so aus:
DefaultTimeoutStartSec=30s
Your "naming" is also failing
Try using UUID and the disks itself instead.
example:
UUID=b4885921-86d7-4f8e-ae2c-d15bd2db48fe /disks/disk1part6 ext4 auto,users,rw,exec,relatime 0 0
I dropped labels long time ago, sooner or later it led to problems, yes, I know, people have been doing it for decades, I avoid like the plague, use kiss. avoid future problems
Bei mir ist es Aus-kommentiert:
#DefaultTimeoutStartSec=90sAber, kurz getestet, wenn ich den wert auf 30s setze, und meine eintrage aus der fstab
x-systemd.device-timeout=5s entferne, muss ich eben 30sec warten, bis er in den emergency mode fällt. Ohne Änderung in der /etc/systemd/system.conf sinds 1min 30sec.
Ich verstehe nicht, warum das mounten beim booten schief-geht, dann aber im emergency mode sofort, ohne weiteres Zutun von mir, stattfindet.
Could you please explain what you mean, I didn't understand.
Zitat von: piper in 2016/06/26, 21:20:43
Try using UUID and the disks itself instead.
example:
UUID=b4885921-86d7-4f8e-ae2c-d15bd2db48fe /disks/disk1part6 ext4 auto,users,rw,exec,relatime 0 0
I dropped labels long time ago, sooner or later it led to problems, yes, I know, people have been doing it for decades, I avoid like the plague, use kiss. avoid future problems
I've no mountpoints under disks, the folder is empty.
Wie bluelupo schon sagte - vom Stick booten, die Dateisysteme sollten nicht gemounted sein, auf Fehler prüfen. systemd ist da sehr nörgelig.
Ist alles in Ordnung, dann die Filesysteme allesamt ausdokumentieren und der Reihe nach wieder rein nehmen - und das, wo es hängt fixen.
Hi Brummer,
kann es sein das /home und /home/opt USB-Devices sind?
Normalerweise macht die Option x-systemd.device-timeout nur Sinn bei einem Remote-FS (sprich NFS bzw. Samba). Lass bitte diese Option weg und trage für /home die nachfolgende Zeile ein (/home/opt erst mal inaktiv lassen)
UUID=6d240a14-9a87-4b93-9b4b-6458a7f0ebaa /home ext4 defaults,relatime,errors=remount-ro 0 2
Poste die Fehlermeldungen bitte wieder hier.
Hallo bluelupo
Vielen Dank für deine Hilfe, aber, das ändert leider nichts.
Den Eintrag x-systemd.device-timeout habe ich nur drin,weil ich nicht 1.30sec beim booten warten will, und auch nur fürs debuggen. Mit, oder ohne, das Ergebniss ist leider das selbe.
fsck habe ich mehrfach ausgeführt, ohne Fehler.
Vielleicht noch, alle meine partitionen liegen auf der selbem Festplatte.
Ich hatte die Hoffnung das es evtl. ein bug in systemd wäre, der hier bekannt ist, dem scheint nicht so. Folglich ist es ein locales Problem.
Ach so, der Ursprung ist, "a start job is running" . . . .
So, eine wirkliche Lösung für mein Problem habe ich nicht gefunden, aber einen work-around.
Zunächst habe ich für meine Partitionen ein nofail in der fstab eingetragen.
UUID=4ea712e1-25a7-4749-bbe9-0e6bb80b81d0 / ext4 defaults,noatime,errors=remount-ro 0 1
UUID=6d240a14-9a87-4b93-9b4b-6458a7f0ebaa /home ext4 defaults,nofail,noatime,x-systemd.device-timeout=5s,errors=remount-ro 0 2
UUID=33e7d251-f2c4-4bb8-bfba-072b3300dd91 /home/opt ext4 defaults,nofail,noatime,x-systemd.device-timeout=5s,errors=remount-ro 0 2
UUID=c57a4047-41bf-484b-a3e9-e81ed50534f6 none swap nofail,x-systemd.device-timeout=5s,ssw 0 0
dann habe ich einen systemd-service geschrieben:
# /etc/systemd/system/mount-user-configuration.service
[Unit]
Description=mount remaining filesystems
After=remote-fs.target
[Service]
ExecStart=/bin/mount -a
[Install]
WantedBy=systemd-udev-trigger.service
und diesen in systemd-udev-trigger.service als wonted eingetragen und aktiviert:
systemctl enable --now mount-user-configuration.service
schließlich musste ich noch denn systemd-udev-settle.service deaktivieren
systemctl mask systemd-udev-settle
un nu, bootet die kiste wieder durch.
Ich weiß, diese "Lösung" ist schmutzig, aber nichts anderes hat funktioniert.
Als wirklich gelöst kann ich diesen thread aber nicht markieren.
Dieser Thread ist uralt. Aber exakt das Gleiche tritt aktuell bei einem meiner Siductions (einer 32bit-Version) auf. Auch dieser Rechner ist schon sei mindestens 3 Monaten nicht rebootet worden, auch ich kann nicht sagen, seit wann das ist. Das Durchsuchen sämtlicher Logs bringt keine weiterführenden Infos, außer, das zwei Dateisysteme nicht gemounted werden können. Deswegen falle ich in den Recoverymodus, und wenn ich dort ohne Login einfach ctrl-d drücke, läuft alles.
Seltsam ist:
In der fstab sind drei Dateisysteme (alle auf der gleichen Platte)
/
/home
swap
(in der Reihenfolge).
Wenn ich mir die Bootmeldungen ansehe, meckert er bei /home und swap. Dokumentiere ich swap aus, meckert er bei / und /home.
Dokumentiere ich /home aus, meckert er bei / und swap. Kurzum: was auch immer ich ausdokumentiere: er meckert immer bei zwei Dateisystemen, mit einer Ausnahme: wenn ich /home und swap ausdokumentiere, gibt es keine Fehlermeldung und er bootet durch, aber logischerweise ohne Userlogin, da keine Homeverzeichnisse.
Wenn ich nur /home oder nur swap in der fstab habe, meckert er trotzdem bei zweien: bei / (obwohl nicht in der fstab) und "dem anderen".
Ich denke, wir haben das gleiche Problem. Daher würde es mich brennend interessieren, ob Du es zwischenzeitlich "sauber" lösen konntest.
LG
df8oe
Post your WHOLE fstab
also post your WHOLE output of blkid (as root)
Hi Piper,
as brummer has done I have of course tested every possible combination. Identified by UUID, identified using labels, and direct identifying with devices (/dev/sdaX). Nothing changes. I have rebuild initramfs - no changes. This is the wrong path - problem is located anywhere else.
Best regards
df8oe
Zitat von: df8oe in 2018/07/19, 17:44:06
Ich denke, wir haben das gleiche Problem. Daher würde es mich brennend interessieren, ob Du es zwischenzeitlich "sauber" lösen konntest.
Hi
Nö, meine Kiste läuft immer noch genau so wie oben beschrieben. Das funktioniert ohne Probleme, so das ich nicht mehr nach einer anderen Lösung gesucht habe.
Wenn ich doch da nur logtechnisch weiter käme! Er sagt zwar, dass die Mounts "timed out" sind, aber sie sind trotzdem schon gemounted, wenn ich in die Rescuekonsole geworfen werde. Fast so, als wenn versucht wird, doppelt zu mounten und das zweite Mal schlägt natürlich fehl.
LG
DF8OE
Ich bin damals zu dem Schluss gekommen das ein benötigtes Modul noch nicht geladen ist (systemd arbeitet ja einiges parallel ab), deshalb habe ich den mount auf einen späteren Zeitpunkt verlegt.
Ansonsten, würde ja ein einfaches nofail in der fstab reichen, ich muss aber (später halt) nochmal mounten damit die platten zur Verfügung stehen.
Ich habe jetzt nochmal geguckt, es ist so das die mount services vom systemd-fstab-generator beim Systemstart generiert werden (siehe /run/systemd/generator). Es ist quasi nicht möglich hier die Reihenfolge der Ausführung zu verändern.
systemd-fstab-generator kann aber abgeschaltet werden, mit dem boot Parameter fstab=no wird die Erzeugung der mount services verhindert, und man kann seinen eigenen Service schreiben und nutzen.
Ein mount der Partitionen zu einem späteren Zeitpunkt funktioniert hier einwandfrei.
Ich habe eben auch nochmal getestet. Erstaunlicherweise ist das System, wenn ich an ALLE mounts in der fstab ein nofail eintrage, hochgefahren - wenn auch nicht fehlerfrei. Ich landete auf der Konsole, obwohl der X-Server und kdm gestartet werden sollen. Die Untersuchung der systemd-Protokolle ergab einen Fehler beim Starten von apparmor - es wurde gemeckert, dass die Datei freedesktop.org in /etc/apparmor.d/abstractions nicht gelesen werden konnte. Stimmt - die gab es da auch nicht - aber eine freedesktop.org.dpkg-dist... Diese habe ich wieder aktiviert. Danach bootet bei mir das System wieder in die grafische Oberfläche, es sind alle Dateisysteme gemounted (obwohl "nofail" in der fstab steht), es läuft einfach alles. Der Fehler mit apparmor steht übrigens NICHT in den Logs, wenn das "nofail" weg ist! Dann startet apparmor - aber ich lande wegen des timeouts immer in der Rescue-Konsole.
Jetzt - mit der umkopierten freedesktop.org UND dem nofail - läuft alles. Als nächstes werde ich mal apparmor deaktivieren - mal schauen, was dann passiert. Da ist irgendeine Reihenfolge beim Booten durcheinandergekommen - das denke ich auch.
LG
DF8OE
Okay, ich habe jetzt für mich eine saubere Lösung.
Ich habe in meiner fstab eine direktive für systemd eingetragen um den mount auf einen späteren zeitpunkt zu verlegen. Einen eigen service brauche ich jetzt nicht mehr. Meine fstab sieht jetzt so aus:
UUID=4ea712e1-25a7-4749-bbe9-0e6bb80b81d0 / ext4 defaults,noatime,errors=remount-ro 0 1
UUID=6d240a14-9a87-4b93-9b4b-6458a7f0ebaa /home ext4 defaults,nofail,noatime,x-systemd-after=systemd-udevd-kernel.socket,errors=remount-ro 0 2
UUID=e59da633-c3ad-4b2c-8ba2-f134c4f3d110 /home/opt ext4 defaults,nofail,noatime,x-systemd-after=systemd-udevd-kernel.socket,errors=remount-ro 0 2
UUID=c57a4047-41bf-484b-a3e9-e81ed50534f6 none swap nofail,x-systemd-after=systemd-udevd-kernel.socket,ssw 0 0
wobei nofail jetzt wahrscheinlich wieder raus-kann, da der mount einwandfrei funktioniert. Der entscheidende eintrag ist:
x-systemd-after=systemd-udevd-kernel.socket
zu diesem Zeitpunkt sind alle benötigten module geladen.
Super - genial - danke für deine Mühe. Da habe ich Dich doch noch mal motivieren können ;) . Alleine wäre ich nicht soweit gekommen.
LG
DF8OE