Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#43445 - [systemd] initcpio hook: list added units according to systemctl list-dependencies initrd.target

Attached to Project: Arch Linux
Opened by Alain Kalker (ackalker) - Wednesday, 14 January 2015, 19:40 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 15 March 2015, 14:11 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Please consider restructuring the list of units added with `add_systemd_unit` to be in the order as output by `systemctl list-dependencies initrd.target`.

The structure output by `list-dependencies` appears to be very consistent: the difference between a minimal `base` system made with pacstrap and a fully pimped out system with lots of other packages installed comes down to a few units inserted within the overall structure.

Keeping this structure makes it much easier to troubleshoot (and experiment), as well as find units which need to be added or which can be removed.

Additional info:
* package version(s)
systemd 218-1
mkinitcpio 18-2
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 15 March 2015, 14:11 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Doesn't seem like a good compromise given a number of factors.
Comment by Dave Reisner (falconindy) - Wednesday, 14 January 2015, 19:59 GMT
Agreeing to do this implicitly signs me up for maintaining this list in order for every future release, too. And, what happens if list-dependencies' output order becomes non-deterministic?

I'm hesitant to add more toil to the packaging process for the sake of an infrequent optimization task.
Comment by Alain Kalker (ackalker) - Wednesday, 14 January 2015, 22:53 GMT
Well, I'm assuming that the unit dependencies need to be checked on every new release of systemd anyway, and humans are much better at detecting changes in structure than picking out differences in a jumble of information, I am not so sure if copy-pasting a few lines of text is too much of a burden.

Considering that the current consistency may not hold forever, I think that even keeping the list sorted lexicographically would be a big improvement.
Comment by Dave Reisner (falconindy) - Wednesday, 14 January 2015, 23:20 GMT
Looking at this list, a large amount of it does not belong in the initramfs. For example, there's no reason to include:

systemd-hwdb-update.service
systemd-fs-fuse-connections.mount
sys-kernel-config.mount
sys-kernel-debug.mount
alsa-restore.service
alsa-state.service
(there's others)

And there's units in here which are pulled in because of local configuration. While it's common to my machine, srv-nfs-video.mount probably is rare elsewhere. The ALSA stuff isn't always going to be included... this gets worse the more I look at it.
Comment by Alain Kalker (ackalker) - Thursday, 15 January 2015, 02:19 GMT
Many of these units have conditions like `ConditionPathExists=` which are satisfied only when the rootfs is mounted, so they would not run in initrd anyway. It should not be too hard to exclude them from the list manually.

I think the best starting point is a fresh system with only the `base` group installed, then add units which appear to be needed (installed by packages other than systemd itself).
Comment by Alain Kalker (ackalker) - Saturday, 31 January 2015, 19:09 GMT
Here's a small script which I use when checking unit dependencies. Looking at its output makes it easier to tell which units do or do not belong in initrd.
   sd-list-dependencies-extra (0.7 KiB)
Comment by Dave Reisner (falconindy) - Sunday, 15 March 2015, 14:11 GMT
Sorry, closing this as wontfix -- I only surmise that this is shifting the maintenance burden around for little gain.

Loading...