Re: [systemd-devel] Second (erroneous) check of rootfs?

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Cristian Rodríguez]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

El 07/01/15 a las 22:55, Nikolai Zhubr escribió:
> 08.01.2015 4:12, Cristian Rodríguez:
>> El 07/01/15 a las 21:43, Lennart Poettering escribió:
>>
>>> Maybe suse forgot to include this service file in the initrd or so?
>>
>> Correct. It appears to be a bug in the dracut package. I wonder why ..
>
> Ok. So should I file a report to opensuse bugtracker? I have no idea if
> the issue is suse-specific actually... Although I know that dracut is
> very new for suse, that might explain it...

Hrmm.. looking at the dracut upstream sources.. this service is not 
included in the required file list. so it is an upstream problem.

Attached is a patch to fix the problem.



[-- Attachment #2: 0001-98systemd-Include-systemd-root-fsck.service-too.patch --]
[-- Type: text/x-patch, Size: 998 bytes --]

From 81b8f407d84cb60e9d4df0e2f68b4bd3850448f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= <crrodriguez-stAJ6ESoqRxg9hUCZPvPmw@public.gmane.org>
Date: Wed, 7 Jan 2015 23:22:00 -0300
Subject: [PATCH] 98systemd: Include systemd-root-fsck.service too

---
 modules.d/98systemd/module-setup.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/modules.d/98systemd/module-setup.sh b/modules.d/98systemd/module-setup.sh
index 51ea288..a28df30 100755
--- a/modules.d/98systemd/module-setup.sh
+++ b/modules.d/98systemd/module-setup.sh
@@ -91,6 +91,7 @@ install() {
         $systemdsystemunitdir/systemd-reboot.service \
         $systemdsystemunitdir/systemd-kexec.service \
         $systemdsystemunitdir/systemd-fsck@.service \
+        $systemdsystemunitdir/systemd-fsck-root.service \
         $systemdsystemunitdir/systemd-udevd.service \
         $systemdsystemunitdir/systemd-udev-trigger.service \
         $systemdsystemunitdir/systemd-udev-settle.service \
-- 
2.2.1

Re: Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Wed, 07 Jan 2015 23:23:27 -0300
Cristian Rodríguez <crrodriguez@opensuse.org> пишет:

> El 07/01/15 a las 22:55, Nikolai Zhubr escribió:
> > 08.01.2015 4:12, Cristian Rodríguez:
> >> El 07/01/15 a las 21:43, Lennart Poettering escribió:
> >>
> >>> Maybe suse forgot to include this service file in the initrd or so?
> >>
> >> Correct. It appears to be a bug in the dracut package. I wonder why ..
> >
> > Ok. So should I file a report to opensuse bugtracker? I have no idea if
> > the issue is suse-specific actually... Although I know that dracut is
> > very new for suse, that might explain it...
> 
> Hrmm.. looking at the dracut upstream sources.. this service is not 
> included in the required file list. so it is an upstream problem.
> 
> Attached is a patch to fix the problem.
> 
> 

Are you sure? Where this service is called in initrd then? Note that
fsck for root *did* run. dracut runs generator for root in
98systemd/rootfs-generator.sh which does

            echo "RequiresOverridable=systemd-fsck@${_name}.service"
            echo "After=systemd-fsck@${_name}.service"

And initrd cannot use systemd-fsck-root.service because this service
assumes current root is "/" which is of course wrong in initrd. 

So options are

a) somehow dynamically disable systemd-fsck-root.service from within
initrd 
b) pretend systemd-fsck-root.service did run. Which probably is the
same as it means overriding service definition
c) allow passing real root device to systemd-fsck-root.service. Very
ugly hack is

[Service]
ExecStart=@rootlibexecdir@/systemd-fsck $__REAL_ROOT_DEVICE__

where __REAL_ROOT_DEVICE__ is added by drop-in in initrd, by
rootfs-generator.sh

[Service]
Environment=__REAL_ROOT_DEVICE__=${_name}"
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Sun, 11 Jan 2015 13:43:34 +0300
Nikolai Zhubr <n-a-zhubr-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> пишет:

