DevHeads.net

grub (v1) in f18?

The grub2 package obsoletes grub, so there's no way to actually _use_ the
older package, but it's still in the tree. Is there a reason?

Comments

Re: grub (v1) in f18?

By Richard W.M. Jones at 12/06/2012 - 18:02

On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
Yes, virtualization.

I actually thought grub had been removed, so I removed the dependency
on it in libguestfs. However libguestfs certainly *could* use grub,
if it was available. There's some heated discussion of this here:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10" title="https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10">https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10</a>

and also in the archives of the current mailing list.

Rich.

Re: grub (v1) in f18?

By Matthew Miller at 12/06/2012 - 18:25

On Thu, Dec 06, 2012 at 10:02:20PM +0000, Richard W.M. Jones wrote:
So, yeah, that's actually what I want to do. But since 2011, the grub2
package _obsoletes_ grub, which means that yum and friends will happily
substitute grub2 for grub on every opportunity (by default) including
building images with appliance-creator.

Re: grub (v1) in f18?

By Chris Murphy at 12/06/2012 - 19:48

I haven't experienced this with F16, F17 or so far F18. What I'm seeing is:

yum install/update grub gets me grub legacy.
yum install/update grub-efi gets me grub legacy efi.
yum install/update grub2 gets me grub2.
yum install/update grub2-efi gets me grub2 efi.

Chris Murphy

Re: grub (v1) in f18?

By Adam Williamson at 12/07/2012 - 03:41

On Thu, 2012-12-06 at 16:48 -0700, Chris Murphy wrote:
If you have *both* installed, grub2 will want to nuke grub every time an
update shows up, IIRC.

pjones had a reason for doing it this way, my personal opinion is that
it's a dumb thing to do (I thought we should actually kill grub and only
ship grub-efi), but I'm just the monkey. He might catch this thread to
explain what his reasoning is/was.

Re: grub (v1) in f18?

By Panu Matilainen at 12/07/2012 - 04:56

On 12/07/2012 09:41 AM, Adam Williamson wrote:
Yum and rpm refuse to install packages which are obsoleted by an
installed package, so you can't really have both. Unless you first
install grub2 and then grub with 'rpm --nodeps'...

Re: grub (v1) in f18?

By Matthew Miller at 12/07/2012 - 11:26

On Fri, Dec 07, 2012 at 10:56:44AM +0200, Panu Matilainen wrote:
But, it's not just if both installed, is it? The grub2 package obsoletes
grub, and yum follows obsoletes by default in dependency resolution.

Panu, you would know this better than I, so clearly I'm going crazy
somewhere. If you could explain how, I'd appreciate it. :)

Here's on an F17 image booted in a cloud service (so no grub at all
installed initially):

$ rpm -qa |grep grub
grubby-8.11-1.fc17.x86_64

(As expected, just grubby; nothing else matches.)

$ sudo yum install grub
[...]
Package grub is obsoleted by grub2, trying to install
1:grub2-2.0-0.39.fc17.x86_64 instead
Resolving Dependencies
--> Running transaction check
---> Package grub2.x86_64 1:2.0-0.39.fc17 will be installed
--> Processing Dependency: grub2-tools = 1:2.0-0.39.fc17 for package:
--> 1:grub2-2.0-0.39.fc17.x86_64
[...and so on]

Even "yum install grub-0.97" gets this behavior. Now, I can set
"obsoletes=0" in /etc/yum.conf if I _really_ want to get grub installed, but

a) I don't actually want to change the default behavior of yum on the final
image

b) I don't want users to get messed up if they innocently change that back
to its default

c) I'm not even sure how I would go about changing that pre-transaction in
appliance-creator and other tools

Re: grub (v1) in f18?

By Panu Matilainen at 12/07/2012 - 12:49

On 12/07/2012 05:26 PM, Matthew Miller wrote:
My comment was simply on the "if you have both" part: it's not really
possible to have both without playing dirty tricks, so even the "if" is
pretty moot.

Yes, I think we're both trying to say the same thing: there's no point
having 'grub' in the repositories as its not installable or usable in
practise. The same goes for bunch of other obsoleted packages as well.

Re: grub (v1) in f18?

By Matthew Miller at 12/07/2012 - 13:59

