This is mainly for the release media, but is also relevant to the initramfs that is built by genkernel. In the stock one on the livecd, you get spews of errors due to the /dev/nbd* devices existing but not being readable, as below, every time you run one of the LVM tools. ==== nbd0: Attempted send on closed socket end_request: I/O error, dev nbd0, sector 0 ... nbd15: Attempted send on closed socket end_request: I/O error, dev nbd15, sector 0 ==== I've attached an lvm.conf that runs a bit cleaner, with sane defaults for both new installs and reading old disks.
Created attachment 135547 [details] lvm.conf
Wouldn't it be better to get the ebuild/upstream to accept this file? I don't want to have to keep a completely separate config file that can easily be broken in future lvm versions.
If I make the ebuild install it as /etc/lvm/lvm.conf.minimal, would you pick it up from there on the user's system?
I'd really prefer not to do anything of the sort. I am working towards the removal of any code which requires files from the user's system which are not provided by genkernel. I especially don't want to add one-offs that will only have to be removed later. Is there a reason it cannot be a sensible default for the package? Would that exact same reason not make it unsuitable for being a sensible default for genkernel? We pull the user's /etc/lvm/lvm.conf for a reason. We want what the user has configured. In the case of a "genkernel --lvm all" without configuration, it should be a usable default configuration.
99% of users do not touch their lvm.conf, so I'll just make the changes there instead, since you say you'll take the lvm.conf from them. There are two key changes: - ignore nbd devices by default, because of the kernel noise. - explicitly use the LVM2 format when creating new PV/VG/LV entities. (this is esp. important in the livecd env, when they create their systems).
I implemented it in lvm2-2.02.28-r3 now. It provides the slightly changed lvm.conf as the new default (the changes described in comment 5). If genkernel could pull in this new revision, that would be ideal. For genkernel-3.5.0, it should also pick /sbin/lvm.static rather than /sbin/lvm - not sure how best to put that into the dependancy tree. Maybe a block against older genkernel versions?
We don't pull ebuilds for genkernel. Everything provided by genkernel is provided by upstream tarballs or our own tarballs. If I need to pull the config, I can do that. Is it being submitted upstream? Like I said, I don't want to end up maintaining something outside of the main upstream tarball, if I can help it. We can do it for the short term, but I definitely won't let it carry over into genkernel 3.5's codebase. I'm also not going to be pulling *any* LVM binary from the running system in 3.5, but instead will be compiling it on-demand. My goal is pretty simple. I think that genkernel (via ebuild) should provide everything that it needs. If we need device-mapper, we grab the tarball and compile it. That is where I want to be. For files such as configuration files, I'd like the default to pull from the system, but capable of being overridden from genkernel.conf, so people can create a custom config just for their initramfs/livecd/whatever. With 3.5, it won't care so much what's on the live system, except in cases where they need to be somewhat in sync.
By pull ebuilds, I mean that if genkernel is being used with LVM, the user should ideally have a specific revision or newer of LVM on their system, so that the best possible lvm.conf is used. Eg: If LVM, DEPEND on lvm2-2.02.28-r3, and use that /etc/lvm/lvm.conf (esp when you are rolling the release media, but be sure you get the profiles/base/package.use entries with it). The config changes are specifically better defaults for Gentoo. Both RH and Debian ship their LVM configs in separate packages from the LVM binaries, and have them even more heavily customized than we do. Upstream in this case won't take config specialization patches, they say to ship it with the distro packaging.
Well, genkernel will pull the current stable. I've gone and marked -r3 stable in the snapshot. We'll likely want to do the same in the tree. Since the newer lvm ebuilds have this as default, so does genkernel, since we pull lvm.conf from the live system.
So, RESOLVED-FIXED?
Let's say yes...
