Dear Michael Biebl, you wrote:
> Well, /usr is mounted by the initramfs these days. So it should already
> be available when systemd is started. If that fails, this is a bug which
> needs to be addressed by initramfs-tools (or one of the hook scripts).
> It wasn't clear so far that /usr hasn't been mounted at all.
>
> Is /usr on LVM, RAID, etc?
No, nothing like that. And for what it's worth: the problem only appeared
after I upgraded systemd last week. The laptop has nothing special in its
setup, and has been working perfectly for years, until last week when systemd
was renwed. I think in my bugreport I mentioned the problem that /usr wasn't
mounted.
In your next reply you wrote:
> I'm a bit confused by those logs. They show that sda5 have been mounted.
>
> Dec 17 15:44:29 localhost.localdomain kernel: EXT4-fs (sda5): mounting
> ext3 file system using the ext4 subsystem
> Dec 17 15:44:29 localhost.localdomain kernel: EXT4-fs (sda5): mounted
> filesystem with ordered data mode. Opts: (null)
>
> I figure /dev/sda5 is your /usr partition? Just to be sure, please
> attach ls -la /dev/disk/by-uuid/
I seem to remember that message, in particular the Opts: (null) remark, and I
think at that point /usr was mounted by me fron the systemd shell. Also,
couldn't it be that initramfs *did* do the mount, but that remounting it rw,
als reported in the error message is the problem? Also, to me it appears
remarkable that by removing the 'quiet' from the kernel parameters, so that
things go a bit slower because of the extra messages that are displayed the
frequency of failing boot procedures is greatly diminished. I'm considering
trying to add 'verbose' to grub's parameters to see if that produces more
output and maybe further reduces the frequency, but I haven't had the time to
do that yet. Something on the TODO list :-)
Anyway, here's the ls -la output:
total 0
drwxr-xr-x 2 root root 200 Dec 18 13:05 ./
drwxr-xr-x 5 root root 100 Dec 18 13:02 ../
lrwxrwxrwx 1 root root 10 Dec 18 13:02 04b82e8b-f871-4abb-978a-44ae44c5d1f7
-> ../../sda1
lrwxrwxrwx 1 root root 10 Dec 18 13:02 595bcdbf-6436-45a7-99d2-297a3dd85930
-> ../../sda6
lrwxrwxrwx 1 root root 10 Dec 18 13:02 693c71eb-d411-4ee0-a1b3-c577df02e01b
-> ../../sda9
lrwxrwxrwx 1 root root 10 Dec 18 13:02 6bcb2a05-33c9-402b-8093-e6a35ffd7aa1
-> ../../sda8
lrwxrwxrwx 1 root root 11 Dec 18 13:05 82e52787-6072-4af9-a5e6-2d88c365e62b
-> ../../loop0
lrwxrwxrwx 1 root root 10 Dec 18 13:02 c5591eff-0a6c-4310-bb11-7d5535f7da7b
-> ../../sda7
lrwxrwxrwx 1 root root 10 Dec 18 13:05 e289e4ad-be1d-42a8-9b38-f4dad9473520
-> ../../dm-0
lrwxrwxrwx 1 root root 10 Dec 18 13:02 ea8202e7-4564-424c-af70-a6a640fafb65
-> ../../sda5
~
I'll do the 'debug' addition later this weekend, like you requested.
Finally, you asked:
> Do you have any custom udev rules in /etc/udev/rules.d?
I don't think so, looking at the time stamps nothing has been changed there for
years:
total 10
drwxr-xr-x 2 root root 3072 Dec 6 2014 ./
drwxr-xr-x 4 root root 1024 Dec 3 08:34 ../
-rw-r--r-- 1 root root 115 Dec 6 2014 70-automount.rules
-rw-r--r-- 1 root root 3841 Dec 6 2014 70-persistent-cd.rules
-rw-r--r-- 1 root root 895 Feb 26 2013 70-persistent-net.rules
And I definitely didn't recently change there any files, so again: the problem
appeared out of the blue since last weeks upgrade.
I hope the above gives you at least some additional info. As I wrote: I'll do
the 'debug' addition tomorrow.
Cheers,
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
