Bug#985255: Systemd initiates fsckd for no apparent reason
Am 16.03.21 um 11:41 schrieb Michael Biebl: Am 16.03.21 um 11:37 schrieb Michael Biebl: As you can see, the kernel switched the ordering of sdb with sdd. Hardware probing is no longer asynchronous, so you can't rely on your Sorry, this was confusing. I meant: Hardware probing by the kernel is nowadays asynchronous. So you can't rely on the kernel provided names. You might try adding "scsi_mod.scan=sync" to your kernel command line to instruct the kernel to probe the scsi devices synchronously. https://cateee.net/lkddb/web-lkddb/SCSI_SCAN_ASYNC.html It's not something I would recommend and not guaranteed to work, but you can try. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#985255: Systemd initiates fsckd for no apparent reason
Am 16.03.21 um 11:37 schrieb Michael Biebl: As you can see, the kernel switched the ordering of sdb with sdd. Hardware probing is no longer asynchronous, so you can't rely on your Sorry, this was confusing. I meant: Hardware probing by the kernel is nowadays asynchronous. So you can't rely on the kernel provided names. The same is btw true as well for ethernet devices. If you have multiple ones, you can't rely on eth0, eth1 names being stable. They can be assigned randomly during boot. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#985255: Systemd initiates fsckd for no apparent reason
Am 16.03.21 um 01:20 schrieb haagmj: Requested info attached. The exact error message was provided in my initial report. In any case, I know of no way to take a screenshot from within a terminal. On Mon, 15 Mar 2021 18:37:05 +0800 *Michael Biebl * wrote Control: tags -1 + moreinfo Please provide your /etc/fstab, an exact error message (screenshot is fine), the output of "udevadm info --export-db" and a "journalctl -alb" from a failed boot. A bit more detailed explanation: As you can see in the "udevadm info" dump, there is a sda device ( CT1000MX500SSD1) with a partition sda1, sda2, sda3, sda4, sda5, sda6 Then there is a sdb device (SAMSUNG_HD103SJ) with a partition sdb1 Then there is a sdc device (SAMSUNG_HD103SJ) with a partition sdc1 Then there is a sdd device (CT1000MX500SSD1) with a partition sdd1, sdd2, sdd3, sdd4, sdd5, sdd6. I assume this is the copy of your master disk. As you can see, the kernel switched the ordering of sdb with sdd. Hardware probing is no longer asynchronous, so you can't rely on your 2nd CT1000MX500SSD1 disk to show up as /dev/sdb. The Linux kernel simply doesn't work this way anymore. My recommendation to use nofail/noauto won't really help in this case (it is more for USB disks which aren't always attached and you don't want to make the boot fail because the device is not plugged in). The only thing that will help is to use UUIDs or LABELs (and to make sure they are "unique", i.e. the second disk is not an exact clone of the first one. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#985255: Systemd initiates fsckd for no apparent reason
Am 16.03.2021 um 02:34 schrieb Michael Biebl: Apparently /dev/sdb2 is not attached during boot, but you have listed it in /etc/fstab. Therefore systemd is waiting for it. You probably want noauto or nofail here, but not defaults. Please also keep in mind, that the kernel provided names are not necessarily stable, so I would advice to *not* use /dev/sd* but instead UUID= or LABEL= in /etc/fstab.
Bug#985255: Systemd initiates fsckd for no apparent reason
Package: systemd Version: 247.3-1 Every few system restarts fsckd runs and fails with the following error message: [TIME] timed out waiting for device /dev/sdb2 I am subsequently dropped into a terminal session (busybox?) There are no problems with the filesystem or the hard disk (SSD) in question. Pressing Ctl-Alt-Del almost always results in a successful reboot. Rarely, the system will halt again with the same error message requiring yet another reboot. In any case, the system eventually boots without error. This problem first appeared on a hard disk that has since been replaced. Manually initiating fsck on /dev/sdb2 has never resulted in an error on either the old disk or the new one. Occasionally, systemd reports an error indicating missing system files (/dev/sda1). Again, manually running fsck against the referenced partition has never resulted in an error. I tried sending this via reportbug, but I've never received an email reply indicating it was received. I was previously running Debian Buster without issue. I upgraded to Debian Bullseye several months ago, but did not experience this problem until sometime after the initial upgrade. If you require additional information, feel free to contact me with your request.
Bug#985255: Systemd initiates fsckd for no apparent reason
Control: tags -1 + moreinfo Please provide your /etc/fstab, an exact error message (screenshot is fine), the output of "udevadm info --export-db" and a "journalctl -alb" from a failed boot. OpenPGP_signature Description: OpenPGP digital signature
