Bug#985255: Systemd initiates fsckd for no apparent reason
biebl at debian.org
Tue Mar 16 10:37:20 GMT 2021
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
> <biebl at debian.org>* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 840 bytes
Desc: OpenPGP digital signature
More information about the Pkg-systemd-maintainers