On Fri, Dec 07, 2012 at 06:49:25PM +0200, Panu Matilainen wrote:
My point is that it's not really possible to have *grub* without playing
tricks (maybe not dirty ones).

Are there other obsoleted packages in the F18 repo? Is there a good way to
look for them and to clean them up before release?

Obsoleted packages in repositories (was: grub (v1) in f18?)

By Panu Matilainen at 12/21/2012 - 04:55

On 12/07/2012 07:59 PM, Matthew Miller wrote:
Here's what I see on F18, it's quite a pile:

4ti2-1.3.2-12.fc18.x86_64
anyremote2html-1.4-4.fc18.noarch
chktex-1.6.4-11.fc18.x86_64
classads-1.0.8-5.fc18.i686
classads-1.0.8-5.fc18.x86_64
classads-devel-1.0.8-5.fc18.i686
classads-devel-1.0.8-5.fc18.x86_64
classads-static-1.0.8-5.fc18.i686
classads-static-1.0.8-5.fc18.x86_64
cura-account-0.0.4-1.fc18.x86_64
cura-fan-0.0.4-1.fc18.x86_64
cura-networking-0.0.4-1.fc18.x86_64
cura-powermanagement-0.0.4-1.fc18.x86_64
cura-providers-0.0.4-1.fc18.i686
cura-providers-0.0.4-1.fc18.x86_64
cura-providers-devel-0.0.4-1.fc18.i686
cura-providers-devel-0.0.4-1.fc18.x86_64
cura-service-0.0.4-1.fc18.x86_64
cura-storage-0.3-1.fc18.noarch
cura-tools-0.1-3.fc18.noarch
django-keyedcache-1.4.1-4.fc18.noarch
django-mako-0.1.4-0.5.pre.fc18.noarch
django-pylibmc-0.2.1-4.20110806gitb56e74.fc18.noarch
dvisvgm-1.0.12-2.fc18.x86_64
english-typing-booster-0.0.2-2.fc18.noarch
fcitx-keyboard-0.1.3-1.fc18.x86_64
gpxe-bootimgs-1.0.1-7.fc18.noarch
gpxe-roms-1.0.1-7.fc18.noarch
gpxe-roms-qemu-1.0.1-7.fc18.noarch
grc-0.70-9.fc18.noarch
1:grub-0.97-91.fc18.x86_64
gtksourceview2-sharp-1.0-10.svn89788.fc16.x86_64
gtksourceview2-sharp-devel-1.0-10.svn89788.fc16.i686
gtksourceview2-sharp-devel-1.0-10.svn89788.fc16.x86_64
ibus-european-table-1.1.6-2.fc18.noarch
ibus-hunspell-table-0.0.8-2.fc18.noarch
ibus-indic-table-1.3.1-23.fc17.noarch
ibus-table-array30-1.2.0.20090729-4.fc18.noarch
jadetex-3.13-12.fc18.noarch
jaffl-0.5.9-1.fc16.noarch
jaxen-bootstrap-1.1-6.2.fc18.noarch
kdirstat-2.5.3-13.fc18.x86_64
latexmk-4.35-1.fc18.noarch
libgssapi-0.11-11.fc18.i686
libgssapi-0.11-11.fc18.x86_64
libgssapi-devel-0.11-11.fc18.i686
libgssapi-devel-0.11-11.fc18.x86_64
lzma-4.32.7-8.fc18.x86_64
manaworld-0.5.2-9.fc18.x86_64
manaworld-music-0.3-3.fc18.noarch
maven-shared-artifact-resolver-1.1-24.fc18.noarch
maven-shared-common-artifact-filters-1.3-24.fc18.noarch
maven-shared-dependency-tree-1.3-24.fc18.noarch
module-init-tools-3.16-6.fc18.x86_64
netxen-firmware-4.0.534-6.fc18.noarch
nfs-utils-lib-1.1.5-7.fc18.i686
nfs-utils-lib-1.1.5-7.fc18.x86_64
nss_ldap-265-10.fc17.i686
nss_ldap-265-10.fc17.x86_64
pam_passwdqc-1.0.5-10.fc18.i686
pam_passwdqc-1.0.5-10.fc18.x86_64
pdfjam-2.08-4.fc18.noarch
pexpect-2.3-8.fc18.noarch
ps2eps-1.68-4.fc18.x86_64
pymongo-2.1.1-2.fc18.x86_64
pymongo-gridfs-2.1.1-2.fc18.x86_64
python-cryptsetup-0.1.4-4.fc18.x86_64
ql2100-firmware-1.19.38-6.fc18.noarch
ql2200-firmware-2.02.08-6.fc18.noarch
ql23xx-firmware-3.03.28-4.fc18.noarch
qxmpp-dev-0.6.3.1-1.fc18.i686
qxmpp-dev-0.6.3.1-1.fc18.x86_64
qxmpp-dev-devel-0.6.3.1-1.fc18.i686
qxmpp-dev-devel-0.6.3.1-1.fc18.x86_64
rt61pci-firmware-1.2-10.fc18.noarch
rt73usb-firmware-1.8-10.fc18.noarch
ruby-goocanvas-0.90.4-1.9.fc18.1.x86_64
ruby-goocanvas-devel-0.90.4-1.9.fc18.1.i686
ruby-goocanvas-devel-0.90.4-1.9.fc18.1.x86_64
ruby-gstreamer-0.90.4-1.9.fc18.1.x86_64
ruby-gstreamer-devel-0.90.4-1.9.fc18.1.i686
ruby-gstreamer-devel-0.90.4-1.9.fc18.1.x86_64
ruby-gtksourceview2-0.90.4-1.9.fc18.1.x86_64
ruby-gtksourceview2-devel-0.90.4-1.9.fc18.1.i686
ruby-gtksourceview2-devel-0.90.4-1.9.fc18.1.x86_64
seahorse-plugins-2.91.6-0.5.git1e35fd9.fc18.x86_64
sshfp-1.2.2-4.fc18.noarch
tetex-IEEEtran-1.7.1-6.fc18.noarch
texlive-texmf-2007-42.fc18.noarch
texlive-texmf-afm-2007-42.fc18.noarch
texlive-texmf-context-2007-42.fc18.noarch
texlive-texmf-doc-2007-42.fc18.noarch
texlive-texmf-dvips-2007-42.fc18.noarch
texlive-texmf-east-asian-2007-42.fc18.noarch
texlive-texmf-errata-2007-10.fc18.noarch
texlive-texmf-errata-afm-2007-10.fc18.noarch
texlive-texmf-errata-context-2007-10.fc18.noarch
texlive-texmf-errata-doc-2007-10.fc18.noarch
texlive-texmf-errata-dvips-2007-10.fc18.noarch
texlive-texmf-errata-east-asian-2007-10.fc18.noarch
texlive-texmf-errata-fonts-2007-10.fc18.noarch
texlive-texmf-errata-latex-2007-10.fc18.noarch
texlive-texmf-errata-xetex-2007-10.fc18.noarch
texlive-texmf-fonts-2007-42.fc18.noarch
texlive-texmf-latex-2007-42.fc18.noarch
texlive-texmf-xetex-2007-42.fc18.noarch
utouch-evemu-1.0.8-3.fc18.i686
utouch-evemu-1.0.8-3.fc18.x86_64
utouch-evemu-devel-1.0.8-3.fc18.i686
utouch-evemu-devel-1.0.8-3.fc18.x86_64
yum-plugin-downloadonly-1.1.31-6.fc18.noarch

