-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lvm2: systemd fixes and update #88565
Conversation
- use installTargets again ("install", and "install_systemd_{generators,units,configuration}" when udev is not null) - The call to the blkid binary in lvm2's 13-dm-disk.rules file disappeared (so we don't need to patch in blkid anymore). lvm seems to rely on udev's internal blkid functionality. - Call /run/current-system/systemd/bin/udevadm instead of ${systemd}/bin/udevadm in the lvm activation generator. This is not necessary to break the dependency cycle (as we don't use that file when building without udev), but a good idea anyways - We want to trigger the udevadm of the current system, not the one that lvm was built with.
Otherwise, we end up in a dependency cycle: systemd -> cryptsetup -> lvm -> fetchgit -> git -> openssh -> libfido2 -> hidapi -> libusb -> udev=systemd
I would guess that nobody wanted to check if As for modules — well, I guess this is a necessary step to eventually having a NixOS test for all that… No idea whether addition of more things should be mentioned in release notes (but I am not a user of stable), renaming installed files probably is a good thing to mention. (I wonder if it breaks some rev-deps…) |
I looked a bit more into this. Turns out For turning them off there is The other daemons include some python d-bus stuff and cluster stuff ( As for tests, there is The main hold-up for extending |
There's a circular dependency to systemd via cryptsetup and lvm2 (systemd -> cryptsetup -> lvm2 -> udev=systemd). However, cryptsetup only really needs the devmapper component shipped with lvm2. So build `pkgs.cryptsetup` with a lvm2 that doesn't come with udev.
…yptsetup-generator.c)
This package previously did override the systemd package, and instructed ninja, systemd's previous build system, to only build the cryptsetup-specific systemd generators (plus some rpath massaging, as we didn't use ninja install). Afterwards, users were expected to add this package to their `systemd.generator-packages` (or since https://github.com/NixOS/nixpkgs/pull/65376/files `systemd.packages`) NixOS module options, so systemd will use these generators. As the previous commit added cryptsetup support directly to the systemd package (and pkgs.systemd now already ships the cryptsetup generators), we don't need another package shipping the same generators.
Instead, prompt user to add lvm to systemd.packages, which is a cleaner way, and we don't need to rebuild the world by changing systemd globally. Initially introduced in c0fd887.
We might want to do this conditionally on whether lvm is enabled (or add the lvm system-generators unconditionally, too)
This seems to be mostly used to simplify LV management tasks from a web interface (https://www.redhat.com/archives/linux-lvm/2008-September/msg00029.html), and is as fat as the `lvm` binary itself
Well, maybe it is enough for the first step just not to break the basic operation… So, for this PR what is needed is a release note entry that we rename installed files back to upstream names? |
Enabling dmeventd doesn't actually work right now, because of
Not sure how to fix that while keeping the split outputs. |
@ajs124 I propose checking the outputs, and /why/ there are these circular references. |
It's not that much of a "why", but:
|
Yeah, I dropped If |
The problem isn't only |
I'm not entirely sure which of the components are needed for lvm operation these days - I mostly introduced the multiple outputs to get the closure size down, as systemd only uses the devmapper components shipped inside lvm. |
I'm not sure what either, to be honest.
That's what I assumed. Reducing closure size for something like systemd is always a good idea. The question is where we go from here. I can spend some time to figure out which parts of LVM are relevant for what, which is probably relevant to us in any case. |
I'm all fine with reducing some of the multiple-output stuff, if it's necessary to get LVM to work - if closure sizes are a problem, we can still re-evaluate. Does your PR currently build, and does the new test succeed? In that case, I could cherry-pick this into #66856, possibly squashing some of the changes for readability. Did you check the closure size of the minimal iso before and after this change? |
It doesn't build as is, but probably builds and runs fine without multiple outputs. I haven't checked the closure size yet. Not sure when I'll get around to put some time into this, might not happen before next week, sorry. |
@7c6f434c I incorporated this back into #66856 (comment), feel free to take a look :-) |
Motivation for this change
We're deploying
lvmthin
and they recommend runningdmeventd
, and while there is an option on the lvm2 package, it sort of didn't work.The update is in there, because our current version is from October of 2018.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)This probably needs a changelog entry and some documentation updates, because:
systemd.packages = with pkgs; [ lvm2 ];
andsystemd.sockets."dm-event".wantedBy = [ "sockets.target" ];
. And mabye you also need alvm.conf
. (And alsolvm2.override { enable_dmeventd = true; }
).blk_availability_systemd_red_hat.service
andlvm2_activation_generator_systemd_red_hat
are currently manually installed with these names. Using the upstream install they're simply calledblk-availability.service
andlvm2-activation-generator
.I haven't looked through the commit history that much, but I'm wondering why dmeventd is optional in the first place. Is the difference in closure size really that big?
There's also at least two other lvm daemons (lvmetad and lvmpoold), which we're not shipping right now.
Point 1. above might also warrant the introduction of a small module to configure dmeventd and the other daemons, if anyone is interested in those.