Bug 1001896 - The installroot should include the "core" comps components
The installroot should include the "core" comps components
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: lorax (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-28 01:05 EDT by Dennis Gilmore
Modified: 2014-03-27 13:18 EDT (History)
24 users (show)

See Also:
Fixed In Version: lorax-20.0-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-27 13:18:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dennis Gilmore 2013-08-28 01:05:31 EDT
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:
Comment 1 Harald Hoyer 2013-08-28 03:06:25 EDT
Yes, grubby is in the "core" group of comps!!!! 

Why isn't the composing tool using this info?
Comment 2 Harald Hoyer 2013-08-28 03:15:05 EDT
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.
Comment 3 Dennis Gilmore 2013-08-28 08:57:25 EDT
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.
Comment 4 Zbigniew Jędrzejewski-Szmek 2013-08-28 09:27:49 EDT
Adding it as a dep for systemd would pull it into containers, which is wrong of course.
Comment 5 Harald Hoyer 2013-08-28 10:17:25 EDT
(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
Comment 6 Kay Sievers 2013-08-28 10:24:39 EDT
(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.
Comment 7 Kay Sievers 2013-08-28 10:24:59 EDT
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.
Comment 8 Zbigniew Jędrzejewski-Szmek 2013-08-28 10:31:47 EDT
(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?
Comment 9 Harald Hoyer 2013-08-28 10:36:01 EDT
(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
Comment 10 Brian Lane 2013-08-28 20:03:34 EDT
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.
Comment 11 Josh Boyer 2013-08-28 20:41:28 EDT
(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.
Comment 12 Harald Hoyer 2013-08-29 05:46:10 EDT
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!!!
Comment 13 Harald Hoyer 2013-08-29 05:54:37 EDT
$ 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?
Comment 14 Josh Boyer 2013-08-29 09:53:44 EDT
(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.
Comment 15 Harald Hoyer 2013-08-29 10:28:25 EDT
(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.
Comment 16 Bill Nottingham 2013-08-29 13:54:56 EDT
(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...
Comment 17 Brian Lane 2013-09-03 12:28:43 EDT
In the interest of moving forward I have added Dennis' original lorax patch.
Comment 18 Kay Sievers 2013-09-04 11:55:07 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.