Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Dimitri John Ledkov
xnox at debian.org
Sat Oct 11 23:45:21 BST 2014
On 11 October 2014 20:14, Michael Biebl <biebl at debian.org> wrote:
> Am 11.10.2014 um 20:58 schrieb Dimitri John Ledkov:
>> So what needs doing? Because to mount btrfs /dev/sdb,
>> systemd-udev-trigger is needed to generate "block" "add" event and
>> thus execute btrfs scan, in the initramfs-less case.
>> And ate the moment systemd-udev-trigger is only called after local-fs.
>
> How did you come to that conclusion that this is happening? At least the
> timestamps in the systemdadm dump do not confirm what you are suggesting:
>
By inspecting conditions, which i clearly parsed wrong.
I don't have access to a initramfsless system, and I didn't read into
systemdadm dump at all.
> -> Unit systemd-udev-trigger.service:
> Description: udev Coldplug all Devices
> Instance: n/a
> Unit Load State: loaded
> Unit Active State: active
> Inactive Exit Timestamp: Sun 2014-09-21 21:51:55 CEST
> Active Enter Timestamp: Sun 2014-09-21 21:51:55 CEST
>
>
> -> Unit local-fs.target:
> Description: Local File Systems
> Instance: n/a
> Unit Load State: loaded
> Unit Active State: active
> Inactive Exit Timestamp: Sun 2014-09-21 21:51:57 CEST
> Active Enter Timestamp: Sun 2014-09-21 21:51:57 CEST
>
>
Actually that dump is very confusing for me to read, but it does have
timestamps for udev-trigger 2 seconds before data-gentoo, data and
home mount.
Then yeah, we need a log of udev events that were triggered during
udev-trigger time.
> To me it rather looks like "btrfs scan" is not triggered at all.
Actually it looks like it was, no? Because data-gentoo, data and home
mount units and local-fs did succeed, no?! If btrfs scan was not run,
they wouldn't be active but failed or some such?!
I'm further confused by reading into systemdadm output than I was before.
--
Regards,
Dimitri.
More information about the Pkg-systemd-maintainers
mailing list