Skip to contentSkip to conversation

sysroot not mounted in case several rootflags=subvol=@ boot params are passed

DISCUSSION Thomas Renninger 2 participants 3 messages Jan 20, 2014 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

Hi,

due to a bug in another tool it came out that systemd/dracut cannot mount /sysroot if the same rootflags= parameter is passed twice:
rootflags=subvol=@ rootflags=subvol=@

Yep, this should be fixed somewhere else, but I still like to make the /sysroot mount more robust or at least find out what what is going on more detailed.

journalctl -b -u sysroot.mount

Jan 20 15:02:30 localhost systemd[1]: Failed to mount /sysroot.
Jan 20 15:02:30 localhost systemd[1]: Unit sysroot.mount entered failed state.
Jan 20 15:16:46 localhost systemd[1]: Mounting /sysroot...
Jan 20 15:16:46 localhost mount[970]: mount: wrong fs type, bad option, bad superblock on /dev/vda2,
Jan 20 15:16:46 localhost systemd[1]: sysroot.mount mount process exited, code=exited status=32

It looks like in
modules.d/99base/parse-root-opts.sh
rflags is made to "subvol=@,subvol=@"
and
modules.d/95rootfs-block/mount-root.sh
fails due to passing this as -o to mount?

But what I am mostly missing is any dracut warning. I should see:
modules.d/95rootfs-block/mount-root.sh:

    while ! mount -t ${rootfs} -o "$_rflags_ro" "${root#block:}" "$NEWROOT"; do
        warn "Failed to mount -t ${rootfs} -o $_rflags_ro ${root#block:} $NEWROOT"
        fsck_ask_err
    done

?

This would give an obvios hint what is going wrong.

But I cannot find where "warn" is even defined.

Could be that I came on the wrong track somewhere.
I guess there cannot be made much against passing bad (or doubled) rootflags= options, things will simply fail then, right?

Still it would be nice if someone can give me a hint how I can debug similar stuff easier next time.

Thanks!

Thomas

#1 lore raw

В Mon, 20 Jan 2014 17:41:10 +0100
Thomas Renninger <[email protected]> пишет:

Quoted 28 lines

Hi,

due to a bug in another tool it came out that systemd/dracut cannot mount /sysroot if the same rootflags= parameter is passed twice:
rootflags=subvol=@ rootflags=subvol=@

Yep, this should be fixed somewhere else, but I still like to make the /sysroot mount more robust or at least find out what what is going on more detailed.

journalctl -b -u sysroot.mount

Jan 20 15:02:30 localhost systemd[1]: Failed to mount /sysroot.
Jan 20 15:02:30 localhost systemd[1]: Unit sysroot.mount entered

failed state. Jan 20 15:16:46 localhost systemd[1]:
Mounting /sysroot... Jan 20 15:16:46 localhost mount[970]: mount:
wrong fs type, bad option, bad superblock on /dev/vda2, Jan 20 15:16:46 localhost systemd[1]: sysroot.mount mount process exited, code=exited status=32

It looks like in
modules.d/99base/parse-root-opts.sh
rflags is made to "subvol=@,subvol=@"
and
modules.d/95rootfs-block/mount-root.sh
fails due to passing this as -o to mount?

Quoted 8 lines

But what I am mostly missing is any dracut warning. I should see:
modules.d/95rootfs-block/mount-root.sh:

    while ! mount -t ${rootfs} -o "$_rflags_ro" "${root#block:}"

"$NEWROOT"; do warn "Failed to mount -t ${rootfs} -o $_rflags_ro ${root#block:} $NEWROOT" fsck_ask_err
done
?

No. In your case rootflags are handled by systemd-fstab-generator. Comment from systemd sources (src/fstab-generator/fstab-generator.c):

/* root= and roofstype= may occur more than once, the last instance should take precedence.
* In the case of multiple rootflags= the arguments should be
concatenated */

You can see the generated mount unit from emergency shell. It should be located here:
/run/systemd/generator/sysroot.mount

Quoted 19 lines

This would give an obvios hint what is going wrong.

But I cannot find where "warn" is even defined.

Could be that I came on the wrong track somewhere.
I guess there cannot be made much against passing bad (or doubled) rootflags= options, things will simply fail then, right?

Still it would be nice if someone can give me a hint how I can debug similar stuff easier next time.

Thanks!

Thomas
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 1 line
Alexander Tsoy

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw
Quoted 40 lines · On Mon Jan 20 23:40:54 2014 Alexander Tsoy…

В Mon, 20 Jan 2014 17:41:10 +0100
Thomas Renninger <[email protected]> пишет:

Quoted 28 lines

Hi,

due to a bug in another tool it came out that systemd/dracut cannot mount /sysroot if the same rootflags= parameter is passed twice:
rootflags=subvol=@ rootflags=subvol=@

Yep, this should be fixed somewhere else, but I still like to make the /sysroot mount more robust or at least find out what what is going on more detailed.

journalctl -b -u  sysroot.mount

Jan 20 15:02:30 localhost systemd[1]: Failed to mount /sysroot.
Jan 20 15:02:30 localhost systemd[1]: Unit sysroot.mount entered

failed state. Jan 20 15:16:46 localhost systemd[1]:
Mounting /sysroot... Jan 20 15:16:46 localhost mount[970]: mount:
wrong fs type, bad option, bad superblock on /dev/vda2, Jan 20 15:16:46 localhost systemd[1]: sysroot.mount mount process exited, code=exited status=32

It looks like in
modules.d/99base/parse-root-opts.sh
rflags is made to "subvol=@,subvol=@"
and
modules.d/95rootfs-block/mount-root.sh
fails due to passing this as -o to mount?

Quoted 8 lines

But what I am mostly missing is any dracut warning.
I should see:
modules.d/95rootfs-block/mount-root.sh:
while ! mount -t ${rootfs} -o "$_rflags_ro" "${root#block:}" "$NEWROOT"; do warn "Failed to mount -t ${rootfs} -o $_rflags_ro ${root#block:} $NEWROOT" fsck_ask_err
done
?

Quoted 1 line

No. In your case rootflags are handled by systemd-fstab-generator.

And, of course, systemd is actually mounting root fs, not the mount-root.sh script.

Quoted 24 lines

Comment from systemd sources (src/fstab-generator/fstab-generator.c):

/* root= and roofstype= may occur more than once, the last instance should take precedence.
  * In the case of multiple rootflags= the arguments should be concatenated */

You can see the generated mount unit from emergency shell. It should be located here:
/run/systemd/generator/sysroot.mount

Quoted 13 lines

This would give an obvios hint what is going wrong.

But I cannot find where "warn" is even defined.

Could be that I came on the wrong track somewhere.
I guess there cannot be made much against passing bad (or doubled) rootflags= options, things will simply fail then, right?

Still it would be nice if someone can give me a hint how I can debug similar stuff easier next time.

Thanks!

Signature · 1 line
Alexander Tsoy