According to policy: " The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed. " [1] Since the dracut binary is a shell script, it does not link to any of the dependencies in the ebuild. They are needed by dracut modules which are installed into the initramfs if the user requests it in /etc/dracut.conf. Also, by deleting dracut modules that are not enabled by use flags, the current ebuild forces users to do runtime configuration at emerge time, thus creating extra configuration for the package. I agree that post install messages might not be a good way to comunicate this type of information to the user; however, this is a documentation issue, not something that should be solved by violating our use flags policy. @qa: I will propose a patch for this issue shortly. @aidecoe, @alexander: Please add your comments as well. [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html
My second concern about this ebuild is more a best practices concern, so it may not belong on this bug. I noticed a lot of epatch calls in src_prepare. It is possible to do all of that patching in one call and use a patch tarball. I am willing to explain how to do that if the maintainers are interested, but it isn't required to close this bug.
(In reply to William Hubbs from comment #0) > @qa: > I will propose a patch for this issue shortly. No need for a patch. I am fully aware that I am violating QA. My reason for it is that there's no other automated mechanism to communicate with users about additional dependencies. It is PITA to maintain dependencies manually. It is a double work both for maintainer and user: maintainer must manually check if all suggested dependencies are still valid (repoman doesn't check postinst elog string) and user needs to manually install/remove dependencies afterwards. If the report is an ultimatum I can change ebuild myself, no need for a patch. Wrt epatch - patches have been added incrementally. Next version bump will solve this issue.
(In reply to Amadeusz Żołnowski from comment #2) > (In reply to William Hubbs from comment #0) > > @qa: > > I will propose a patch for this issue shortly. > > No need for a patch. I am fully aware that I am violating QA. My reason for > it is that there's no other automated mechanism to communicate with users > about additional dependencies. It is PITA to maintain dependencies manually. The dependencies you are speaking of are more like suggested runtime dependencies. The check() functions in the Dracut modules will not allow the modules to be installed into the initramfs if the host system doesn't meet the module's requirements, e.g. if the "lvm" binary doesn't exist on the host, the lvm module will not be installed in the initramfs, but Dracut will still build the initramfs. This should be fine though since the host is not using lvm if it isn't installed. Although these are suggested dependencies, Dracut runs successfully without them. > It is a double work both for maintainer and user: maintainer must manually > check if all suggested dependencies are still valid (repoman doesn't check > postinst elog string) and user needs to manually install/remove dependencies > afterwards. I'll state my position, and if you would like to wait for the qa lead to respond, you are welcome to do that. You are correct that portage does not have suggested dependencies. However, policy does not allow you to use optional runtime dependencies to emulate suggested dependencies either, so I feel that all of the code for these RDEPENDs should be removed from the ebuild. debug device-mapper net selinux ${IUSE_DRACUT_MODULES} For the selinux flag, the dependency on libselinux should go in CDEPEND if the Dracut code links to the library, which I did not see. Also, I feel that the code that checks these use flags and deletes Dracut modules based on whether the use flags are set or not should be removed. Please write back and let me know if you are going ahead or if you want to wait for the lead to respond. Thanks, William
(In reply to William Hubbs from comment #3) > The check() functions in the Dracut modules will not allow the modules to be > installed into the initramfs [...] > Although these are suggested dependencies, Dracut runs successfully without > them. Yes. I know Dracut internals, no need to explain me... > > It is a double work both for maintainer and user: maintainer must manually > > check if all suggested dependencies are still valid (repoman doesn't check > > postinst elog string) and user needs to manually install/remove dependencies > > afterwards. > > I'll state my position, and if you would like to wait for the qa lead to > respond, you are welcome to do that. OK, I will wait. > You are correct that portage does not have suggested dependencies. > > However, policy does not allow you to use optional runtime dependencies to > emulate suggested dependencies either, so I feel that all of the code for > these RDEPENDs should be removed from the ebuild. Policy… but I don't recall users complaining on my approach. This is for users, not for policy. But I see this is an ultimatum and the only choice I have is on who is cutting it off, so let me do that.
You may want to have a look at the optfeature function in the netctl-1.4.ebuild It's the best approach to runtime dependencies in postinst messages I've seen so far.
(In reply to Amadeusz Żołnowski from comment #4) > Policy… but I don't recall users complaining on my approach. This is for > users, not for policy. But I see this is an ultimatum and the only choice I > have is on who is cutting it off, so let me do that. I'm sorry you see this as an ultimatum. Yes, it is something that needs to be fixed, but the idea of QA is to assist developers with fixing things, not to hand down ultimatums. In other words, we are all a team. That is why I opened a bug and offered to post a patch, so we could discuss things openly.
*QA lead hat on* Two things to note here. First, William is correct, this should not be understood as an ultimatum or us being angry with you. We're here to work with you to fix the issue. Since this isn't an issue that is breaking the tree right now, it can wait for a new dracut version to come out or something, and we're not giving you a deadline or anything like that. Second, users generally won't complain about QA issues, those are more in the realm of devs. As for suggested fixes, readme.gentoo.eclass could work (giving people a map of "if you want x to work, install package y"). This is something I'm going to bring up at the next QA meeting, how to standardize displaying suggested dependencies. As for deleting modules, I concur with William; that should be done at runtime.
I just don't agree on changing this until portage supports suggested-dependencies. Moving dependencies from code to README/elog/posinstmsg (which many users don't read) is not a fix. It's a workaround not better than the one I have used. So basically we're not fixing anything that way, just juggling with workarounds. Thanks for bringing readme.gentoo.eclass up, I have forgot about that one. poncho - thanks for pointing good example, looks promising.
Speaking as a hypothetical user of dracut: The use flags and optional runtime deps do not bother me so much; I just find it strange to remove the modules when those use flags are disabled. If I happen to have btrfs-utils installed, why do I need to set DRACUT_MODULES and re-install dracut? Maybe there is a good reason for it, but I don't see it at a glance.
(In reply to Mike Gilbert from comment #9) > Speaking as a hypothetical user of dracut: The use flags and optional > runtime deps do not bother me so much; I just find it strange to remove the > modules when those use flags are disabled. > > If I happen to have btrfs-utils installed, why do I need to set > DRACUT_MODULES and re-install dracut? Maybe there is a good reason for it, > but I don't see it at a glance. You shouldn't. Also, since you already have btrfs-utils installed, it does not need to be a dependency of Dracut.
(In reply to poncho from comment #5) > You may want to have a look at the optfeature function in the > netctl-1.4.ebuild > > It's the best approach to runtime dependencies in postinst messages I've > seen so far. I just looked at this, and I like this approach as well. It could even be improved so that it doesn't output any message if the optional package is already installed.
(In reply to Amadeusz Żołnowski from comment #8) > I just don't agree on changing this until portage supports > suggested-dependencies. Moving dependencies from code to > README/elog/posinstmsg (which many users don't read) is not a fix. It's a > workaround not better than the one I have used. So basically we're not > fixing anything that way, just juggling with workarounds. > > Thanks for bringing readme.gentoo.eclass up, I have forgot about that one. > poncho - thanks for pointing good example, looks promising. Yes, but unless you're planning to write a patch to Portage to allow SDEPEND, that's probably not happening anytime soon. The devmanual policy is clear: "The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed." The appropriate (and agreed-upon) solution is a post-install message. There are several options; now that I've seen that optfeature() function I really like it, but elogs and readme.gentoo are also appropriate, and I think any of these is a suitable replacement for a theoretical SDEPEND. This doesn't seem like a case that should get an exception, since I don't think it's likely that people would try to create an initramfs with lvm support unless they had lvm installed, for example.
@aidecoe: I would like to meet up with you in the next few days on IRC and chat about this bug. My timezone is utc-6, what is yours, and when could we chat? Thanks, William
I have spoken with aidecoe, and we have agreed to meet on Wednesday at 19:00 UTC.
(In reply to William Hubbs from comment #0) > @aidecoe, @alexander: > Please add your comments as well. I'm fine with that change and agree with QA team. <offtop>But don't apply these rules to all packages, please. IMO, gajim is a good example of package where optional runtime deps are justified and it is odd to have them all in a world file (dev-python/*, net-libs/*, etc).</offtop>
Created attachment 369100 [details] dracut-036.ebuild Here is my version of the dracut ebuild. It is not quite complete, because I don't know how you want to do the warnings in postinst. Also please look through it and expand the comments a bit where I have QA: It would be good for someone to know why those things are being done. Also, I'm not really comfortable with modules being deleted. Does dracut make initramfs images that do not work with all of the modules installed? If not, is there any harm in removing the rest of the code that deletes modules? Thanks, and I'll talk to you soon. William
> # QA: Why do we need this? > local libdirs="/$(get_libdir) /usr/$(get_libdir)" > [[ $libdirs =~ /lib\ ]] || libdirs+=" /lib /usr/lib" > einfo "Setting libdirs to \"${libdirs}\" ..." > sed -e "3alibdirs=\"${libdirs}\"" \ > -i "${S}/dracut.conf.d/gentoo.conf.example" || die We don't want/need libraries for non-native ABIs in initramfs. Expanded answer: Setting $libdirs in gentoo.conf fixes 2 issues introduced by commit [1]: 1. Libraries for non-native ABIs are included into initramfs. This issue was fixed for some distributions by commit [2], but not for Gentoo, where ldconfig_paths() returns /lib32 and /usr/lib32 on multilib systems. 2. All $libdirs are created in initramfs. Since most of them remains empty (useless), it is annoying to some users. [1] http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=4fe1bdd406602922a55ef4f7d6a13e13dfd1b87f [2] http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=1d50dfe6025126c38b1d23815360bd48e9e8c24c
(In reply to Alexander Tsoy from comment #17) > > # QA: Why do we need this? > > local libdirs="/$(get_libdir) /usr/$(get_libdir)" > > [[ $libdirs =~ /lib\ ]] || libdirs+=" /lib /usr/lib" > > einfo "Setting libdirs to \"${libdirs}\" ..." > > sed -e "3alibdirs=\"${libdirs}\"" \ > > -i "${S}/dracut.conf.d/gentoo.conf.example" || die > > We don't want/need libraries for non-native ABIs in initramfs. > > > Expanded answer: > Setting $libdirs in gentoo.conf fixes 2 issues introduced by commit [1]: > 1. Libraries for non-native ABIs are included into initramfs. This issue was > fixed for some distributions by commit [2], but not for Gentoo, where > ldconfig_paths() returns /lib32 and /usr/lib32 on multilib systems. > 2. All $libdirs are created in initramfs. Since most of them remains empty > (useless), it is annoying to some users. Is it really safe to assume that we will never want library directories for non-native abi's in the initramfs? I think we shouldn't assume that, because we do not know what a user might want to add to the initramfs. If upstream is blocking it, imo that could be a bug. I'm not sure why people would be concerned about empty directories in the initramfs; it shouldn't cause any errors or breakages for them to be there and they do not take up enough space to speak of.
Commit [2] above makes sense, so let me rephrase my question. Wouldn't it be better to push the fix into upstream Gentoo.conf rather than using sed if that is possible, or better yet, maybe have Dracut remove unnecessary empty directories before it builds the cpio file?
(In reply to William Hubbs from comment #19) > Commit [2] above makes sense, so let me rephrase my question. > > Wouldn't it be better to push the fix into upstream Gentoo.conf rather than > using sed if that is possible, or better yet, maybe have Dracut remove > unnecessary empty directories before it builds the cpio file? This is similar to all other paths setting done further with pkg-config use. It's better not hard-coding such things. Moreover user can change this dirs in config file. If one is able to add something special do initramfs then one is able to edit config file.
(In reply to Amadeusz Żołnowski from comment #20) > This is similar to all other paths setting done further with pkg-config use. > It's better not hard-coding such things. > > Moreover user can change this dirs in config file. If one is able to add > something special do initramfs then one is able to edit config file. Correct: This is similar to all other paths setting done further with pkg-config use. It's better not hard-code such things. Moreover user can change these dirs in config file. If one is able to add something special to initramfs then one is able to edit a config file.
(In reply to William Hubbs from comment #18) > Is it really safe to assume that we will never want library directories for > non-native abi's in the initramfs? I think we shouldn't assume that, because > we do not know what a user might want to add to the initramfs. If a user wants to add 32 bit binary in the initramfs on 64 bit system, then dracut-install will resolve and install all of its dependencies. $libdirs variable is only used by inst_libdir_file() function which in turn is used to install libraries that are not dynamically linked to anything (e.g. libnss*)
I like how current dracut ebuild works with dependencies and like DRACUT_MODULES= USE flags: ability to install only required modules, ability to ensure correctness of installed deps for selected modules and ability to see table of deps are nice and useful. Now dracut ebuild lets users to see features of dracut instantly and verifies system preparedness to use these features: check if deps are installed, have required USE flags enabled, also it is possible to do any other tests per USE flag. Adding these features to package was significant amount of work, so why waste it? I think QA was not violated: USE flags do not only affect RDEPEND, but also change (remove) installed files. Blindly enforcing rules without keeping in mind why these rules were created, what goals their creators tried to achieve and what circumstances existed during rules writing is wrong and can be harmful. As i understand, "no linking => no USE" rule was created for preventing unwanted, useless and long rebuilds of C and C++ packages, especially such huge as libreoffice. Applying this rule to scripting language (where no compilation is done at all and "rebuiling" packages takes near 10 seconds) is not right. Dracut is written in bash with _very_ small part in C, rebuilding it does not take much time even in 10 years old systems.
(In reply to Nikoli from comment #23) > I like how current dracut ebuild works with dependencies and like > DRACUT_MODULES= USE flags: ability to install only required modules, ability > to ensure correctness of installed deps for selected modules and ability to > see table of deps are nice and useful. Now dracut ebuild lets users to see > features of dracut instantly and verifies system preparedness to use these > features: check if deps are installed, have required USE flags enabled, also > it is possible to do any other tests per USE flag. Adding these features to > package was significant amount of work, so why waste it? > I think QA was not violated: USE flags do not only affect RDEPEND, but also > change (remove) installed files. Blindly enforcing rules without keeping in > mind why these rules were created, what goals their creators tried to > achieve and what circumstances existed during rules writing is wrong and can > be harmful. As i understand, "no linking => no USE" rule was created for > preventing unwanted, useless and long rebuilds of C and C++ packages, > especially such huge as libreoffice. Applying this rule to scripting > language (where no compilation is done at all and "rebuiling" packages takes > near 10 seconds) is not right. Dracut is written in bash with _very_ small > part in C, rebuilding it does not take much time even in 10 years old > systems. This would be different if there were upstream configure switches that controlled whether the modules were installed. In this situation, we could write econf $(USE_ENABLE lvm) for example. However There are not; the ebuild deletes modules if you do not have use flags set and does nothing if you do. Here is an example of the concern with this setup. If you have a system that uses lvm, you already have lvm installed, so it doesn't need to be a depend of Dracut at all. Also, Dracut, if installed as upstream recommends, will know that lvm is installed and automatically set up the initramfs to support it. Right now, if you do not set DRACUT_MODULES correctly, you get a broken install out of the box since the lvm module gets removed at build time. Also, you can configure at runtime in /etc/Dracut.conf whether or not you want the lvm module on the initramfs, so the DRACUT_MODULES setting is in affect redundant.
(In reply to Amadeusz Żołnowski from comment #20) > (In reply to William Hubbs from comment #19) > > Commit [2] above makes sense, so let me rephrase my question. > > > > Wouldn't it be better to push the fix into upstream Gentoo.conf rather than > > using sed if that is possible, or better yet, maybe have Dracut remove > > unnecessary empty directories before it builds the cpio file? > > This is similar to all other paths setting done further with pkg-config use. > It's better not hard-coding such things. I don't understand your statement here; you *are* hard coding the setting of LIBDIRS in the config file. I guess this isn't really related to this bug, so let's talk about it on irc. > Moreover user can change this dirs in config file. If one is able to add > something special do initramfs then one is able to edit config file. Yes, users can edit the config file, so why bother running the sed in the first place? But again let's catch up and talk about this.
> If you have a system that uses lvm, you already have lvm installed, so it doesn't need to be a depend of Dracut at all. Disagree with this argument: if i have lvm2 installed, it does not mean i want it in my initramfs, my rootfs can be not in lvm. Consider such situation: 1) /boot partition is small: 16 or 32 MB 2) rootfs is simple ext4 GPT partition, initramfs is used only for loading kernel modules and running fsck 3) several or even all optional dracut deps are installed: lvm2, mdadm, cryptsetup, cifs-utils, dmraid, nfs-utils, multipath-tools and so on 4) hostonly="yes" is not possible, because same initramfs.img should be used in several systems So what will happen? a) With current dracut ebuild user can set DRACUT_MODULES="dash" and be unworried, because he knows that his initramfs.img will be small enough even after installing new packages or updating dracut. b) If DRACUT_MODULES is removed, then user will be really nervous: 1) by default dracut will create huge initramfs.img, most likely it will be bigger then 16 MB. 2) after installing new packages initramfs.img can become bigger: you never know until you rebuild initramfs.img 3) after updating dracut initramfs.img can become bigger, because dracut devs can add new modules and start using new deps, again you will not know until you rebuild initramfs.img So what you suggest will make dracut behaviour unpredictable and force users to dig into dracut sources and have huge omit_dracutmodules= in /etc/dracut.conf
(In reply to Nikoli from comment #26) > > If you have a system that uses lvm, you already have lvm installed, so it doesn't need to be a depend of Dracut at all. > > Disagree with this argument: if i have lvm2 installed, it does not mean i > want it in my initramfs, my rootfs can be not in lvm. --hostonly will handle that. If you use the --hostonly option it only installs the modules and binaries that the specific host needs, unlike the situation you are talking about below. > Consider such situation: > 1) /boot partition is small: 16 or 32 MB > 2) rootfs is simple ext4 GPT partition, initramfs is used only for loading > kernel modules and running fsck > 3) several or even all optional dracut deps are installed: lvm2, mdadm, > cryptsetup, cifs-utils, dmraid, nfs-utils, multipath-tools and so on > 4) hostonly="yes" is not possible, because same initramfs.img should be used > in several systems Here you are talking about a generic initramfs, and those are big. See /usr/share/doc/Dracut-${PV}/README.generic. Those have to be able to boot on any system with any setup. > So what will happen? > > a) With current dracut ebuild user can set DRACUT_MODULES="dash" and be > unworried, because he knows that his initramfs.img will be small enough even > after installing new packages or updating dracut. Like I said above, --hostonly takes care of this, and --hostonly also has a configuration setting in Dracut.conf. I guess the real question here is what is the default setting for it? > So what you suggest will make dracut behaviour unpredictable and force users > to dig into dracut sources and have huge omit_dracutmodules= in > /etc/dracut.conf I disagree with you, based on the hostonly function. If a user is building a generic initramfs, yes, those are big, but there is no way around that. If you are building one specific to the host, it will not be over 10 mb by default.
(In reply to William Hubbs from comment #24) > Right now, if you do not set DRACUT_MODULES correctly, you get a broken > install out of the box since the lvm module gets removed at build time. The "word" broken is inappropriate here. There's no way you can install dracut with broken module set - it's controlled by REQUIRED_USE. Both QA and Nikoli make some good points about current ebuild. I am still not sure if QA way is the good way to go here. What about voting or something?
I spoke with Nikoli personally and explained the upstream solution for his question, which is the use of omit_dracutmodules in /etc/dracut.conf. Since the modules you want on your initramfs can be fully configured in /etc/dracut.conf and the modules can determine for themselves whether or not they should be installed to the initramfs, the ebuild should not try to determine which modules should be installed on the host system. This doesn't make things easier for the user, but more complex.
omit_dracutmodule is not a replacement for DRACUT_MODULES=, because omit_dracutmodule is a blacklist for all modules, but DRACUT_MODULES= is a white list for optional aka non core modules.
(In reply to Nikoli from comment #30) > omit_dracutmodule is not a replacement for DRACUT_MODULES=, because > omit_dracutmodule is a blacklist for all modules, but DRACUT_MODULES= is a > white list for optional aka non core modules. If you list the optional modules you do not want in omit_dracutmodules, you will get the same affect as not listing them in DRACUT_MODULES=, e.g. they will not be installed in the initramfs. The issue with DRACUT_MODULES= is that the ebuild removes modules from the host system that are not listed in DRACUT_MODULES. This is not an upstream feature, so there is no valid reason for our ebuild to do it. Use flags are to control build time settings.
(In reply to Nikoli from comment #26) > > If you have a system that uses lvm, you already have lvm installed, so it doesn't need to be a depend of Dracut at all. > > Disagree with this argument: if i have lvm2 installed, it does not mean i > want it in my initramfs, my rootfs can be not in lvm. > > Consider such situation: > 1) /boot partition is small: 16 or 32 MB This is a good example of bad partitioning scheme :P > 2) rootfs is simple ext4 GPT partition, initramfs is used only for loading > kernel modules and running fsck > 3) several or even all optional dracut deps are installed: lvm2, mdadm, > cryptsetup, cifs-utils, dmraid, nfs-utils, multipath-tools and so on > 4) hostonly="yes" is not possible, because same initramfs.img should be used > in several systems Looks like a very rare use case. Even in binary distros initramfs is not shipped with any package. It is generated on each host after kernel install/update. > > So what will happen? > > a) With current dracut ebuild user can set DRACUT_MODULES="dash" and be > unworried, because he knows that his initramfs.img will be small enough even > after installing new packages or updating dracut. > > b) If DRACUT_MODULES is removed, then user will be really nervous: > 1) by default dracut will create huge initramfs.img, most likely it will be > bigger then 16 MB. > 2) after installing new packages initramfs.img can become bigger: you never > know until you rebuild initramfs.img > 3) after updating dracut initramfs.img can become bigger, because dracut > devs can add new modules and start using new deps, again you will not know > until you rebuild initramfs.img Yes. If we drop DRACUT_MODULES, then we should enable hostonly mode by default (like in fedora and probably in other distros). > > So what you suggest will make dracut behaviour unpredictable and force users > to dig into dracut sources and have huge omit_dracutmodules= in > /etc/dracut.conf I guess dracutmodules+=" base dash fs-lib kernel-modules " in /etc/(dracut.conf|dracut.conf.d/*.conf) should be enough in your case.
(In reply to Alexander Tsoy from comment #32) > Yes. If we drop DRACUT_MODULES, then we should enable hostonly mode by > default (like in fedora and probably in other distros). In briefly looking at the code, isn't this the upstream default anyway? If it is, that is what we should do.
I guess it may not be the upstream default. However, I don't agree either that we should use --hostonly by default, here's why. The check() function inside each module will make sure the module is not installed into the initramfs if the software the module needs is not on the host system.
(In reply to William Hubbs from comment #34) > I guess it may not be the upstream default. hostonly is disabled by default. > However, I don't agree either that we should use --hostonly by default, > here's why. > The check() function inside each module will make sure the module is not > installed into the initramfs if the software the module needs is not on the > host system. I suggested to enable hostonly by default in the context of comment #26 (In reply to Nikoli from comment #26) > b) If DRACUT_MODULES is removed, then user will be really nervous: > 1) by default dracut will create huge initramfs.img, most likely it will be > bigger then 16 MB. > 2) after installing new packages initramfs.img can become bigger: you never > know until you rebuild initramfs.img > 3) after updating dracut initramfs.img can become bigger, because dracut > devs can add new modules and start using new deps, again you will not know > until you rebuild initramfs.img
(In reply to Alexander Tsoy from comment #35) > (In reply to William Hubbs from comment #34) > > I guess it may not be the upstream default. > > hostonly is disabled by default. > > > However, I don't agree either that we should use --hostonly by default, > > here's why. > > The check() function inside each module will make sure the module is not > > installed into the initramfs if the software the module needs is not on the > > host system. > > I suggested to enable hostonly by default in the context of comment #26 Whether you go this rout is really up to @aidecoe, but there are a couple of things I can say about it. > (In reply to Nikoli from comment #26) > > b) If DRACUT_MODULES is removed, then user will be really nervous: > > 1) by default dracut will create huge initramfs.img, most likely it will be > > bigger then 16 MB. Not true by default. This would happen if the software that all of the modules use is installed on the host system. This is what Dracut calls a generic initramfs. > > 2) after installing new packages initramfs.img can become bigger: you never > > know until you rebuild initramfs.img This is correct, unless the user uses -H on the command line or hostonly is changed to yes. > > 3) after updating dracut initramfs.img can become bigger, because dracut > > devs can add new modules and start using new deps, again you will not know > > until you rebuild initramfs.img This is also true, but fixed by point 2 above. The question then is whether you want to build a hostonly initramfs by default in Gentoo. Is the most common case a host specific initramfs, or a more automatic one like what the Dracut package does by default?
@aidecoe: Here is something else to consider. If multiple distros are enabling hostonly mode, it might be an opportunity to talk to Harald about making this the upstream default?
genkernel builds a very minimal initramfs unless the user requests more. Since most users will be using it on one machine I would imagine that defaulting to hostonly is sane. I can't see a reason why I want to include everything when it darn well knows I'm not using it on this system.
Fixed with bump to 036. Please confirm if everything is all right, now. +*dracut-036 (16 Feb 2014) + + 16 Feb 2014; Amadeusz Żołnowski <aidecoe@gentoo.org> +dracut-036.ebuild, + +files/036-0001-NEWS-update-for-version-036.patch, + +files/036-0002-dracut-functions.sh-support-for-altern.patch, + +files/036-0003-gentoo.conf-let-udevdir-be-handled-by-.patch, + +files/036-0004-Use-the-same-paths-in-dracut.sh-as-tho.patch, + +files/036-0005-Install-dracut-install-into-libexec-di.patch: + Version bump. + + At the request of QA team the use of DRACUT_MODULES use-expand has been + removed as well as run-time (pseudo-suggested) dependencies. Instead, the + list of suggested dependencies is printed in postinst log message. See + bug #498832. + + NEWS + ~~~~ [...]
Regarding host-only mode: I found out the hard way that dracut's implementation of host-only is brain-dead. It hard-wires a check on the root filesystem UUID into the boot code, and regardless of what you stick in root= on the kernel commandline and regardless of whether that root= is actually there or not, if the hard-wired UUID is not to be found, it will refuse to mount root as directed by the root= and will drop to the emergency shell. This makes testing backup root partitions or other boot options useless, since they work as long as the normal root is there, but break as soon as the hard-wired root UUID cannot be found, which is when you'd REALLY NEED the backup boot you THOUGHT you tested to be booting just fine! When it happened to me, I was stuck between a rock and a hard place, because while I could manually mount my rootfs just fine, I couldn't easily figure out where it was /supposed/ to be mounted in ordered to get the initramfs initscript to resume, and while I may or may not have eventually figured that out, I still couldn't get it to boot (after I **THOUGHT** I had checked that my freshly made backup was booting just fine... it WAS... as long as the hard-wired UUID was still there!), apparently because the old UUID I had just mkfs-ed was still not there... and never would be! What I eventually ended up doing was clearly a hack, but it was just as clearly a hack that shouldn't have been necessary: I created a symlink in /dev/disk/by-uuid/ named as the old UUID, linking to the appropriate new device. Despite the fact that the real UUID was something else entirely, that satisfied the initscript in the initramfs, and I was finally able to boot properly. Why host-only mode hard-wires this UUID into the generated initscript in the initramfs, and **REQUIRES** that said filesystem UUID be present in /dev/disk/by-uuid, refusing to boot without it even if the root= passed to it from the kernel commandline is perfectly valid, I haven't the foggiest, but it's entirely brain-dead. I can see it doing that as a fallback if the root= doesn't point to a valid rootfs, but in my case it did, and what should have been a fallback ended up being a boot-blocker instead. =:^( So these days I don't use host-only mode, since I don't want to again be up a creek without a paddle the next time my normal rootfs UUID disappears, despite an otherwise perfectly valid and tested-bootable root= on the kernel commandline. As such, if anything, gentoo should be WARNING about that in post-install, not suggesting that people actually USE such a broken thing, or worse yet, making it the default! Such a brain-dead solution may work just fine on periodic blow-root-away-and-reinstall-a-new-release distros, but I had to find out the hard way how brain-dead it is when used on a rolling-release distro where the admin might actually back root up and do a fresh mkfs and restore, occasionally!
(In reply to Duncan from comment #40) > Regarding host-only mode: > > I found out the hard way that dracut's implementation of host-only is > brain-dead. It hard-wires a check on the root filesystem UUID into the boot > code, and regardless of what you stick in root= on the kernel commandline > and regardless of whether that root= is actually there or not, if the > hard-wired UUID is not to be found, it will refuse to mount root as directed > by the root= and will drop to the emergency shell. This issue was fixed after 026 release: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=8da51857f0ac94004305f51de9f72a04679a5616
(In reply to Alexander Tsoy from comment #41) > (In reply to Duncan from comment #40) > > Regarding host-only mode: > > > > I found out the hard way that dracut's implementation of host-only is > > brain-dead. It hard-wires a check on the root filesystem UUID into the boot > > code, and regardless of what you stick in root= on the kernel commandline > > and regardless of whether that root= is actually there or not, if the > > hard-wired UUID is not to be found, it will refuse to mount root as directed > > by the root= and will drop to the emergency shell. > > This issue was fixed after 026 release: > > http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/ > ?id=8da51857f0ac94004305f51de9f72a04679a5616 I meant 036 of course
Dear Duncan, Thank you for reporting the bug. It has been fixed in dracut-036-r1 (thanks Alexander for pointing the correct commit :-)). I haven't read carefully your complain because it's too long, as usual, but I see you're not happy with what happened to you. Please have in mind that: 1) We test it. a) Before I commit new version or my fix I reboot my machine with newly generated image to test my configuration at least and consult stuff with upstream. b) Dracut have test suite which is run by Harald on virtual machines. 2) BUT it is impossible to test all possible configurations. 3) Dracut is still in testing, not in stable, so it should be an alert itself for you. 4) Sysadmin should not blindly rely on software and he/she should test his/her main and backup configuration BEFORE bad things might happen and not hold somebody else responsible for his/her oversight. We do what our short spare time allows us to do. Moreover you should report the problem in SEPARATE BUG REPORT, not in a comment to some not related random bug you have found on bugzilla. And please be a bit more brief next time. +*dracut-036-r1 (17 Feb 2014) + + 17 Feb 2014; Amadeusz Żołnowski <aidecoe@gentoo.org> +dracut-036-r1.ebuild, + +files/036-0006-dracut.sh-Fix-variable-name-typo.patch: + Fixed problem with root= boot parameter being ignored by dracut in hostonly + mode. Rels comment #40 of bug #498832. + + Commit on behalf of Alexander Tsoy <alexander@tsoy.me>. +
(In reply to Amadeusz Żołnowski from comment #43) > Dear Duncan, > > Thank you for reporting the bug. It has been fixed in dracut-036-r1 (thanks > Alexander for pointing the correct commit :-)). Thanks. =:^) > Please have in mind that: > > 1) We test it. For the record... I don't blame gentoo dracut maintainers at all; it wasn't your fault and any testing you did would have been as unlikely as my own to find this specific problem.(*) a) I interpreted the various warnings about hostonly as discouraging its use and thought it was an "OK, you asked for it, but you get to keep the pieces if it breaks" feature, particularly since it /seemed/ obvious that a such a UUID lock would /have/ to be deliberate. (Of course now I know I was very wrong on both counts!) b) Because I considered it a deliberate upstream (mis-)feature, I didn't really consider it a gentoo bug either. c) That's why I didn't file it as a (separate) bug and only brought it up here when it appeared hostonly was being discussed as a default, since my experience suggested it wasn't a suitable default at all. > 2) BUT it is impossible to test all possible configurations. > > 3) Dracut is still in testing, not in stable, so it should be an alert itself > for you. > > 4) Sysadmin should not blindly rely on software and he/she should test > his/her main and backup configuration BEFORE bad things might happen and not > hold somebody else responsible for his/her oversight. We do what our short > spare time allows us to do. (*) Given that any testing including my own and presumably yours that didn't actually wipe or mkfs the default rootfs before testing boot of an alternative root would fail to find the issue... results would be just great... until/unless the filesystem matching the hard-coded UUID disappeared, it would have been difficult for /anyone/ to predict that actually booting a backup root might depend on the default root being there. Pre-testing for a bug you haven't even considered the possibility of is notoriously difficult, and I can't blame anyone, myself, gentoo, or upstream, for failing to catch that in whatever tests. People running into it in actual use as I did was the only real way to catch it, and then it looked deliberate, so... > Moreover you should report the problem in SEPARATE BUG REPORT, not in a > comment to some not related random bug you have found on bugzilla. Since I figured the "misfeature" must be deliberate and thus NOTABUG, I didn't file it /as/ a bug. I only commented here to point out the then existing danger of hostonly for anyone who did what I did, and didn't actually expect a fix as I didn't consider it a bug, so I was only arguing that hostonly was inappropriate as a default. But you surprised me and considered it a bug to be fixed, and what a fast fix it was, too! Hostonly is a much more appropriate gentoo default now. =:^) Again, thanks! =:^)
I wish Bugzilla had an option to lock threads...
