Description of problem: When attempting to compose Fedora 20 Alpha TC1 I was unable to compose an arm tree. after wasiting most of my weekend debugging why it turned out that x86 images only composed by a fluke. memtest86+ required grubby, however that is an x86 only package. The reason for the compose failure ended up being that grubby is not installed into the installroot any longer, this is due to the kernel changeing its dep from new-kernel-pkg to kernel-install. the resulting tree failed to make initrds and the compose failed, after finally digging into the cause of the problem i wrote a patch for lorax which builds the installroot to always pull in grubby https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-August/005546.html it was naked by Brian Lane and Peter Jones. I checked with the kernel guys since thats where the dep is supposed to be according to Peter in his nak, the resposne I got was "17:01 < jwb> dgilmore, harald was supposed to keep the dep for grubby on kernel-install itself" which led me to the conclusion that systemd need ed to pull in grubby. after Kay reverted my patch which I in turn put back, I came back to 00:26 < kay> dgilmore: can you please stop that nonsense? 00:26 < kay> dgilmore: add it to grub or whatever but please stop fiddling with the systemd package 00:27 < kay> dgilmore: this is not how things should work 00:27 < kay> dgilmore: i'm going to revert it again 00:28 < rdieter> playing hot potato with the dependency isnt going to fix it either. :( 00:28 < kay> dgilmore: and for the last time, use bugzilla and not mis-use your privileges, please 00:29 < kay> it actively brweaks our test setups, systemd does not want grubby. it is intentionally made to work without it I really do not care how this is dealt with I need to be able to compose Fedora, which today means grubby needs to be pressent in the installroot to make initrds for the installer. The dep needs to stay in systemd until something else is sure to always pull it in on all arches. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Yes, grubby is in the "core" group of comps!!!! Why isn't the composing tool using this info?
Adding grubby as a dependency would just paper over the fact, that lorax should use the "core" comps group as a base for its installroot. Reassigning, because normal kickstart installs have no problem, as Jens Petersen pointed out.
we dont use comps when building the installroot to ensure the boot.iso and dvd are the smallest possible size while working. it needs to be added as a package dep, being in comps is not enough.
Adding it as a dep for systemd would pull it into containers, which is wrong of course.
(In reply to Dennis Gilmore from comment #3) > we dont use comps when building the installroot to ensure the boot.iso and > dvd are the smallest possible size while working. it needs to be added as a > package dep, being in comps is not enough. <id>core</id> <_name>Core</_name> <_description>Smallest possible installation</_description> Which of those components is too much for the live CD? Maybe we should scratch these then from the "Smallest possible installation" list?? audit basesystem bash biosdevname coreutils cronie curl dhclient e2fsprogs filesystem glibc grubby hostname initscripts iproute iputils kbd less man-db ncurses openssh-clients openssh-server parted passwd plymouth policycoreutils procps-ng rootfiles rpm selinux-policy-targeted setup shadow-utils sudo systemd util-linux vim-minimal yum authconfig firewalld NetworkManager ppc64-utils dracut-config-rescue
(In reply to Dennis Gilmore from comment #3) > we dont use comps when building the installroot to ensure the boot.iso and > dvd are the smallest possible size while working. it needs to be added as a > package dep, being in comps is not enough. So and the fix for you custom hack is to break the core package dependencies, to make your hack work? Awesome. Please fix the stuff where it's broken and stop messing around in packages. If core is to "big", fix core please, but don't break the rest of our stuff, to adjust to your broekn optimizations.
Please, just add grubby as a dependency to the bootloaders which are configured by grubby, in this case grub. The dependency in systemd (or the kernel) is just wrong and backwards, and needs to go.
(In reply to Harald Hoyer from comment #5) > Which of those components is too much for the live CD? Maybe we should > scratch these then from the "Smallest possible installation" list?? > biosdevname Hasn't this been deprecated?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8) > (In reply to Harald Hoyer from comment #5) > > Which of those components is too much for the live CD? Maybe we should > > scratch these then from the "Smallest possible installation" list?? > > > biosdevname > Hasn't this been deprecated? don't know why this is in @core
1. This used to work. Someone broke it. I'm not clear on the details, but the dep use to belong to the kernel. If it is what's calling this stuff then put it back there. 2. lorax shouldn't be in the business of doing things that should be solved by a dependency. 3. Adding it to lorax is just papering over the problem -- it may solve it for the compose but it doesn't solve it for the actual install or anything else that expects yum to pull in the needed packages. 4. Adding the dep to the bootloaders is backwards, they don't need grubby for anything. If something needs grubby in order for things to work, it needs to Require it (or maybe grubby needs to provide something new?) so that the dependency can be resolved by yum, not by a manually maintained list of packages. Just tossing it into a package because it is always included isn't the right solution.
(In reply to Brian C. Lane from comment #10) > 1. This used to work. Someone broke it. I'm not clear on the details, but > the dep use to belong to the kernel. If it is what's calling this stuff then > put it back there. It isn't. The kernel is calling kernel-install. kernel-install is calling grubby under the covers because grub2 doesn't support BLS yet. kernel-install is provided by systemd. > 2. lorax shouldn't be in the business of doing things that should be solved > by a dependency. > > 3. Adding it to lorax is just papering over the problem -- it may solve it > for the compose but it doesn't solve it for the actual install or anything > else that expects yum to pull in the needed packages. Agreed to 2 and 3. > 4. Adding the dep to the bootloaders is backwards, they don't need grubby > for anything. Neither does the kernel in that rather scoped and contextualized definition of "need". I mean, sure a bootloader will start without a valid config written, but it won't boot anything. The kernel will install on a system and work fine if someone can manually load it too. WHO NEEDS GRUBBY? > If something needs grubby in order for things to work, it needs to Require > it (or maybe grubby needs to provide something new?) so that the dependency > can be resolved by yum, not by a manually maintained list of packages. Just > tossing it into a package because it is always included isn't the right > solution. This is the third time I've been approached about adding this back to the kernel. In an effort to not repeat myself any further, I'm going to summarize things. The kernel-install kernel.spec patch was submitted as a drop-in replacement for grubby in F20. The intention was to allow users not using grub2 to avoid installing it and needing grubby, while letting the other 95% of the distro users still work as usual. This has worked fine since it went in on an installed system. It was also submitted to allow grub2 time to migrate to supporting BLS, which might eventually eliminate the need for grubby even for grub2 (from what I remember). That is beyond the scope of F20. Apparently, the removal of the dep on grubby in kernel.spec has now caused this compose issue. OK, fine, but adding a dep on both systemd (for kernel-install) and grubby to the kernel makes the entire point of the patch moot to being with. There are two proposals here. One is to add a dep on grubby to the bootloaders. The other is to add the dep to systemd, because in Fedora kernel-install is actually calling grubby. Apparently the bootloader people dislike the first option because bootloaders don't need grubby. This is technically true, but a bootloader without a written config to boot the system and/or updated kernels is somewhat pointless. The systemd people dislike the systemd option because it breaks their testing of non-Fedora systems using Fedora RPMs and systemd doesn't need grubby. If there are other reasons, I've forgotten them. Those reasons might be technically true as well, but this is FEDORA not "non-Fedora", and I care most about Fedora working. So now those two groups are at an impasse and a problem I was told wouldn't happen has happened and now I get to deal with it. I'm growing increasingly tired of people pointing fingers, and I will revert the kernel.spec change if this isn't resolved soon because the option of adding a dep on grubby to kernel.spec is in-effect the same thing. I would suggest this be taken to FESCo if some agreement on a solution cannot be achieved.
I really don't understand the problem with adding grubby or better @core to lorax? - Adding it to systemd is just a workaround. - Adding it to kernel is just a workaround. - Adding it to grub is just a workaround. There is no "hard" requirement for all these components to have grubby. Josh, nobody is demanding to add grubby back to the kernel.spec. Adding it to systemd would pull in grubby in containers, which is really not what people want. Note: you can add Fedora containers in Fedora, too... This not a non-Fedora problem. And btw, gummiboot is in Fedora and not non-Fedora. Why the heck is nobody using @core as the base of the system? Isn't that, what it is supposed to be? And if @core does not reflect our needs, then fix @core!!!
$ egrep installpkg share/runtime-install.tmpl|while read a rest; do printf "$rest ";done | wc -w 139 And I don't understand why it is so difficult to add grubby to your list of 139 handcrafted install items either. 139! and adding one is a problem?
(In reply to Harald Hoyer from comment #12) > Josh, nobody is demanding to add grubby back to the kernel.spec. This bug is assigned to the kernel component. Until something is decided upon, I'm moving it to the distribution component.
(In reply to Josh Boyer from comment #14) > (In reply to Harald Hoyer from comment #12) > > Josh, nobody is demanding to add grubby back to the kernel.spec. > > This bug is assigned to the kernel component. > > Until something is decided upon, I'm moving it to the distribution component. The distribution has it all correct. grubby is in comps @core.
(In reply to Harald Hoyer from comment #12) > Adding it to systemd would pull in grubby in containers, which is really not > what people want. Note: you can add Fedora containers in Fedora, too... This > not a non-Fedora problem. And btw, gummiboot is in Fedora and not non-Fedora. systemd in containers? All the container work I've seen Alex doing has a fake package to provide systemd in order to keep it out of the container...
In the interest of moving forward I have added Dennis' original lorax patch.
(In reply to Brian C. Lane from comment #17) > In the interest of moving forward I have added Dennis' original lorax patch. Thanks a lot for the cooperation, it's very appreciated.