Here's the dumb little scriptlet used to produce the above list on my
F18 box. For "real world" purposes you'd want at least some control over
what repositories are enabled...

import yum

if __name__ == '__main__':
my = yum.YumBase()
my.doConfigSetup()
my.doRepoSetup()
my.doSackSetup()

obsoleted = []
for p in my.pkgSack:
obsoleters = p.obsoletedBy(my.pkgSack.searchObsoletes(p.name))
if obsoleters:
obsoleted.append(p)

obsoleted.sort()
for o in obsoleted:
print o

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Matthew Miller at 12/21/2012 - 13:28

On Fri, Dec 21, 2012 at 10:55:15AM +0200, Panu Matilainen wrote:
I made a Rel-Eng ticket: <a href="https://fedorahosted.org/rel-eng/ticket/5427" title="https://fedorahosted.org/rel-eng/ticket/5427">https://fedorahosted.org/rel-eng/ticket/5427</a>

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Jerry James at 12/21/2012 - 11:19

On Fri, Dec 21, 2012 at 1:55 AM, Panu Matilainen
< ... at laiskiainen dot org> wrote:
This one should not be obsoleted. See
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=868996" title="https://bugzilla.redhat.com/show_bug.cgi?id=868996">https://bugzilla.redhat.com/show_bug.cgi?id=868996</a>. I'd appreciate
Jindrich doing something about that before release.

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Matthew Miller at 12/21/2012 - 11:28

