| View previous topic :: View next topic |
| Author |
Message |
Hamlet
Apprentice
Joined: 15 Apr 2005
Posts: 151
Location: Turin (Italy)
|
 Posted: Tue Jul 25, 2017 2:48 am Post subject: [SOLVED] New systemd tries to mount /sysroot/sysroot/usr |
 |
|
On Saturday I have run through my weekly update of a amd64 Gentoo desktop system.
This time, I got new systemd (233-r4 -> 234-r2), kernel (4.12.3; I was running 4.12.1), and no new dracut (045-r2).
I could not really find anything to do for the advertised move of systemd from /usr/lib into /lib.
Actually, considering that my /usr lives on its own LVM partition ("/dev/SystemData/usr"), I thought things would, if anything, improve.
They didn't.
On rebooting, systemd in his wisdom insists to try and mount the partition on /sysroot/sysroot/usr; this is /run/systemd/generators/sysroot-sysroot-usr.mount: | Code: | # Automatically generated by systemd-fstab-generator
[Unit]
SourcePath=/sysroot/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=initrd-fs.target
Requires=systemd-fsck@dev-disk-by\x2duuid-3c6e12c5\x2dd50a\x2d4a75\x2da900\x2d2af971fd75a4.service
After=systemd-fsck@dev-disk-by\x2duuid-3c6e12c5\x2dd50a\x2d4a75\x2da900\x2d2af971fd75a4.service
[Mount]
# Canonicalized from /sysroot/usr
Where=/sysroot/sysroot/usr
What=/dev/disk/by-uuid/3c6e12c5-d50a-4a75-a900-2af971fd75a4
Type=reiserfs
Options=auto
|
The correct path would be /sysroot/usr. It seems the "canonicalization" went awry.
If I ask systemd to regenerate its scripts (systemd daemon-reload) from the rescue shell, it regenerates the file just the same as above: just wrong.
I can mount the thing manually... but then I don't even know how to tell systemd to go on (systemctl default is too "destructive"). And anyway I would like it to figure it out right the first time instead.
I can't even convince systemd to load a sysroot-usr.mount file (which I create on the fly) within the emergency shell. So the only way out for me is `systemctl --force reboot`...
Changing the kernel to old 4.12.1 in grub incurs in a 90 seconds timeout with drop to emergency shell, from which a `systemctl default` starts the system in a regular way that allows me to write posts in Gentoo forums.
Any suggestion or insight? is it dracut fault? is it the kernel command line? is it some systemd configuration?
Miscellaneous information:
- relevant line in fstab: `UUID=3c6e12c5-d50a-4a75-a900-2af971fd75a4 /usr reiserfs auto 0 2`
- kernel arguments according to dmesg: `Command line: BOOT_IMAGE=/Linux/Gentoo-4.12/gentoo.1/vmlinuz root=UUID=c6fb4c15-1eb2-4cac-bf28-5ab0efd3a1dc ro resume=/dev/sda6 rd.lvm.lv=SystemData/usr systemd.legacy_systemd_cgroup_controller=yes loglevel=5`
P.S. dracut does not even give me an editor. That's so wrong.
Last edited by Hamlet on Wed Aug 09, 2017 4:42 pm; edited 1 time in total |
|
| Back to top |
|
 |
Hamlet
Apprentice
Joined: 15 Apr 2005
Posts: 151
Location: Turin (Italy)
|
| Posted: Mon Jul 31, 2017 12:44 am Post subject: [SOLVED] systemd mounting partition in /sysroot/sysroot/usr |
|
|
It appears to be an upstream bug, already fixed upstream with their commit 98eda38aed6a10c4f6d6ad0cac6e5361e87de52b (commit c7b2630c9154722e2295f3dbfbb19f3305676ecf in the issue branch).
To pick the fix from the official branch and quickly apply it, I could do roughly (all steps except the first need more or less administrator privileges):
| Code: | git clone https://github.com/systemd/systemd.git
mkdir -p /etc/portage/patches/sys-apps/systemd-234-r2/
git -C systemd show 98eda38aed6a10c4f6d6ad0cac6e5361e87de52b > /etc/portage/patches/sys-apps/systemd-234-r2/chase_symlink.patch
emerge -1 =sys-apps/systemd-234-r2 |
and finally have dracut regenerate the init ram disk. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
