-
Notifications
You must be signed in to change notification settings - Fork 32
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
LVM VDO not sending "device online events" to LVM ? #52
Comments
Hi @tigerblue77, I saw this thread and meant to reply sooner. I'm still trying to understand what might be going on for you, but wanted to mention that all of the mount options that you listed for the /etc/fstab are not actually needed in the LVM-VDO (or RHEL-8.3+) scenario. We're working to update the docs on that. But you should be able to get away with a basic configuration that looks like:
The need for the additional options previously was because we only had the This behavior has always been present for the LVM-VDO implementation, and I'm a little confused on the need for a lvm2-activation-generator. Prior to us being acquired by Red Hat, we had a number of Debian/Ubuntu deployments that seemed to work fine, but perhaps things have changed over the last few years? |
Hi @rhawalsh, Thanks for taking a look and thanks for your reply. I am currently working on this project, so I will modify my script with your suggestion and tell you directly if it works for me. Edit: yes it works. Thanks. Don't worry, it works like a charm once I add the configuration line
Also, I hope everything is clear on my linked Reddit thread, don't hesitate if you have any question or any question. Thanks again. |
Great!
The systemd mount unit is just an alternative to spelling things in /etc/fstab but with additional controls available just like other systemd units.
Which manipulations are you speaking of? As you can see we have no special requirements on the mount options anymore. It used to be necessary because we didn't have per-device management controls during startup. With the LVM-VDO implementation, the defaults always worked. Unless you're talking about the stuff in your script where you were running things like depmod, etc.. In which case, any time you want to have a kernel module available in the initrd, you'd need to do that. Generally speaking, unless you need it in early boot, I think you'd be ok skipping that step.
I'm not sure... The default configuration in RHEL-based distros works as intended. I'm not sure whether event_activation is enabled or disabled by default there and why it needs to be changed on Debian-based distros.
I don't know who maintains lvm2 in the Debian-based distros. I don't think it's the same group as those who maintain it in RHEL-based distros. If they're using a different default, then maybe they could explain it (or something in their logs might indicate why)
|
Hello @rhawalsh,
Yes I was talking about all of this. Whatever, I just upgraded to Debian 12 with 6.1.37-1 Linux kernel and LVM 2.03.16-2 and now this configuration (with # Previously, setting this to zero would enable static autoactivation
# services (via the lvm2-activation-generator), but the autoactivation
# services and generator have been removed. |
OMG I think I just found... I had to add "kvdo" to Sources : |
Hello everyone,
Still working on my project to make VDO work on my Debian 11(.3), I encountered a problem at first reboot after installation, everything is detailed here, including the fix I found.
Reading this RHEL 8 documentation, I understand that the default behavior is that LVM wait for a "device online event" to mount a logical volume. That's why I'm wondering if my problem is "normal", if I did something wrong or if I'm encountering a VDO bug in which VDO doesn't send this event to LVM, leading LVM not to mount the VDO volume.
Also, don't hesitate to give any advice if I'm doing something wrong or if you have a better solution than the one I found. It's really hard to find up-to-date documentation and to apply it on another system than RHEL so... Help is welcome :)
The text was updated successfully, but these errors were encountered: