[arch-projects] [mkinitcpio][PATCH] [WIP] systemd: add systemd hook and needed files

Tom Gundersen teg at jklm.no
Thu Nov 22 13:55:52 EST 2012


On Thu, Nov 22, 2012 at 7:32 PM, Dave Reisner <d at falconindy.com> wrote:
>> Note: generate initramfs with
>>  HOOKS=('base' 'fsck' 'systemd')
>> to get all the needed binaries (such as mount and fsck and busybox for
>> debugging).
>
> This is fine for now, but I think eventually, this should be an alterate
> "base" hook called sd-base, or similar.

Yeah, that makes sense. I thought I'd reuse the old hooks for now
until it is clear exactly what we need. As you note below, the lack of
dependencies between hooks means we'll get quite a bit of duplication.

> None of this stuff is ever installed aside from the install hook.

Yeah, I forgot about changes to the Makefile. I was hoping that all of
this stuff would anyway live in the systemd repo, but we'll see.

> You have /bin/ash from busybox.

Good catch, would have to add a symlink from bash though as that's
what debug-shell.service calls.

> So I guess the goal here is that the systemd hook would replace the udev
> hook? That seems a little weird. We don't have any concept of hook
> dependencies or conflicts (though this part is perhaps intentional)
> which doesn't really help.

Not sure what the best way to go is. I'm tempted to say that all the
things that are needed by this hook should be part of it (as we don't
have deps). Whether or not a separate stand-alone udev hook makes
sense in the long-term, I will leave open...

>> +    # wtf?
>> +    add_file "/etc/passwd"
>> +    add_file "/etc/shadow"
>> +    add_file "/etc/group"
>> +    add_file "/etc/gshadow"
>> +    add_file "/etc/nsswitch.conf"
>> +    # (wtf?)^2
>
> What is it that actually wants these things?

"systemctl switch-root" is not happy without them. I don't understand
1) why not and 2) why the libs are not pulled in. This
<http://randombitsofuselessinformation.blogspot.fr/2007/12/dbus-could-not-get-password-database.html>
outlines the problem.

>> +    add_file "/lib/libnsl-2.16.so"
>> +    add_symlink "/lib/libnsl.so" "libnsl.so.1"
>> +    add_symlink "/lib/libnsl.so.1" "libnsl-2.16.so"
>> +    add_file "/lib/libnss_files-2.16.so"
>> +    add_symlink "/lib/libnss_files.so" "libnss_files.so.2"
>> +    add_symlink "/lib/libnss_files.so.2" "libnss_files-2.16.so"
>
> This makes us need to move in lockstep with glibc. I'm way too lazy for
> that.

Anything marked with "wtf?" should hopefully go away before we ship this ;-)

> Not sure this proposed name is long enough ;P

Hehe, suggestions welcome  :-)

>> +[Unit]
>> +Description=Cleanup udevd DB
>> +DefaultDependencies=no
>> +ConditionPathExists=/etc/initrd-release
>> +Conflicts=systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket
>> +After=systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket
>> +Before=initrd-switch-root.target
>> +
>> +[Service]
>> +Type=oneshot
>> +ExecStart=-/usr/bin/udevadm info --cleanup-db
>
> Why does this need to exist? Can't we just "fix" the systemd-udevd
> service file to do as a PreExecStop= and make initrd-switch-root.target
> provide the right conflicts to trigger that?

PostExecStop I guess? I don't see why it would not work, except that
it would obviously not be specific to the iniramfs, if that matters I
don't know. If I go ahead and submit this upstream I'll suggest the
PostExecStop approach first to see if there are objections.

Thanks for the comments.

-t


More information about the arch-projects mailing list