> >
> > Uh. Why not simply mount rootfs rw in initrd then?
> 
> I'm not against generally. But it'd mean that this first mount is 
> actually a real mount, the fs will start up in full. Then I'd suppose it 
> is definitely a must to supply all necessary mount options (from fstab) 
> at this stage already. I don't easily see how to do this currently, at 
> least on my opensuse system.
> 

By adding all needed options to rootflags="..." (modify
GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
in /etc/default/grub; you can use yast for it).

Otherwise it is functional gap between non-systemd and systemd
enabled dracut. Without systemd dracut will actually mount root
read-only, then fetch mount options from real root /etc/fstab and then
remount real root read-write using correct options. This all got lost
when converting to systemd.

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 4:11 AM, Andrei Borzenkov <arvidjaar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> В Sun, 11 Jan 2015 13:43:34 +0300
> Nikolai Zhubr <n-a-zhubr-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> пишет:
>
>> >
>> > Uh. Why not simply mount rootfs rw in initrd then?
>>
>> I'm not against generally. But it'd mean that this first mount is
>> actually a real mount, the fs will start up in full. Then I'd suppose it
>> is definitely a must to supply all necessary mount options (from fstab)
>> at this stage already. I don't easily see how to do this currently, at
>> least on my opensuse system.
>>
>
> By adding all needed options to rootflags="..." (modify
> GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
> in /etc/default/grub; you can use yast for it).
>
> Otherwise it is functional gap between non-systemd and systemd
> enabled dracut. Without systemd dracut will actually mount root
> read-only, then fetch mount options from real root /etc/fstab and then
> remount real root read-write using correct options. This all got lost
> when converting to systemd.


Not true on Fedora even still with 21. The kernel parameter ro is
present, so dracut mounts root read-only, then reads fstab, then does
a remount. Fedora is a systemd OS of course.


-- 
Chris Murphy

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Sun, 11 Jan 2015 04:15:41 -0700
Chris Murphy <lists-zXQU9YWDTqjmlV4oE/1sFAC/G2K4zDHf@public.gmane.org> пишет:

> On Sun, Jan 11, 2015 at 4:11 AM, Andrei Borzenkov <arvidjaar-Re5JQEeQqe8@public.gmane.orgm> wrote:
> > В Sun, 11 Jan 2015 13:43:34 +0300
> > Nikolai Zhubr <n-a-zhubr-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> пишет:
> >
> >> >
> >> > Uh. Why not simply mount rootfs rw in initrd then?
> >>
> >> I'm not against generally. But it'd mean that this first mount is
> >> actually a real mount, the fs will start up in full. Then I'd suppose it
> >> is definitely a must to supply all necessary mount options (from fstab)
> >> at this stage already. I don't easily see how to do this currently, at
> >> least on my opensuse system.
> >>
> >
> > By adding all needed options to rootflags="..." (modify
> > GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
> > in /etc/default/grub; you can use yast for it).
> >
> > Otherwise it is functional gap between non-systemd and systemd
> > enabled dracut. Without systemd dracut will actually mount root
> > read-only, then fetch mount options from real root /etc/fstab and then
> > remount real root read-write using correct options. This all got lost
> > when converting to systemd.
> 
> 
> Not true on Fedora even still with 21. The kernel parameter ro is
> present, so dracut mounts root read-only, then reads fstab, then does
> a remount. Fedora is a systemd OS of course.
> 
> 

Does it using systemd *inside* of initrd? From upstream dracut:

    if ! dracut_module_included "systemd"; then
        inst_hook cmdline 95 "$moddir/parse-block.sh"
        inst_hook pre-udev 30 "$moddir/block-genrules.sh"
        inst_hook mount 99 "$moddir/mount-root.sh"
                                    ^^^^^^^^^^^^^ here it does it
    fi

Do you have Fedora specific patches to do it differently?

Re: Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 4:57 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:

> Does it using systemd *inside* of initrd?

