dracut

dracut copied to clipboard

The blockdev@.target is a unit made for ordering block devices for systemd services. It seems to be the canonical way of doing this as given in the man page systemd.special. This PR aims to get dracut to use the same target unit throughout in base, as well as in the dracut-systemd module.

Signed-off-by: Savyasachee Jha [email protected]

This pull request changes...

Changes

All instances of initrd.target.wants/<devname>.device replaced with initrd.target.wants/blockdev@<devname>.target. I have tested this locally and seen no breakage in booting.

Checklist

• [X] I have tested it locally
• [ ] I have reviewed and updated any documentation if relevant
• [ ] I am providing new code and test(s) for it

Fixes # Nothing

@savyajha on which distro which has which systemd release did you locally test this on?

On Debian Bullseye, @johannbg. systemd 247 (247.3-6)

@savyajha yeah suspected that's much an old systemd release, if you can, try testing these ( and any future systemd related changes ) on systemd 250+ release which should be available in either Debian unstable/experiment and or both.

I will, thank you for the advice @johannbg. I've got an old desktop lying around somewhere which has Arch on it, I guess it's time to shake the rust off and see if it still works. If it doesn't I'll spin up VMs and experiment.

Regardless, I think that the [email protected] bit remains the same from 247 -> 250. At least, there's no change in the manpages.

I will, thank you for the advice @johannbg. I've got an old desktop lying around somewhere which has Arch on it, I guess it's time to shake the rust off and see if it still works. If it doesn't I'll spin up VMs and experiment.

Regardless, I think that the [email protected] bit remains the same from 247 -> 250. At least, there's no change in the manpages.

Your pr is poking a hornest nest of udev rules and systemd dependencies, the scope of this change is not as simple as reading a man page and perform search and replace.

Systemd's man pages should be quite clear about the intent and purposes of type device units and block device targets and there are things in the code that often cant be found in man pages or changes that work in older release but not newer ones etc.

I shall get back after testing it on a newer machine.

@johannbg I haven't been able to check it with systemd 250 yet, but it works perfectly normally on Fedora 35 (systemd 249 (v249.9-1.fc35)) with a btrfs root.

@johannbg Tested with systemd 250 (250.3-4-arch) on Arch Linux and it boots fine.

@johannbg Apologies for the ping, but does this require any more testing/work from my side? It's been tested on:

• Debian Bullseye (systemd 247)
• Fedora 35 (systemd 249)
• Arch Linux (systemd 250)

and found to cause no issues with booting.

@savyajha there is nothing that you further need to do, it is I that need to find the time to properly look into this ( go through udev rules, systemd type unit dependency, upstream systemd code etc ) but as it stands now there is a high propability it will get nack-ed.

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

A small additional datapoint here: systemd-fstab generator generates <mountpoint>.mount files of the following type (example copied from one of my own systems):

# Automatically generated by systemd-fstab-generator

[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Requires=systemd-fsck@dev-disk-by\x2duuid-a6223870\x2db98c\x2d49bb\x2daa8c\x2dd33466a23ee4.service
After=systemd-fsck@dev-disk-by\x2duuid-a6223870\x2db98c\x2d49bb\x2daa8c\x2dd33466a23ee4.service
After=blockdev@dev-disk-by\x2duuid-a6223870\x2db98c\x2d49bb\x2daa8c\x2dd33466a23ee4.target

[Mount]
Where=<mount point>
What=/dev/disk/by-uuid/a6223870-b98c-49bb-aa8c-d33466a23ee4
Type=xfs
Options=rw,noatime,attr2,inode64,logbufs=8,logbsize=256k,sunit=8192,swidth=16384,noquota,largeio,swalloc,nodev,nosuid

It seems systemd naturally does not use <devname>.device in generated unit files. It uses blockdev@<devname>.target. I do think that is what systemd expects blockdev@<devname>.target to be used for.

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

@savyajha It seems this PR does not break any of the existing tests, but it is hard for me to conclude if the code in this PR at least executed by some of the tests. One way to confirm this is if you intentionally make a typo/bug in your code and confirm that some tests are failing.

In general good to have a test case with PRs.

Also, can you think of an actual benefit for this change (other than source code maintenance and readability). Are they any other executables/tools that could be interfering with .device or take advantage of blockdev@.target

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.