Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Hi On Mon, 3 Nov 2014 22:26:25 +0100 M G Berberich wrote: > Hello, > > Am Samstag, den 11. Oktober schrieb Michael Biebl: > > could you please remove your local service file again, add > > systemd.log_level=debug to the kernel command line, enable verbose udev > > debug logging via /etc/udev/udev.conf and then after a reboot, attach > > the output of > > journalctl -alb > > My little script no longer worked: the system hangs at trying to mount > sdb and gives up after 1:30 min. But⦠> > Inbetween I found that the systems boots if I deinstall lvm2. So there > seems to be some interaction between lvm2 and btrfs udev-rules or > systemd-scripts. > > I attached the compressed log. This was with my script and lvm2 > installed and failed. this bug report fell through the cracks somehow, sorry. Do you still encounter this issue with a recent version of systemd? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Hello, Am Samstag, den 11. Oktober schrieb Michael Biebl: > could you please remove your local service file again, add > systemd.log_level=debug to the kernel command line, enable verbose udev > debug logging via /etc/udev/udev.conf and then after a reboot, attach > the output of > journalctl -alb My little script no longer worked: the system hangs at trying to mount sdb and gives up after 1:30 min. But… Inbetween I found that the systems boots if I deinstall lvm2. So there seems to be some interaction between lvm2 and btrfs udev-rules or systemd-scripts. I attached the compressed log. This was with my script and lvm2 installed and failed. MfG bmg -- „Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!“ | berbe...@fmi.uni-passau.de (SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic journalctl-alb.log.xz Description: application/xz
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Am 12.10.2014 um 00:45 schrieb Dimitri John Ledkov: > On 11 October 2014 20:14, Michael Biebl wrote: > 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. Yeah, curious. Looking at systemd-analyze-dump.txt, the btrfs volumes seem to be correctly mounted and I don't find the custom btrfs-scan.service in the dump. M G, can you elaborate if this dump is from a successful boot or not? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
On 11 October 2014 20:14, Michael Biebl 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Am 11.10.2014 um 21:17 schrieb Michael Biebl: > Please also attach your /etc/fstab and mention which mounts are btrfs > volumes which are not mounted. nvm, I just noticed that you already did provide that file in the mean time. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Hi, could you please remove your local service file again, add systemd.log_level=debug to the kernel command line, enable verbose udev debug logging via /etc/udev/udev.conf and then after a reboot, attach the output of journalctl -alb Please also attach your /etc/fstab and mention which mounts are btrfs volumes which are not mounted. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
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: -> 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 To me it rather looks like "btrfs scan" is not triggered at all. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
On 11 October 2014 18:09, Michael Biebl wrote: > Am 11.10.2014 um 18:57 schrieb Dimitri John Ledkov: >> Can someone from systemd experts say whether or not >> systemd-udev-trigger is run before local-fs target? > > That's not quite how it works. > local-fs.target is a dynamic target which all the mounts in /etc/fstab > hook into. > If you look at "systemctl show local-fs.target", you'll see that it has > After=foo.mount bar.mount baz.mount > > So local-fs.target is delayed until all mount points as defined in > /etc/fstab have shown up or a timeout is reached. > > > mount units themselves are triggered via udev and mounted once the > devices show up. Therefore, there is no explicit ordering between > systemd-udev-trigger.service and local-fs.target. > > 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. This is far from the only filesystem that requires things to happen and be available before one can mount it. >> Original bug reporter, Can you change before/after/wants on the udevd >> units such that systemd-udev-trigger unit is executed before local-fs >> target and see if that resolves your problem or not? > > That should not be necessary. > btrfs scan is necessary to mount btrfs fstab entry. with initramfs, this happens there. without initramfs, it must happen before local-fs target. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Am 11.10.2014 um 18:57 schrieb Dimitri John Ledkov: > Can someone from systemd experts say whether or not > systemd-udev-trigger is run before local-fs target? That's not quite how it works. local-fs.target is a dynamic target which all the mounts in /etc/fstab hook into. If you look at "systemctl show local-fs.target", you'll see that it has After=foo.mount bar.mount baz.mount So local-fs.target is delayed until all mount points as defined in /etc/fstab have shown up or a timeout is reached. mount units themselves are triggered via udev and mounted once the devices show up. Therefore, there is no explicit ordering between systemd-udev-trigger.service and local-fs.target. > Original bug reporter, Can you change before/after/wants on the udevd > units such that systemd-udev-trigger unit is executed before local-fs > target and see if that resolves your problem or not? That should not be necessary. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Hey all, On 22 September 2014 18:09, M G Berberich wrote: > Hello, > > Am Montag, den 22. September schrieb Dimitri John Ledkov: > >> It is my understanding that udev rules should be sufficient. >> Could you please provide your /etc/fstab to reproduce this failure to boot? >> Are you attempting to do initramfs-less boot with rootfs on btrfs? > > --- > # /etc/fstab: static filesystem information. > # > # > proc/proc procdefaults0 0 > > /dev/sda2 / ext4errors=remount-ro,discard 0 > 1 > /dev/sda1 /boot ext2defaults0 2 > /dev/sda3 /varext4discard 0 2 > tmpfs /tmptmpfs defaults,size=8g1 2 > /dev/sdd1 /scratchext4defaults,noatime0 2 > /dev/sdb/home btrfs subvol=home 0 0 > /dev/sdb/data btrfs subvol=data,noatime 0 0 > … > --- > > /boot is ext2 > /, /var is ext4 > My understanding is that after udevd is started, systemd-udev-trigger.service should be started, which then should trigger events that would cause btrfs udev to run and successfully execute btrfs scan for all btrfs formatted drives. However, it also seems to be non-trivial to setup initramfs-less debian system, hence I can't debug this locally. Original bug reporter, Can you obtain udevd logs of events that happen when you boot with and without your custom job to fix things? Can someone from systemd experts say whether or not systemd-udev-trigger is run before local-fs target? Original bug reporter, Can you change before/after/wants on the udevd units such that systemd-udev-trigger unit is executed before local-fs target and see if that resolves your problem or not? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Hello, Am Montag, den 22. September schrieb Dimitri John Ledkov: > It is my understanding that udev rules should be sufficient. > Could you please provide your /etc/fstab to reproduce this failure to boot? > Are you attempting to do initramfs-less boot with rootfs on btrfs? --- # /etc/fstab: static filesystem information. # # proc/proc procdefaults0 0 /dev/sda2 / ext4errors=remount-ro,discard 0 1 /dev/sda1 /boot ext2defaults0 2 /dev/sda3 /varext4discard 0 2 tmpfs /tmptmpfs defaults,size=8g1 2 /dev/sdd1 /scratchext4defaults,noatime0 2 /dev/sdb/home btrfs subvol=home 0 0 /dev/sdb/data btrfs subvol=data,noatime 0 0 … --- /boot is ext2 /, /var is ext4 MfG bmg -- „Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!“ | berbe...@fmi.uni-passau.de (SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Hello,
Am Montag, den 22. September schrieb Dimitri John Ledkov:
> On 22 September 2014 12:57, Michael Biebl wrote:
> > Am 22.09.2014 um 13:27 schrieb M G Berberich:
> >> Hello,
> >>
> >> Am Montag, den 22. September schrieb Michael Biebl:
> >>> Am 21.09.2014 um 22:04 schrieb M G Berberich:
> Package: systemd
> Version: 208-8
> Severity: normal
>
> Dear Maintainer,
>
> systemd is not able to boot a system that has btrfs-volumes in
> /etc/fstab and does not use a initramfs. That is because ‘btrfs device
> scan’ has to be executed bevor mounting btrfs-volumes and systemd does
> not do this.
>
> >>>
> >>> I see
> >>>
> >>> btrfs-tools: /lib/udev/rules.d/70-btrfs.rules
> >>> btrfs-tools: /lib/udev/rules.d/80-btrfs-lvm.rules
> >>>
> >>> 70-btrfs.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
> >>> 80-btrfs-lvm.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
> >>>
> >>> Can you investigate why that is not sufficient.
> >>
> >> A first guess: local filesystems are mounted bevor udev is working.
> >
> > Well, no. udev is started well before the file systems are mounted.
> > Actually, udev is responsible for local file systems to be mounted since
> > the mounting is event based and systemd relies on udev to trigger those
> > events.
> >
> > I'm bringing Dimitri into the loop here, as this sounds like a bug in
> > btrfs-tools to me.
> >
>
> It is my understanding that udev rules should be sufficient.
> Could you please provide your /etc/fstab to reproduce this failure to boot?
not at the moment, but it must something like
/dev/sdb /home btrfs subvol=home0 2
/dev/sdb /data btrfs subvol=data0 2
> Are you attempting to do initramfs-less boot with rootfs on btrfs?
No, as far as I remember both boot and root are ext4 on
/dev/sda. /dev/sdb and dev/sdc are a btrfs-raid1 volume.
MfG
bmg
--
„Des is völlig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!“ | berbe...@fmi.uni-passau.de
(SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
On 22 September 2014 12:57, Michael Biebl wrote:
> Am 22.09.2014 um 13:27 schrieb M G Berberich:
>> Hello,
>>
>> Am Montag, den 22. September schrieb Michael Biebl:
>>> Am 21.09.2014 um 22:04 schrieb M G Berberich:
Package: systemd
Version: 208-8
Severity: normal
Dear Maintainer,
systemd is not able to boot a system that has btrfs-volumes in
/etc/fstab and does not use a initramfs. That is because ‘btrfs device
scan’ has to be executed bevor mounting btrfs-volumes and systemd does
not do this.
>>>
>>> I see
>>>
>>> btrfs-tools: /lib/udev/rules.d/70-btrfs.rules
>>> btrfs-tools: /lib/udev/rules.d/80-btrfs-lvm.rules
>>>
>>> 70-btrfs.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
>>> 80-btrfs-lvm.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
>>>
>>> Can you investigate why that is not sufficient.
>>
>> A first guess: local filesystems are mounted bevor udev is working.
>
> Well, no. udev is started well before the file systems are mounted.
> Actually, udev is responsible for local file systems to be mounted since
> the mounting is event based and systemd relies on udev to trigger those
> events.
>
> I'm bringing Dimitri into the loop here, as this sounds like a bug in
> btrfs-tools to me.
>
It is my understanding that udev rules should be sufficient.
Could you please provide your /etc/fstab to reproduce this failure to boot?
Are you attempting to do initramfs-less boot with rootfs on btrfs?
--
Regards,
Dimitri.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Am 22.09.2014 um 13:27 schrieb M G Berberich:
> Hello,
>
> Am Montag, den 22. September schrieb Michael Biebl:
>> Am 21.09.2014 um 22:04 schrieb M G Berberich:
>>> Package: systemd
>>> Version: 208-8
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>>
>>> systemd is not able to boot a system that has btrfs-volumes in
>>> /etc/fstab and does not use a initramfs. That is because ‘btrfs device
>>> scan’ has to be executed bevor mounting btrfs-volumes and systemd does
>>> not do this.
>>>
>>
>> I see
>>
>> btrfs-tools: /lib/udev/rules.d/70-btrfs.rules
>> btrfs-tools: /lib/udev/rules.d/80-btrfs-lvm.rules
>>
>> 70-btrfs.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
>> 80-btrfs-lvm.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
>>
>> Can you investigate why that is not sufficient.
>
> A first guess: local filesystems are mounted bevor udev is working.
Well, no. udev is started well before the file systems are mounted.
Actually, udev is responsible for local file systems to be mounted since
the mounting is event based and systemd relies on udev to trigger those
events.
I'm bringing Dimitri into the loop here, as this sounds like a bug in
btrfs-tools to me.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Hello,
Am Montag, den 22. September schrieb Michael Biebl:
> Am 21.09.2014 um 22:04 schrieb M G Berberich:
> > Package: systemd
> > Version: 208-8
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > systemd is not able to boot a system that has btrfs-volumes in
> > /etc/fstab and does not use a initramfs. That is because ‘btrfs device
> > scan’ has to be executed bevor mounting btrfs-volumes and systemd does
> > not do this.
> >
>
> I see
>
> btrfs-tools: /lib/udev/rules.d/70-btrfs.rules
> btrfs-tools: /lib/udev/rules.d/80-btrfs-lvm.rules
>
> 70-btrfs.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
> 80-btrfs-lvm.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
>
> Can you investigate why that is not sufficient.
A first guess: local filesystems are mounted bevor udev is working.
MfG
bmg
--
„Des is völlig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!“ | berbe...@fmi.uni-passau.de
(SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762395: systemd is not abel to boot systems with btrfs and without initramfs
Am 21.09.2014 um 22:04 schrieb M G Berberich:
> Package: systemd
> Version: 208-8
> Severity: normal
>
> Dear Maintainer,
>
> systemd is not able to boot a system that has btrfs-volumes in
> /etc/fstab and does not use a initramfs. That is because ‘btrfs device
> scan’ has to be executed bevor mounting btrfs-volumes and systemd does
> not do this.
>
I see
btrfs-tools: /lib/udev/rules.d/70-btrfs.rules
btrfs-tools: /lib/udev/rules.d/80-btrfs-lvm.rules
70-btrfs.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
80-btrfs-lvm.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}"
Can you investigate why that is not sufficient.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
