Discussion:
[systemd-devel] systemd blocks update kernel partition table
e***@gmx.de
2018-11-21 22:26:37 UTC
Permalink
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
e***@gmx.de
2018-11-21 22:38:45 UTC
Permalink
Sorry for my html mail before!

Hi list,
i'm new to systemd and are working with an embedded device with yocto.
 
In my embedded device i want to format and store my emmc device with the new firmware. When updating the firmware the device boots from SD card.
 
When updating the firmware i want to (re)partition my emmc storage device with parted and 3 ext4 partitions. None of the partitions is mounted, because the device boots from SD card.
When the emmc already contains a partition table parted complains that it can't update the kernel partition table after it was modified.
It seems these partitions are already mounted anywhere. partprobe doesn't help either.
 
But i don't mount them and when i check for mounted partitions by mount command, none of them is mounted. The only thing i see is that systemd has created device units for these partitions. In syslog i see that the ext4 partition is recognized (also in /sys/fs/ext4 available). I assume that the systemd device units block the update of the kernel partition table.
 

I need to modify, format and fill the partitions on the emmc without booting after the new partition table is written.
 My question is: What/is systemd blocking the update of the kernel partition table and what can i do to prevent it?
 
Thanks in advance
Eberhard
 
 
Jérémy Rosen
2018-11-22 08:47:23 UTC
Permalink
systemd creates .device for any partition it finds, but that doesn't
mean the partition is mounted.

You should trust "mount" in this case. Your partition is not mounted and
I don't think this is a systemd problem. People on the yocto side are
probably more able to help

now, that being said, I am not sure what "the kernel partition table" is
in this context. I assume parted is trying to refresh the way the kernel
sees the partitions on the eMMC and fails, which would be a pure kernel
problem.

If you repartition your eMMC and then reboot on the sd-card, does your
kernel see the partitions correctly ?
It kinda seems to me that everything is working fine here, and that the
message is a red herring...
Post by e***@gmx.de
Sorry for my html mail before!
Hi list,
i'm new to systemd and are working with an embedded device with yocto.
In my embedded device i want to format and store my emmc device with the new firmware. When updating the firmware the device boots from SD card.
When updating the firmware i want to (re)partition my emmc storage device with parted and 3 ext4 partitions. None of the partitions is mounted, because the device boots from SD card.
When the emmc already contains a partition table parted complains that it can't update the kernel partition table after it was modified.
It seems these partitions are already mounted anywhere. partprobe doesn't help either.
But i don't mount them and when i check for mounted partitions by mount command, none of them is mounted. The only thing i see is that systemd has created device units for these partitions. In syslog i see that the ext4 partition is recognized (also in /sys/fs/ext4 available). I assume that the systemd device units block the update of the kernel partition table.
I need to modify, format and fill the partitions on the emmc without booting after the new partition table is written.
 My question is: What/is systemd blocking the update of the kernel partition table and what can i do to prevent it?
Thanks in advance
Eberhard
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>

20 rue des Jardins
92600 AsniÚres-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email ***@smile.fr <mailto:***@smile.fr>
phone +33141402967
url http://www.smile.eu

Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>


Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planÚte, n'imprimez ce mail que si c'est nécessaire
Eberhard Stoll
2018-11-22 10:39:06 UTC
Permalink
Thanks for your reply!
Post by Jérémy Rosen
systemd creates .device for any partition it finds, but that doesn't
mean the partition is mounted.
You should trust "mount" in this case. Your partition is not mounted and
I don't think this is a systemd problem. People on the yocto side are
probably more able to help
After booting my device over NFS the dmesg log says:

[ 16.226801] EXT4-fs (mmcblk1p1): mounted filesystem with ordered
data mode. Opts: (null)
[ 16.227246] EXT4-fs (mmcblk1p2): mounted filesystem with ordered
data mode. Opts: (null)
[ 16.370595] EXT4-fs (mmcblk1p3): mounted filesystem with ordered
data mode. Opts: (null)

which is my already partitionned emmc device.
When i do a 'mount' command no emmc device is printed out:

***@t1000-multi:~# mount
192.168.1.240:/nfs/t1000-multi-qt on / type nfs
(rw,relatime,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.240,mountvers=1,mountproto=udp,local_lock=all,addr=192.168.1.240)
devtmpfs on /dev type devtmpfs
(rw,relatime,size=153016k,nr_inodes=38254,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2
(rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/debug type cgroup
(rw,nosuid,nodev,noexec,relatime,debug)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
configfs on /sys/kernel/config type configfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /var/volatile type tmpfs (rw,relatime)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=43812k,mode=700)
Post by Jérémy Rosen
now, that being said, I am not sure what "the kernel partition table" is
in this context. I assume parted is trying to refresh the way the kernel
sees the partitions on the eMMC and fails, which would be a pure kernel
problem.
Parted gives this error message when i reset the partition table:
***@t1000-multi:~# parted /dev/mmcblk1 --script mklabel gpt
Error: Partition(s) 1, 2, 3 on /dev/mmcblk1 have been written, but we
have been unable to inform the kernel of the change, probably because
it/they are in use. As a result, the old partition(s) will remain in
use. You should reboot now before making further changes.

Running 'fuser /dev/mmcblkp1' doesn't give any process which occupies my
partitions. In '/sys/fs/ext4' my partitions are recognized:

***@t1000-multi:~# ls /sys/fs/ext4/
features mmcblk1p1 mmcblk1p2 mmcblk1p3
Post by Jérémy Rosen
If you repartition your eMMC and then reboot on the sd-card, does your
kernel see the partitions correctly ?
yes

It seems nothing from userspace holds the partitions. Is there a
possibility for a 'hidden' mount or ext4 fs driver occupies the device
nodes?

Thanks
Eberhard
Mantas Mikulėnas
2018-11-22 11:26:20 UTC
Permalink
Post by Eberhard Stoll
It seems nothing from userspace holds the partitions. Is there a
possibility for a 'hidden' mount or ext4 fs driver occupies the device
nodes?
It could be that they remain mounted within another mount namespace. You
don't have any weird udev rules which call `mount`, do you?

If you have a recent util-linux, run `sudo lsns -t mnt` to see live
namespaces. For each non-kernel process ID in the list, run something like
`findmnt -F /proc/$PID/mountinfo` (or `cat` the file). If you don't, then
`grep mmcblk1 /proc/*/mountinfo` should do the job as well.
--
Mantas Mikulėnas
Eberhard Stoll
2018-11-22 18:57:50 UTC
Permalink
Post by Mantas Mikulėnas
It could be that they remain mounted within another mount namespace. You
don't have any weird udev rules which call `mount`, do you?
If you have a recent util-linux, run `sudo lsns -t mnt` to see live
namespaces. For each non-kernel process ID in the list, run something
like `findmnt -F /proc/$PID/mountinfo` (or `cat` the file). If you
don't, then `grep mmcblk1 /proc/*/mountinfo` should do the job as well.
Yes, i found a udev rule which should mount any usb drive which is
plugged in. This is also true for my emmc device:

# Media automounting
SUBSYSTEM=="block", ACTION=="add" RUN+="/etc/udev/scripts/mount.sh"
SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1"
RUN+="/etc/udev/scripts/mount.sh"

And systemd-udevd is running in an own namespace:
***@t1000-multi:~# lsns -t mnt
NS TYPE NPROCS PID USER COMMAND
4026531840 mnt 88 1 root /sbin/init
4026531861 mnt 1 18 root kdevtmpfs
4026532470 mnt 1 125 root
/lib/systemd/systemd-udevd
4026532483 mnt 1 194 systemd-timesync
/lib/systemd/systemd-timesyncd
4026532484 mnt 1 212 systemd-network
/lib/systemd/systemd-networkd
4026532502 mnt 1 262 systemd-resolve
/lib/systemd/systemd-resolved

I wonder what is the preferred way to automount removable media
especially in embedded devices?

Is using 'MountFlags=shared' for systemd-udevd a common solution? Or
should i prefer systemd automounting?
With systemd automount i have to declare all devices statically. This
could be a disadvantage.

Do you have some hints for me?

Thanks
Eberhard
Mantas Mikulėnas
2018-11-22 19:01:26 UTC
Permalink
Post by Eberhard Stoll
Post by Mantas Mikulėnas
It could be that they remain mounted within another mount namespace. You
don't have any weird udev rules which call `mount`, do you?
If you have a recent util-linux, run `sudo lsns -t mnt` to see live
namespaces. For each non-kernel process ID in the list, run something
like `findmnt -F /proc/$PID/mountinfo` (or `cat` the file). If you
don't, then `grep mmcblk1 /proc/*/mountinfo` should do the job as well.
Yes, i found a udev rule which should mount any usb drive which is
# Media automounting
SUBSYSTEM=="block", ACTION=="add" RUN+="/etc/udev/scripts/mount.sh"
SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1"
RUN+="/etc/udev/scripts/mount.sh"
NS TYPE NPROCS PID USER COMMAND
4026531840 mnt 88 1 root /sbin/init
4026531861 mnt 1 18 root kdevtmpfs
4026532470 mnt 1 125 root
/lib/systemd/systemd-udevd
4026532483 mnt 1 194 systemd-timesync
/lib/systemd/systemd-timesyncd
4026532484 mnt 1 212 systemd-network
/lib/systemd/systemd-networkd
4026532502 mnt 1 262 systemd-resolve
/lib/systemd/systemd-resolved
I wonder what is the preferred way to automount removable media
especially in embedded devices?
Is using 'MountFlags=shared' for systemd-udevd a common solution?
should i prefer systemd automounting?
With systemd automount i have to declare all devices statically. This
could be a disadvantage.
You can use the `systemd-mount` tool if your version comes with it. That
will create a transient .mount unit in systemd via IPC, so it will be
unaffected by namespacing.

Otherwise, no need to bother with MountFlags=, just remove the existing
PrivateMounts=yes option which isolates udev to begin with.
--
Mantas Mikulėnas
Lennart Poettering
2018-11-23 09:26:07 UTC
Permalink
Post by Mantas Mikulėnas
It could be that they remain mounted within another mount namespace. You
don't have any weird udev rules which call `mount`, do you?
If you have a recent util-linux, run `sudo lsns -t mnt` to see live
namespaces. For each non-kernel process ID in the list, run something
like `findmnt -F /proc/$PID/mountinfo` (or `cat` the file). If you
don't, then `grep mmcblk1 /proc/*/mountinfo` should do the job as well.
Yes, i found a udev rule which should mount any usb drive which is plugged
# Media automounting
SUBSYSTEM=="block", ACTION=="add" RUN+="/etc/udev/scripts/mount.sh"
SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1"
RUN+="/etc/udev/scripts/mount.sh"
NS TYPE NPROCS PID USER COMMAND
4026531840 mnt 88 1 root /sbin/init
4026531861 mnt 1 18 root kdevtmpfs
4026532470 mnt 1 125 root /lib/systemd/systemd-udevd
4026532483 mnt 1 194 systemd-timesync
/lib/systemd/systemd-timesyncd
4026532484 mnt 1 212 systemd-network
/lib/systemd/systemd-networkd
4026532502 mnt 1 262 systemd-resolve
/lib/systemd/systemd-resolved
I wonder what is the preferred way to automount removable media especially
in embedded devices?
Is using 'MountFlags=shared' for systemd-udevd a common solution? Or should
i prefer systemd automounting?
With systemd automount i have to declare all devices statically. This could
be a disadvantage.
Do you have some hints for me?
Use the "systemd-mount" tool for removable media. It's *the* tool of
choice, as it will ensure that fsck is run before the media is
mounted, and it will use the kernel's automount logic so that that the
fs appears continously mounted while the file system is actually
unmounted quickly after each access. Both of these means that the best
guarantees tha the fs on the removable remains in a clean state.

systemd-mount also means that fsck/mount are called in service
context as children from PID 1, hence aren't affected by the fs
namespacing applied to udev.

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2018-11-22 09:48:12 UTC
Permalink
Post by e***@gmx.de
Hi list,
i'm new to systemd and are working with an embedded device with yocto.
In my embedded device i want to format and store my emmc device with the
new firmware. When updating the firmware the device boots from SD card.
When updating the firmware i want to (re)partition my emmc storage device
with parted and 3 ext4 partitions. None of the partitions is mounted,
because the device boots from SD card.
When the emmc already contains a partition table parted complains that it
can't update the kernel partition table after it was modified.
It seems these partitions are already mounted anywhere. partprobe doesn't
help either.
But i don't mount them and when i check for mounted partitions by mount
command, none of them is mounted. The only thing i see is that systemd has
created device units for these partitions. In syslog i see that the ext4
partition is recognized (also in /sys/fs/ext4 available). I assume that
the systemd device units block the update of the kernel partition
table.
.device units are just a representation of devices reported by
udev/kernel in the systemd "unit" concept. PID 1 never actually opens
them, it just tracks them. And it hence is not keeping them busy.
Post by e***@gmx.de
I need to modify, format and fill the partitions on the emmc without
booting after the new partition table is written.
My question is: What/is systemd blocking the update of the kernel
partition table and what can i do to prevent it?
I doubt it is. It must be something else.

Use fuser or a similar tool to figure out what is keeping it busy.

Lennart
--
Lennart Poettering, Red Hat
Loading...