I don't know how to find the answer to this. There is an initramfs and
systemd-journald is the first thing (other than kernel) to be found in
dmesg after the initramfs is unpacked, well before root is mounted.



 From upstream dracut:
>
>     if ! dracut_module_included "systemd"; then
>         inst_hook cmdline 95 "$moddir/parse-block.sh"
>         inst_hook pre-udev 30 "$moddir/block-genrules.sh"
>         inst_hook mount 99 "$moddir/mount-root.sh"
>                                     ^^^^^^^^^^^^^ here it does it
>     fi
>
> Do you have Fedora specific patches to do it differently?

No idea.


-- 
Chris Murphy
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Sun, 11 Jan 2015 15:22:54 +0300
Nikolai Zhubr <n-a-zhubr@yandex.ru> пишет:

> Hi,
> 11.01.2015 14:11, Andrei Borzenkov:
> [...]
> > By adding all needed options to rootflags="..." (modify
> > GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
> > in /etc/default/grub; you can use yast for it).
> 
> Ah, indeed.
> Although it feels a bit ugly because the consistency between fstab and 
> GRUB_CMDLINE_* will have to be verified manually forever then.
> 

It's no more ugly than using privately patched distribution package. I
did not suggest it as long term generic solution.

> > Otherwise it is functional gap between non-systemd and systemd
> > enabled dracut. Without systemd dracut will actually mount root
> > read-only, then fetch mount options from real root /etc/fstab and then
> > remount real root read-write using correct options. This all got lost
> > when converting to systemd.
> 
> Hmm, can not find any dracut-specific mailing list to ask. Apparently 
> there is none :(

There is; you keep removing it from Cc.

> Anyway, generally, why not pack a real fstab from the host into initrd 
> then? Or at least one line ("/") from it? Something prohibits this?
> 

Dracut does pack /etc/fstab in initrd if run in host-specific mode,
but right now systemd-fstab-generator will never parse /etc/fstab
for /sysroot mounts. Pre-systemd dracut would actually merge options
from rootfs /etc/fstab and rootflags.

Even if you add additional parsing of in-initrd /etc/fstab, it still
means you need to regenerate initrd every time you change /etc/fstab so
you still have the same problem as when explicitly adding rootflags -
keeping both in sync :) 
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
11.01.2015 15:54, Andrei Borzenkov:
> It's no more ugly than using privately patched distribution package. I
> did not suggest it as long term generic solution.

Yes, absolutely. Therefore I'm reading all the answers to find a 
reasonable workaround and avoid whatever ugly patching.

>>> Otherwise it is functional gap between non-systemd and systemd
>>> enabled dracut. Without systemd dracut will actually mount root
>>> read-only, then fetch mount options from real root /etc/fstab and then
>>> remount real root read-write using correct options. This all got lost
>>> when converting to systemd.
>>
>> Hmm, can not find any dracut-specific mailing list to ask. Apparently
>> there is none :(
>
> There is; you keep removing it from Cc.

Oh. Sorry! :(

[...]
> Even if you add additional parsing of in-initrd /etc/fstab, it still
> means you need to regenerate initrd every time you change /etc/fstab so
> you still have the same problem as when explicitly adding rootflags -
> keeping both in sync :)

Well, doing "mkinitrd" is not a problem? It has to be rerun in case of 
some other changes too. And Yast anyway has to know when it is necessary 
to run mkinitrd in order to apply changes I'd suppose? (I'm trying to 
check this now; I think I recall Yast used to be quite smart about it)


Thank you,
Nikolai
>
>

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: Second (erroneous) check of rootfs?

[Harald Hoyer]

On 11.01.2015 12:57, Andrei Borzenkov wrote:
> Does it using systemd *inside* of initrd? From upstream dracut:
> 
>     if ! dracut_module_included "systemd"; then
>         inst_hook cmdline 95 "$moddir/parse-block.sh"
>         inst_hook pre-udev 30 "$moddir/block-genrules.sh"
>         inst_hook mount 99 "$moddir/mount-root.sh"
>                                     ^^^^^^^^^^^^^ here it does it
>     fi

In Fedora systemd is used in the initramfs.

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel