[systemd-devel] having trouble hooking into early boot process with local-fs.target

[Mantas Mikulėnas]

On Tue, Aug 23, 2016 at 12:42 PM, Bond Masuda <bond.masuda at jlbond.com>
wrote:

> Hello systemd-devel:
>
> My question to the list might be more "user" oriented, but I did not find
> another list that seemed more appropriate. If my question is best directed
> elsewhere, please let me know. 1st time joining this list, so I don't know
> all the rules yet.
>
> I'm trying to accomplish something using EL7 platform that is a bit
> unorthodox: I want to copy the contents of /etc from a USB flash drive
> early in the boot process onto a ramdisk and mount it over /etc. Under
> normal conditions, I want my system to boot normally. But, in other cases,
> when a USB flash drive is inserted and available during boot, there will be
> a etc.tar.gz file on the USB flash drive that contains the content for /etc
> and I want this content extracted and mounted over /etc as early as
> possible.
>

I think you'll need an initramfs for this; it's already too late to touch
/etc once the regular boot has begun.

Before I explain below what I've tried to do to accomplish my objective, I
> want to mention that my problem is that the results are not consistent. The
> difference is that sometimes it sees the USB flash drive, and sometimes it
> does not. When it does, everything works as i want.So, I suspect a race
> condition between steps of the boot up sequence since systemd runs things
> in parallel.
>

AFAIK, those requirements are somewhat contradictory because USB device
scanning is not immediate, so the boot process has to either explicitly
*wait* a few seconds, before doing anything else, or deal with the devices
appearing at various times.

3) the script "usb-load-etc" uses 'lsblk' to look for a usb disk, and then
> looks for partitions contained on those usb disks. it then sequentially
> mounts each partition to look for the file etc.tar.gz. if it doesn't find
> it, it umount the partition and tries the next. if it does find the file
> etc.tar.gz, it creates a ramdisk /dev/ram0, mkfs /dev/ram0, mounts it on
> /mnt and extracts the etc.tar.gz on to it. then it umount /mnt and mounts
> /dev/ram0 over /etc, and umount the usb flash drive partition.
>

(ramdisk? why not tmpfs?)

As I've already mentioned, this does work sometimes. As I understand it,
> local-fs.target is wanted by sysinit.target, which also wants
> systemd-modules-load.service. So, I thought maybe my problem is that the
> usb_storage driver was not loading fast enough sometimes, and so I tried
> adding systemd-modules-load.service to "After=" in my usb-load-etc.service.
> Unfortunately, that did not help.
>

systemd-modules-load only handles static configuration from modules-load.d
– it isn't involved with usb_storage unless you *ask* it to load
usb_storage.

Normally hotplug modules are loaded by udev when the kernel sees a USB
device and requests them, so there *isn't* a single point in time where
"everything has been loaded". Depending on systemd-udev-settle.service
*might* be close enough, but it's a bit too broad and will wait for
everything, not only USB.

You could use modules-load.d, or compile in USB drivers statically (if that
changes anything?), or use After=dev-disk-by\x2dpath-[…].device.

I would appreciate any advice or suggestions to help me accomplish my
> objective here.
>

It sounds like a custom initramfs should be able to do this... Initramfs
runs before everything else by definition, its main job *is* to prepare and
mount rootfs and all 'critical' filesystems, and many initramfs frameworks
already have functions to wait for a specific USB device.

/etc is quite special anyway (among other things, that's where parts of
systemd's configuration live as well) – it's on the same level as /usr, and
various Linux distros have already decided to require split /usr to be
pre-mounted by initramfs.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160823/c084bd25/attachment.html>