Bug#985255: Systemd initiates fsckd for no apparent reason

[Michael Biebl]

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.

    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.

---- On Mon, 15 Mar 2021 18:37:05 +0800 *Michael Biebl <bi...@debian.org>* wrote ----

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



I assume this is the copy of your master disk.
As you can see, the kernel switched the ordering of sdb with sdd.






Regards,
Michael

Then there is a sdd device (CT1000MX500SSD1) with a partition sdd1, sdd2, sdd3, sdd4, sdd5, sdd6. 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.

OpenPGP_signature
Description: OpenPGP digital signature