On Fri, Dec 21, 2012 at 08:19:58AM -0700, Jerry James wrote:
This should be raised as a FESCO ticket.

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Jerry James at 12/21/2012 - 11:55

On Fri, Dec 21, 2012 at 8:28 AM, Matthew Miller
< ... at fedoraproject dot org> wrote:
Sorry, it must be too early in the morning for my brain to work
properly. What would I be asking FESCO to do?

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Matthew Miller at 12/21/2012 - 11:59

On Fri, Dec 21, 2012 at 08:55:22AM -0700, Jerry James wrote:
Decide between the two redundant and conflicting packagings of the same
code.

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Jerry James at 12/21/2012 - 12:13

On Fri, Dec 21, 2012 at 8:59 AM, Matthew Miller
< ... at fedoraproject dot org> wrote:
Ah, got it, thanks. Here's the ticket:
<a href="https://fedorahosted.org/fesco/ticket/983" title="https://fedorahosted.org/fesco/ticket/983">https://fedorahosted.org/fesco/ticket/983</a>

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Kevin Fenzi at 12/21/2012 - 12:24

On Fri, 21 Dec 2012 09:13:27 -0700

Well, IMHO reading the bug it just sounds like to me a mistake was made
and the obsoletes/conflicts was not removed as intended:

+* Sun Nov 4 2012 Jindrich Novy < ... at redhat dot com> 2012-5-20121024
+- don't conflict with latexmk (#868996)

(but that version didn't change obsoletes/conflicts at all)

I'd suggest instead just mailing jnovy and asking if that was a mistake
and if he could push the correct fix before jumping to conclusions.

kevin

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Jerry James at 12/21/2012 - 12:41

On Fri, Dec 21, 2012 at 9:24 AM, Kevin Fenzi < ... at scrye dot com> wrote:
Ah, that makes sense.

Hmm, I didn't think I had jumped to any conclusions. That's why I was
patiently waiting for a response on the bug. I only spoke up because
I was afraid that the appearance of latexmk on this list meant that
its destruction was imminent. In any case, Jindrich has been CCed to
the FESCO ticket, so I'll just wait for a response there.

Or maybe you aren't talking to me. I think it's too late in the
morning for me to claim that it's too early in the morning for my
brain to be working properly. I think I have to admit now that my
brain is already entering full "Christmas vacation" mode. C'mon
brain, back to work....

Re: Obsoleted packages in repositories (was: grub (v1) in f18?)

By Michael Schwendt at 12/21/2012 - 05:18

This has been renamed to "qxmpp" in review request bug 856114 without
completing the "After the review" steps, however:
<a href="https://fedoraproject.org/wiki/Package_Renaming_Process" title="https://fedoraproject.org/wiki/Package_Renaming_Process">https://fedoraproject.org/wiki/Package_Renaming_Process</a>

Re: grub (v1) in f18?

By Panu Matilainen at 12/07/2012 - 15:15

On 12/07/2012 07:59 PM, Matthew Miller wrote:
Sure, I'm not arguing to the contrary :)

Yes there are, see
<a href="http://lists.fedoraproject.org/pipermail/buildsys/2012-November/004004.html" title="http://lists.fedoraproject.org/pipermail/buildsys/2012-November/004004.html">http://lists.fedoraproject.org/pipermail/buildsys/2012-November/004004.html</a>
for a few examples of obsoleted packages that are not only in the
repositories but getting pulled into DVD images too (or at least were at
the time, haven't looked after that).

Should be doable with repoquery, but a custom script is likely to do a
better job. I can have a look when I'm a bit more awake than now, its
not exactly rocket science anyway.

Re: grub (v1) in f18?

By John Reiser at 12/07/2012 - 13:29

yum is not the only tool available.

Using rpm: erase grub2 if it is present; install grub [grub1].

There are other tools, too. rpm2cpio comes to mind.

Re: grub (v1) in f18?

By Matthew Miller at 12/07/2012 - 13:58

On Fri, Dec 07, 2012 at 09:29:28AM -0800, John Reiser wrote:
But it is the package manager for the distro. More importantly, it's not
really about yum. *Any* package manager which respects what the packages say
("grub2 obsoletes grub") will do the same.

And then the next time you do a general package upgrade, presto, you've got
grub2 again. This is a kludge, basically, akin to installing firefox-12.0-1
from the F17 release tree even though firefox-17.0 is F17 updates.

Really???

And sure, you can build grub from source. But we're getting pretty far off
from being actually _Fedora_.

Re: grub (v1) in f18?

By Chris Murphy at 12/06/2012 - 18:25

Why is a boot manager needed for a virtualized guest? It seems like all you need is to point to a virtual disk (or current or past snapshot) and go directly to loading the kernel.

If I could stuff < 1024 bytes of boot loader into ext4's two boot sectors, that seems ways easier than dealing with grub.
<a href="http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html" title="http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html">http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html</a>

And if there's a use case for UEFI VM's, why not use EFISTUB instead of grub?

Chris Murphy

Re: grub (v1) in f18?

By Richard W.M. Jones at 12/07/2012 - 13:24

On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
[My second answer, now that I've looked at that code and understand
better where you're going with this ...]

Yes, I think this is all possible, and probably better than emulating
what the BIOS does. Even better would be if you could get those 1024
bytes down to 512 bytes (and thus fit it in a boot sector). Then no
changes to existing hypervisors would be needed at all, and it would
run on baremetal.

Rich.

Re: grub (v1) in f18?

By Chris Murphy at 12/07/2012 - 15:42

I'm casually suggesting a vastly simpler means of boot loading a VM that doesn't have a dependency on grub. The host VM interface acting as the boot manager.
ext[234] has two boot sectors for a total of 1024 bytes. XFS has none. Btrfs has 64KB.

It just seems like GRUB is a really familiar 4000 meter cargo train, compared to an unfamiliar hand truck, for the task of moving half-dozen boxes. Maybe I'm underestimating the size/weight of those boxes, but maintaining a grub installation, let alone troubleshooting it if it breaks for some reason, is a lot more complicated than some external source rewriting 1024 bytes to merely two sectors.

Chris Murphy

Re: grub (v1) in f18?

By John Reiser at 12/07/2012 - 16:30

Some real BIOS+MBR demand that the last 2 bytes in a boot sector be 0xAA55.
So sometimes the first sector has only 510 usable bytes. If the same code
reads the second sector, then that sector also might have only 510 usable bytes.
Those 2+2 bytes mattered to me when I wrote mine.

Re: grub (v1) in f18?

By Richard W.M. Jones at 12/07/2012 - 12:54

On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
Well this is a more general question about virtualization. I agree
that it's sometimes more convenient to use an external kernel and
initrd to boot a guest, and libvirt supports this mode (see the
<kernel> and <initrd> in libvirt XML). But:

(a) My understanding is this doesn't eliminate the need for a BIOS,
because I think early kernel code still calls into the BIOS, or at
least uses BIOS-created structures (eg. E820). It does however
eliminate the need to deal with grub.

(b) Maintaining a separate kernel and initrd outside the VM is a pain
when it comes to updates. How is 'yum' running in a VM supposed to
update a kernel stored outside the VM?

(c) It's generally better to remain as close as possible to baremetal,
just for ease of testing, reduced number of code paths, etc.

Note that none of this helps with libguestfs + grub. We want grub so
we can deal with existing guests, and they're already using grub
whether we like it or not :-(

No idea sorry.

Rich.

Re: grub (v1) in f18?

By Alek Paunov at 12/11/2012 - 23:21

Hi Rich,

On 07.12.2012 18:54, Richard W.M. Jones wrote:
We are using libvirt in the above fashion for a while - with a little
help from salt recently (on every yum (kernel) update the host changes
the dom definition for the appropriate guest via the python (libvirt)
bindings)

Our disks for the VMs are regular ext4 LVs (without partitions and
bootloaders)

Thank you for the great platform!
Alek