Discussion:
initrd mount wrongly unmounted during bootup
(too old to reply)
A***@selinc.com
2015-03-11 18:26:52 UTC
Permalink
I'm working with an embedded device that mounts / and /var in initrd. It
then switches root and fires up systemd. Early in the boot, after paths
target, /var gets unmounted. I want systemd to not do that, but I can't
figure out how to stop it.
I would like systemd to leave /var mounted, but still unmount it during
shutdown. I would rather not move the mounting of /var out of initrd. Is
this possible?
I'm trying to use a very stripped down systemd. As minimal as possible.
I'm using systemd-219. The logs say that var.mount is bound to an inactive
unit, and it is stopping too. I assume that is why /var gets unmounted,
but I don't know what to do to stop it. There is no /etc/fstab file. There
is no var.mount file.
I assume I'm either missing something simple, or it is not possible.
# systemctl --all
...
var.mount loaded
inactive dead /var
...

# journalctl
...
systemd[1]: Unit var.mount is bound to inactive unit. Stopping, too.
...
systemd[1]: Reached target Paths.
systemd[1]: Starting Paths.
systemd[1]: Unmounting /var...
systemd[1]: Unmounted /var.
systemd[1]: Created slice System Slice.
Andrei Borzenkov
2015-03-12 03:44:28 UTC
Permalink
В Wed, 11 Mar 2015 11:26:52 -0700
Post by A***@selinc.com
I'm working with an embedded device that mounts / and /var in initrd. It
then switches root and fires up systemd. Early in the boot, after paths
target, /var gets unmounted. I want systemd to not do that, but I can't
figure out how to stop it.
I would like systemd to leave /var mounted, but still unmount it during
shutdown. I would rather not move the mounting of /var out of initrd. Is
this possible?
I'm trying to use a very stripped down systemd. As minimal as possible.
Do you use udev in initrd?
Post by A***@selinc.com
I'm using systemd-219. The logs say that var.mount is bound to an inactive
unit, and it is stopping too. I assume that is why /var gets unmounted,
but I don't know what to do to stop it. There is no /etc/fstab file. There
is no var.mount file.
I assume I'm either missing something simple, or it is not possible.
Did you try this commit?


commit 628c89cc68ab96fce2de7ebba5933725d147aecc
Author: Lennart Poettering <***@poettering.net>
Date: Fri Feb 27 21:55:08 2015 +0100

core: rework device state logic

This change introduces a new state "tentative" for device units. Device
units are considered "plugged" when udev announced them, "dead" when
they are not available in the kernel, and "tentative" when they are
referenced in /proc/self/mountinfo or /proc/swaps but not (yet)
announced via udev.

This should fix a race when device nodes (like loop devices) are created
and immediately mounted. Previously, systemd might end up seeing the
mount unit before the device, and would thus pull down the mount because
its BindTo dependency on the device would not be fulfilled.
A***@selinc.com
2015-03-12 15:42:15 UTC
Permalink
Date: 03/11/2015 08:44 PM
Subject: Re: [systemd-devel] initrd mount wrongly unmounted during
bootup
÷ Wed, 11 Mar 2015 11:26:52 -0700
Post by A***@selinc.com
I'm working with an embedded device that mounts / and /var in initrd.
It
Post by A***@selinc.com
then switches root and fires up systemd. Early in the boot, after
paths
Post by A***@selinc.com
target, /var gets unmounted. I want systemd to not do that, but I
can't
Post by A***@selinc.com
figure out how to stop it.
I would like systemd to leave /var mounted, but still unmount it
during
Post by A***@selinc.com
shutdown. I would rather not move the mounting of /var out of initrd.
Is
Post by A***@selinc.com
this possible?
I'm trying to use a very stripped down systemd. As minimal as
possible.
Do you use udev in initrd?
No. initrd is a custom script I wrote, and it mounts devtmpfs for its
devices.
Post by A***@selinc.com
I'm using systemd-219. The logs say that var.mount is bound to an
inactive
Post by A***@selinc.com
unit, and it is stopping too. I assume that is why /var gets
unmounted,
Post by A***@selinc.com
but I don't know what to do to stop it. There is no /etc/fstab file.
There
Post by A***@selinc.com
is no var.mount file.
I assume I'm either missing something simple, or it is not possible.
Did you try this commit?
commit 628c89cc68ab96fce2de7ebba5933725d147aecc
...snip...
I was finally able to get /var to stay mounted when I included the
local-fs.target and local-fs-pre.target units on the device. Apparently
they are used magically by systemd. I'm not sure why or how, but it does
finally work, so I'm happy. This leads to my other question about what
units are required. I'll continue on that discussion on that thread.
A***@selinc.com
2015-04-27 18:47:41 UTC
Permalink
I applied commit 628c89cc68ab96fce2de7ebba5933725d147aecc - core: rework
device state logic, but now I'm left with a random chance to boot or not.

Some boots it comes up with "/var mounted" and lots of nice colored "[ OK
]"s.

Some boots it comes up with "Unit var.mount is bound to inactive unit
/dev/mapper/<name>. Stopping, too." and no colored "[ OK ]"s and about
half the logs; only the "systemd[1]" messages, and it just hangs at some
point; it never reaches the default target.

