Hi, For some reason, I had to do ln -s /usr/lib/systemd/system/systemd-remount-fs.service /etc/systemd/system/multi-user.target.wants/ to get / remounted r/w after the upgrade to systemd-229. This wasn't required before. On another installation, older than the one I got the problem, it is setup correctly just with /usr/lib/systemd/system/local-fs.target.wants/systemd-remount-fs.service, which I also have on the current bogus system. Anyone got the same problem? Here is my fstab: /dev/mapper/root / btrfs noatime,subvol=gentoo 0 0 /dev/mapper/root /lib/modules btrfs noatime,subvol=lib.modules 0 0 /dev/mapper/root /usr/src btrfs noatime,subvol=usr.src 0 0 /dev/mapper/root /home/florent/SteamLibrary btrfs noatime,subvol=SteamLibrary 0 0 UUID=9d1ae5d6-9fe0-49ae-b532-c3697ff07155 /boot btrfs noatime,nodev 0 0 /dev/cdrom /mnt/cdrom auto noauto,ro 0 0 /dev/fd0 /mnt/floppy auto noauto 0 0
Does running "status" over the failed .service give any hint about why it failed to start? Or isn't its starting even tried?
In fact, it seems that systemd doesn't support mounting multiple times the same device. That's for the multiple mounts. I went on #systemd to investigate on this but it seems like a limitation from systemd. The output from mounting units says it clearly, in fact. For the remount-fs unit, it is related to that problem: systemd see /dev/mapper/root as busy and doesn't do anything for it… strange.
I have a btrfs subvolume setup similar to yours, but without the lvm. It seems to work fine with systemd-229. I suspect that my root filesystem is mounted read/write in the initramfs (dracut).
My fstab, for reference. > UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 /boot btrfs subvol=boot,autodefrag 0 0 > UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 / btrfs subvol=rootfs,autodefrag 0 1 > UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 /mnt/data1 btrfs subvol=,autodefrag 0 0 > UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 /home btrfs subvol=home,autodefrag 0 0 > UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 /var/portage/distfiles btrfs subvol=distfiles,autodefrag 0 0 > UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 /var/portage/packages btrfs subvol=packages,autodefrag 0 0 > UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 /chroots btrfs subvol=chroots,autodefrag 0 0
This is really irritating. I setup an fstab with UUID (blkid /dev/mapper/root, took UUID="bla"), and now I have a job timeout on dev-disk\x2dby\x2duuid-blablabla I'll setup a virtual machine to test that. Oh and, I should have noticed that I use RAID1 & LUKS. /dev/md2 is a RAID1 of /dev/sda3 and /dev/sdc3, where the LUKS volume resides. When opened, it gives /dev/mapper/root. For now I'll just mask all devices, disable automounting and setup a unit to do a "mount -a". I think this isn't related to Gentoo, and I'll go on #systemd to take care of that shit.
(In reply to Florent Peterschmitt from comment #5) > I think this isn't related to Gentoo, and I'll go on #systemd to take care > of that shit. Sounds good. Please report back, either way.
any news on this? Maybe upgrading to 233 could help too... :/
Hello, Sorry i forgot to update this issue -_- Well, i asked on the systemd mailing list and it is related to systemd and a udev variable called SYSTEMD_READY that must be set to 1 for a device to be usable. I guess the Gentoo tools should take this in account for there scripts. Here is the link to the ML archives: https://lists.freedesktop.org/archives/systemd-devel/2016-June/036896.html I think i resolved the issue by adding a custom script to the initrd image. Can't remember since i don't use Gentoo row…
