Re: grub (v1) in f18?
Hi Rich, On 07.12.2012 18:54, Richard W.M. Jones 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 and in libvirt XML). But: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On 12/07/2012 11:42 AM, Chris Murphy wrote: > 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. 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. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Dec 7, 2012, at 10:24 AM, "Richard W.M. Jones" wrote: > On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote: >> 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. >> http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html > > [My second answer, now that I've looked at that code and understand > better where you're going with this …] 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. > > 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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On 12/07/2012 07:59 PM, Matthew Miller wrote: On Fri, Dec 07, 2012 at 06:49:25PM +0200, Panu Matilainen 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. My point is that it's not really possible to have *grub* without playing tricks (maybe not dirty ones). Sure, I'm not arguing to the contrary :) 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. Are there other obsoleted packages in the F18 repo? Yes there are, see http://lists.fedoraproject.org/pipermail/buildsys/2012-November/004004.html 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). Is there a good way to look for them and to clean them up before release? 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. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Fri, Dec 07, 2012 at 06:49:25PM +0200, Panu Matilainen 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. My point is that it's not really possible to have *grub* without playing tricks (maybe not dirty ones). > 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. 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? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Fri, Dec 07, 2012 at 09:29:28AM -0800, John Reiser wrote:
> > 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.
> yum is not the only tool available.
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.
> Using rpm: erase grub2 if it is present; install grub [grub1].
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.
> There are other tools, too. rpm2cpio comes to mind.
Really???
And sure, you can build grub from source. But we're getting pretty far off
from being actually _Fedora_.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On 12/07/2012 08:49 AM, Panu Matilainen wrote: > 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. 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. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote: > 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. > http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html [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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote: > > On Dec 6, 2012, at 3:02 PM, "Richard W.M. Jones" wrote: > > > On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote: > >> 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? > > > > 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: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10 > > > > and also in the archives of the current mailing list. > > 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. > http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html 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 and 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 :-( > And if there's a use case for UEFI VM's, why not use EFISTUB instead of grub? No idea sorry. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On 12/07/2012 05:26 PM, Matthew Miller wrote: On Fri, Dec 07, 2012 at 10:56:44AM +0200, Panu Matilainen wrote: 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. If you have *both* installed, grub2 will want to nuke grub every time an update shows up, IIRC. 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'... 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. :) 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. 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 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. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Fri, Dec 07, 2012 at 10:56:44AM +0200, Panu Matilainen wrote: > >>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. > > > >If you have *both* installed, grub2 will want to nuke grub every time an > >update shows up, IIRC. > > 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'... 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 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On 12/07/2012 09:41 AM, Adam Williamson wrote: On Thu, 2012-12-06 at 16:48 -0700, Chris Murphy wrote: On Dec 6, 2012, at 3:25 PM, Matthew Miller wrote: On Thu, Dec 06, 2012 at 10:02:20PM +, Richard W.M. Jones wrote: On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote: 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? Yes, virtualization. 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. 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. If you have *both* installed, grub2 will want to nuke grub every time an update shows up, IIRC. 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'... - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Thu, 2012-12-06 at 16:48 -0700, Chris Murphy wrote: > On Dec 6, 2012, at 3:25 PM, Matthew Miller wrote: > > > On Thu, Dec 06, 2012 at 10:02:20PM +, Richard W.M. Jones wrote: > >> On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote: > >>> 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? > >> Yes, virtualization. > > > > 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. > > 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. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Dec 6, 2012, at 3:25 PM, Matthew Miller wrote: > On Thu, Dec 06, 2012 at 10:02:20PM +, Richard W.M. Jones wrote: >> On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote: >>> 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? >> Yes, virtualization. > > 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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Thu, Dec 06, 2012 at 10:02:20PM +, Richard W.M. Jones wrote: > On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote: > > 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? > Yes, virtualization. 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. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Dec 6, 2012, at 3:02 PM, "Richard W.M. Jones" wrote: > On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote: >> 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? > > 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: > > https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10 > > and also in the archives of the current mailing list. 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. http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html And if there's a use case for UEFI VM's, why not use EFISTUB instead of grub? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote: > 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? 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: https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10 and also in the archives of the current mailing list. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