I create /dev/mapper/<name> in initrd with cryptsetup, and then mount it
to /newroot/var before switching root to /newroot and running systemd. I
don't use systemd in initrd.

Am I going about this wrong? What am I doing wrong here? What is the best
way to mount /var in initrd and make systemd happy?


PS - I also added a commit to log what the inactive unit was.
Post by A***@selinc.com
Post by Andrei Borzenkov
Post by A***@selinc.com
I'm working with an embedded device that mounts / and /var in
initrd. It
Post by A***@selinc.com
Post by Andrei Borzenkov
Post by A***@selinc.com
then switches root and fires up systemd. Early in the boot, after
paths
Post by A***@selinc.com
Post by Andrei Borzenkov
Post by A***@selinc.com
target, /var gets unmounted. I want systemd to not do that, but I
can't
Post by A***@selinc.com
Post by Andrei Borzenkov
Post by A***@selinc.com
figure out how to stop it.
I would like systemd to leave /var mounted, but still unmount it
during
Post by A***@selinc.com
Post by Andrei Borzenkov
Post by A***@selinc.com
shutdown. I would rather not move the mounting of /var out of
initrd. Is
Post by A***@selinc.com
Post by Andrei Borzenkov
Post by A***@selinc.com
this possible?
I'm trying to use a very stripped down systemd. As minimal as
possible.
Post by A***@selinc.com
Post by Andrei Borzenkov
Do you use udev in initrd?
No. initrd is a custom script I wrote, and it mounts devtmpfs for its
devices.
Post by A***@selinc.com
Post by Andrei Borzenkov
Post by A***@selinc.com
I'm using systemd-219. The logs say that var.mount is bound to
an inactive
Post by Andrei Borzenkov
Post by A***@selinc.com
unit, and it is stopping too. I assume that is why /var gets
unmounted,
Post by A***@selinc.com
Post by Andrei Borzenkov
Post by A***@selinc.com
but I don't know what to do to stop it. There is no /etc/fstab
file. There
Post by Andrei Borzenkov
Post by A***@selinc.com
is no var.mount file.
I assume I'm either missing something simple, or it is not possible.
Did you try this commit?
commit 628c89cc68ab96fce2de7ebba5933725d147aecc
...snip...
I was finally able to get /var to stay mounted when I included the
local-fs.target and local-fs-pre.target units on the device.
Apparently they are used magically by systemd. I'm not sure why or
how, but it does finally work, so I'm happy. This leads to my other
question about what units are required. I'll continue on that
discussion on that thread.
Lennart Poettering
2015-04-27 19:47:38 UTC
Permalink
Post by A***@selinc.com
I applied commit 628c89cc68ab96fce2de7ebba5933725d147aecc - core: rework
device state logic, but now I'm left with a random chance to boot or not.
Some boots it comes up with "/var mounted" and lots of nice colored "[ OK
]"s.
Some boots it comes up with "Unit var.mount is bound to inactive unit
/dev/mapper/<name>. Stopping, too." and no colored "[ OK ]"s and about
half the logs; only the "systemd[1]" messages, and it just hangs at some
point; it never reaches the default target.
I create /dev/mapper/<name> in initrd with cryptsetup, and then mount it
to /newroot/var before switching root to /newroot and running systemd. I
don't use systemd in initrd.
Make sure to apply 496068a8288084ab3ecf8b179a8403ecff1a6be8
and f62009410a72f5a89bfb8fdd7e48d9d472a6887b.

Also make sure you have LVM/DM compiled with proper udev support.


Lennart
--
Lennart Poettering, Red Hat
A***@selinc.com
2015-04-29 19:09:37 UTC
Permalink
Post by Lennart Poettering
Post by A***@selinc.com
I applied commit 628c89cc68ab96fce2de7ebba5933725d147aecc - core: rework
device state logic, but now I'm left with a random chance to boot or not.
Some boots it comes up with "/var mounted" and lots of nice colored "[ OK
]"s.
Some boots it comes up with "Unit var.mount is bound to inactive unit
/dev/mapper/<name>. Stopping, too." and no colored "[ OK ]"s and about
half the logs; only the "systemd[1]" messages, and it just hangs at some
point; it never reaches the default target.
I create /dev/mapper/<name> in initrd with cryptsetup, and then mount it
to /newroot/var before switching root to /newroot and running systemd. I
don't use systemd in initrd.
Make sure to apply 496068a8288084ab3ecf8b179a8403ecff1a6be8
and f62009410a72f5a89bfb8fdd7e48d9d472a6887b.
Also make sure you have LVM/DM compiled with proper udev support.
Thanks for hearing me out on this.

I applied those other commits you listed, and I took a look at the lvm2
package, which was being compile with "--disable-udev_sync" and "
--disable-udev_rules". I enabled both of those and recompiled both lvm2
and systemd.

Nothing changed. Sometimes var.mount is still bound to an inactive
/dev/mapper/<name>.

Do I need the *.rules files from lvm2?

So an additional question, is it a requirement to use udev in initrd where
/var is decrypted and mounted? I currently wasn't doing so. I just use
whatever devtmpfs gave me.
Lennart Poettering
2015-04-30 09:39:45 UTC
Permalink
Post by A***@selinc.com
I applied those other commits you listed, and I took a look at the lvm2
package, which was being compile with "--disable-udev_sync" and "
--disable-udev_rules". I enabled both of those and recompiled both lvm2
and systemd.
Nothing changed. Sometimes var.mount is still bound to an inactive
/dev/mapper/<name>.
Well, it will be bound to it, but systemd should not act on it
anymore and unmount it.

Also, th device should become active as soon as udev ran and reprobed everything.
Post by A***@selinc.com
Do I need the *.rules files from lvm2?
Well, you do need the DM ones at least. That's actually where the
interesting bits are sicne they properly probe the LUKS device and
make it available for other components including systemd to pick it up.

Lennart
--
Lennart Poettering, Red Hat
A***@selinc.com
2015-04-30 22:20:57 UTC
Permalink
Post by Lennart Poettering
Post by A***@selinc.com
I applied those other commits you listed, and I took a look at the lvm2
package, which was being compile with "--disable-udev_sync" and "
--disable-udev_rules". I enabled both of those and recompiled both lvm2
and systemd.
Nothing changed. Sometimes var.mount is still bound to an inactive
/dev/mapper/<name>.
Well, it will be bound to it, but systemd should not act on it
anymore and unmount it.
Also, th device should become active as soon as udev ran and
reprobed everything.
Post by A***@selinc.com
Do I need the *.rules files from lvm2?
Well, you do need the DM ones at least. That's actually where the
interesting bits are sicne they properly probe the LUKS device and
make it available for other components including systemd to pick it up.
I added a couple udev rules that are present in the Ubuntu dmsetup package
for my distribution, and now I get a couple errors from systemd-udevd:

systemd-udevd[153]: conflicting device node
'/dev/mapper/91caea2d-0e19-441e-9ea7-7be1ed345e96' found, link to
'/dev/dm-1' will not be created
systemd-udevd[154]: conflicting device node
'/dev/mapper/d8668b2e-3a40-46df-8c64-f369a1a7a09c' found, link to
'/dev/dm-0' will not be created

With status as:

dev-mapper-91caea2d\x2d0e19\x2d441e\x2d9ea7\x2d7be1ed345e96.device
loaded activating tentative
/dev/mapper/91caea2d-0e19-441e-9ea7-7be1ed345e96
dev-mapper-d8668b2e\x2d3a40\x2d46df\x2d8c64\x2df369a1a7a09c.device
loaded activating tentative
/dev/mapper/d8668b2e-3a40-46df-8c64-f369a1a7a09c

The system seems to work just fine though, so I'm wondering if I should
ignore these errors and move on. I'm sure what the impact is.
Lennart Poettering
2015-05-06 17:06:20 UTC
Permalink
Post by A***@selinc.com
Post by Lennart Poettering
Post by A***@selinc.com
I applied those other commits you listed, and I took a look at the
lvm2
Post by Lennart Poettering
Post by A***@selinc.com
package, which was being compile with "--disable-udev_sync" and "
--disable-udev_rules". I enabled both of those and recompiled both
lvm2
Post by Lennart Poettering
Post by A***@selinc.com
and systemd.
Nothing changed. Sometimes var.mount is still bound to an inactive
/dev/mapper/<name>.
Well, it will be bound to it, but systemd should not act on it
anymore and unmount it.
Also, th device should become active as soon as udev ran and
reprobed everything.
Post by A***@selinc.com
Do I need the *.rules files from lvm2?
Well, you do need the DM ones at least. That's actually where the
interesting bits are sicne they properly probe the LUKS device and
make it available for other components including systemd to pick it up.
I added a couple udev rules that are present in the Ubuntu dmsetup package
systemd-udevd[153]: conflicting device node
'/dev/mapper/91caea2d-0e19-441e-9ea7-7be1ed345e96' found, link to
'/dev/dm-1' will not be created
systemd-udevd[154]: conflicting device node
'/dev/mapper/d8668b2e-3a40-46df-8c64-f369a1a7a09c' found, link to
'/dev/dm-0' will not be created
dev-mapper-91caea2d\x2d0e19\x2d441e\x2d9ea7\x2d7be1ed345e96.device
loaded activating tentative
/dev/mapper/91caea2d-0e19-441e-9ea7-7be1ed345e96
dev-mapper-d8668b2e\x2d3a40\x2d46df\x2d8c64\x2df369a1a7a09c.device
loaded activating tentative
/dev/mapper/d8668b2e-3a40-46df-8c64-f369a1a7a09c
The system seems to work just fine though, so I'm wondering if I should
ignore these errors and move on. I'm sure what the impact is.
If they stay tentative then this isn't working correctly. After udev
is up and probed the devcies they should really be set to "plugged"
and not "tentative" anymore. There's something still wrong with your
udev rules I fear...

Lennart
--
Lennart Poettering, Red Hat
Continue reading on narkive:
Loading...