I tried to install using the F18 Beta TC7 Live CD, but couldn't find any way to specify that the bootloader should go onto the root partition rather than the MBR. Is this possible? It used to be.
I see someone has already raised a bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=872826
Ron
On Sat, 2012-11-03 at 19:42 +0000, Ron Yorston wrote:
I tried to install using the F18 Beta TC7 Live CD, but couldn't find any way to specify that the bootloader should go onto the root partition rather than the MBR. Is this possible? It used to be.
I see someone has already raised a bug report:
I was sure we had a bug report for this already, but I can't find it. We _have_ discussed it at length, though (the anaconda team and Mo and I) and the upshot of our discussion was that we should make this possible via a command line parameter rather than a UI option; it's an 'advanced' option that's only of use to multiboot pokemoners (you know...gotta catch 'em all) and is a 'dangerous' option for anyone who doesn't understand it - if you pick it when you don't know what you're doing, you get a non-bootable install. So we agreed a parameter was the way to go.
I don't know, though, if it's actually been implemented yet, or if it's still on someone's todo list. I couldn't find anything in the git log for it, but I may have missed it. I've added bcl and dlehman to the bug and asked them to comment.
On Nov 3, 2012, at 10:10 PM, Adam Williamson awilliam@redhat.com wrote:
I don't know, though, if it's actually been implemented yet, or if it's still on someone's todo list. I couldn't find anything in the git log for it, but I may have missed it. I've added bcl and dlehman to the bug and asked them to comment.
Bug 861192?
I'm a little mystified by people who want to force a bootloader into a file system that doesn't offer a sufficient bootloader region for a bootloader to fit (e.g. ext[234] and XFS). I think there should be a none option, rather than a redirect and force option.
Chris Murphy
On 11/04/2012 12:10 AM, Chris Murphy wrote:
On Nov 3, 2012, at 10:10 PM, Adam Williamson awilliam@redhat.com wrote:
I don't know, though, if it's actually been implemented yet, or if it's still on someone's todo list. I couldn't find anything in the git log for it, but I may have missed it. I've added bcl and dlehman to the bug and asked them to comment.
Bug 861192?
I'm a little mystified by people who want to force a bootloader into a file system that doesn't offer a sufficient bootloader region for a bootloader to fit (e.g. ext[234] and XFS). I think there should be a none option, rather than a redirect and force option.
What I would like to see is proper support for UEFI multiboot. Right now installing a new Fedora next to the live one is difficult since it doesn't support creating individual UEFI boot entried for each installation but only a global one which runs contrary to having this feature in UEFI in the first place. I'm bringing this up because in the UEFI multiboot case you don't care for either the MBR nor a partition bootloader so this use-case should be taken into account.
Regards, Dennis
On Sun, 2012-11-04 at 00:53 +0100, Dennis Jacobfeuerborn wrote:
On 11/04/2012 12:10 AM, Chris Murphy wrote:
On Nov 3, 2012, at 10:10 PM, Adam Williamson awilliam@redhat.com wrote:
I don't know, though, if it's actually been implemented yet, or if it's still on someone's todo list. I couldn't find anything in the git log for it, but I may have missed it. I've added bcl and dlehman to the bug and asked them to comment.
Bug 861192?
I'm a little mystified by people who want to force a bootloader into a file system that doesn't offer a sufficient bootloader region for a bootloader to fit (e.g. ext[234] and XFS). I think there should be a none option, rather than a redirect and force option.
What I would like to see is proper support for UEFI multiboot. Right now installing a new Fedora next to the live one is difficult since it doesn't support creating individual UEFI boot entried for each installation but only a global one which runs contrary to having this feature in UEFI in the first place. I'm bringing this up because in the UEFI multiboot case you don't care for either the MBR nor a partition bootloader so this use-case should be taken into account.
Bad news:
https://bugzilla.redhat.com/show_bug.cgi?id=759303
Jesse, any chance you're going to change your mind here? :)
On 11/04/2012 01:03 AM, Adam Williamson wrote:
On Sun, 2012-11-04 at 00:53 +0100, Dennis Jacobfeuerborn wrote:
On 11/04/2012 12:10 AM, Chris Murphy wrote:
On Nov 3, 2012, at 10:10 PM, Adam Williamson awilliam@redhat.com wrote:
I don't know, though, if it's actually been implemented yet, or if it's still on someone's todo list. I couldn't find anything in the git log for it, but I may have missed it. I've added bcl and dlehman to the bug and asked them to comment.
Bug 861192?
I'm a little mystified by people who want to force a bootloader into a file system that doesn't offer a sufficient bootloader region for a bootloader to fit (e.g. ext[234] and XFS). I think there should be a none option, rather than a redirect and force option.
What I would like to see is proper support for UEFI multiboot. Right now installing a new Fedora next to the live one is difficult since it doesn't support creating individual UEFI boot entried for each installation but only a global one which runs contrary to having this feature in UEFI in the first place. I'm bringing this up because in the UEFI multiboot case you don't care for either the MBR nor a partition bootloader so this use-case should be taken into account.
Bad news:
https://bugzilla.redhat.com/show_bug.cgi?id=759303
Jesse, any chance you're going to change your mind here? :)
That's strange given that the whole point of providing this in UEFI is to fix the battle for the MBR on multiboot systems.
Also what does this mean for UEFI installations with Fedora? When I install F18 will it detect that the UEFI bits already exists on the harddisk and overwrite only the binary bits and only add the new install to the grub menu?
While I get that BIOS stuff needs to be supported for a while I think supporting UEFI multiboot would simplify things because you can separate the installations completely rather than having to deal with updating existing boot structures that could potentially break stuff.
Regards, Dennis
On Sun, 2012-11-04 at 02:36 +0100, Dennis Jacobfeuerborn wrote:
Also what does this mean for UEFI installations with Fedora? When I install F18 will it detect that the UEFI bits already exists on the harddisk and overwrite only the binary bits and only add the new install to the grub menu?
What the current code does is, if you have an existing Fedora entry in the UEFI boot manager, simply erase it and write a new entry. I haven't checked recently what it does with the EFI system partition, but it does not re-use the previous copy of grub(2)-efi.
While I get that BIOS stuff needs to be supported for a while I think supporting UEFI multiboot would simplify things because you can separate the installations completely rather than having to deal with updating existing boot structures that could potentially break stuff.
They're really separate topics and don't need to be considered in relation to each other.
On 11/04/2012 02:50 AM, Adam Williamson wrote:
On Sun, 2012-11-04 at 02:36 +0100, Dennis Jacobfeuerborn wrote:
Also what does this mean for UEFI installations with Fedora? When I install F18 will it detect that the UEFI bits already exists on the harddisk and overwrite only the binary bits and only add the new install to the grub menu?
What the current code does is, if you have an existing Fedora entry in the UEFI boot manager, simply erase it and write a new entry. I haven't checked recently what it does with the EFI system partition, but it does not re-use the previous copy of grub(2)-efi.
But what happens to the files in \EFI\redhat specifically grub.conf? Will this just be updated or overwritten (thus killing the entry for the previous release)?
While I get that BIOS stuff needs to be supported for a while I think supporting UEFI multiboot would simplify things because you can separate the installations completely rather than having to deal with updating existing boot structures that could potentially break stuff.
They're really separate topics and don't need to be considered in relation to each other.
What I was aiming at was that currently in order to install a new Fedora release next to the old one the data in \EFI\redhat needs to be modified carefully to add the new stuff but also keep the old config intact. With proper UEFI multiboot support each release could create a directory \EFI\fedora${releasever} and install the bootloader there with a fresh grub.conf only for that release. Since there is no shared data between the two Fedora version no breakage can happen with the update of grub.efi or grub.conf. The user can then directly boot into both release from the UEFI boot menu rather then first having to select "Fedora" from the UEFI menu and then again select between the releases from the grub menu.
That's what I have to do right now and it's not desirable from a usability point of view for the user and for the maintainers a true separation between the individual installations should simplify things as well.
Regards, Dennis
On Sun, 2012-11-04 at 03:29 +0100, Dennis Jacobfeuerborn wrote:
On 11/04/2012 02:50 AM, Adam Williamson wrote:
On Sun, 2012-11-04 at 02:36 +0100, Dennis Jacobfeuerborn wrote:
Also what does this mean for UEFI installations with Fedora? When I install F18 will it detect that the UEFI bits already exists on the harddisk and overwrite only the binary bits and only add the new install to the grub menu?
What the current code does is, if you have an existing Fedora entry in the UEFI boot manager, simply erase it and write a new entry. I haven't checked recently what it does with the EFI system partition, but it does not re-use the previous copy of grub(2)-efi.
But what happens to the files in \EFI\redhat specifically grub.conf? Will this just be updated or overwritten (thus killing the entry for the previous release)?
Like I said, I haven't tested recently enough to be 100% sure. My guess is that they either just get blown away and rewritten - they're actually owned by the grub2-efi package - or that anaconda creates a second EFI system partition and you wind up with two. I think it did that at one point, but I don't know if it still does. In general, multiple UEFI installs is just not a case that we've covered very well yet. With the current state of Fedora's support, you're just better off sticking to one Fedora install at a time and giving the installer a nice clean slate to work with when you reinstall. One Fedora install per disk is as far as you can push it without having to start fixing stuff up manually, I'd guess.
While I get that BIOS stuff needs to be supported for a while I think supporting UEFI multiboot would simplify things because you can separate the installations completely rather than having to deal with updating existing boot structures that could potentially break stuff.
They're really separate topics and don't need to be considered in relation to each other.
What I was aiming at was that currently in order to install a new Fedora release next to the old one the data in \EFI\redhat needs to be modified carefully to add the new stuff but also keep the old config intact. With proper UEFI multiboot support each release could create a directory \EFI\fedora${releasever} and install the bootloader there with a fresh grub.conf only for that release. Since there is no shared data between the two Fedora version no breakage can happen with the update of grub.efi or grub.conf. The user can then directly boot into both release from the UEFI boot menu rather then first having to select "Fedora" from the UEFI menu and then again select between the releases from the grub menu.
I understand how it could work in theory, yes. I'm on record as saying that UEFI's bootloader design is a deal saner than BIOS's, and should enable much better multiboot co-operation between OSes in an ideal world. It's just not something we currently support very well in practice.
BTW, a directory named after the release version wouldn't be a very good idea, because it'd get very confusing if you did upgrades, and it precludes multiple installs of the same release. It'd probably be best to use some kind of unique identifier.
On 11/04/2012 04:39 AM, Adam Williamson wrote:
On Sun, 2012-11-04 at 03:29 +0100, Dennis Jacobfeuerborn wrote:
On 11/04/2012 02:50 AM, Adam Williamson wrote:
On Sun, 2012-11-04 at 02:36 +0100, Dennis Jacobfeuerborn wrote:
Also what does this mean for UEFI installations with Fedora? When I install F18 will it detect that the UEFI bits already exists on the harddisk and overwrite only the binary bits and only add the new install to the grub menu?
What the current code does is, if you have an existing Fedora entry in the UEFI boot manager, simply erase it and write a new entry. I haven't checked recently what it does with the EFI system partition, but it does not re-use the previous copy of grub(2)-efi.
But what happens to the files in \EFI\redhat specifically grub.conf? Will this just be updated or overwritten (thus killing the entry for the previous release)?
Like I said, I haven't tested recently enough to be 100% sure. My guess is that they either just get blown away and rewritten - they're actually owned by the grub2-efi package - or that anaconda creates a second EFI system partition and you wind up with two. I think it did that at one point, but I don't know if it still does. In general, multiple UEFI installs is just not a case that we've covered very well yet. With the current state of Fedora's support, you're just better off sticking to one Fedora install at a time and giving the installer a nice clean slate to work with when you reinstall. One Fedora install per disk is as far as you can push it without having to start fixing stuff up manually, I'd guess.
While I get that BIOS stuff needs to be supported for a while I think supporting UEFI multiboot would simplify things because you can separate the installations completely rather than having to deal with updating existing boot structures that could potentially break stuff.
They're really separate topics and don't need to be considered in relation to each other.
What I was aiming at was that currently in order to install a new Fedora release next to the old one the data in \EFI\redhat needs to be modified carefully to add the new stuff but also keep the old config intact. With proper UEFI multiboot support each release could create a directory \EFI\fedora${releasever} and install the bootloader there with a fresh grub.conf only for that release. Since there is no shared data between the two Fedora version no breakage can happen with the update of grub.efi or grub.conf. The user can then directly boot into both release from the UEFI boot menu rather then first having to select "Fedora" from the UEFI menu and then again select between the releases from the grub menu.
I understand how it could work in theory, yes. I'm on record as saying that UEFI's bootloader design is a deal saner than BIOS's, and should enable much better multiboot co-operation between OSes in an ideal world. It's just not something we currently support very well in practice.
BTW, a directory named after the release version wouldn't be a very good idea, because it'd get very confusing if you did upgrades, and it precludes multiple installs of the same release. It'd probably be best to use some kind of unique identifier.
So for fun and profit I just went ahead and copied the redhat directory to fedora15, modified the grub.conf to remove all other entries and set the timeout to 0 and installed a bootloader entry with efibootmgr. Now i can boot straight into the old system from the UEFI menu without an additional menu layer. As far as I can tell the only thing missing now would be the ability to tell tools which grub.conf to modify in case of e.g. a kernel update. Other than that a new installation could now completely overwrite the redhat directory and the Fedora bootloader entry and it wouldn't affect the old installation at all which makes installations/upgrades safer and the involved code simpler because it doesn't have to deal with modifying shared data anymore.
Regards, Dennis
On Nov 3, 2012, at 17:03, Adam Williamson awilliam@redhat.com wrote:
Bad news:
https://bugzilla.redhat.com/show_bug.cgi?id=759303
Jesse, any chance you're going to change your mind here? :)
Not for F18.
- jlk
On Nov 4, 2012, at 12:53 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
What I would like to see is proper support for UEFI multiboot. Right now installing a new Fedora next to the live one is difficult since it doesn't support creating individual UEFI boot entried for each installation but only a global one which runs contrary to having this feature in UEFI in the first place. I'm bringing this up because in the UEFI multiboot case you don't care for either the MBR nor a partition bootloader so this use-case should be taken into account.
Well IMO GRUB2 is less than half-baked for UEFI anyway when it comes to Ux. It works, it boots, it's grotesquely inelegant and complicated. There should be a distinction between a boot loader and boot manager, while GRUB2 conflates them into one thing.
A better user experience, by far, for UEFI is rEFInd.efi as the boot manager, and using efistub (the linux efi bootloader) as the bootloader. But then this lacks, at the moment, a nice way to deal with btrfs snapshots and optionally boot them (which GRUB2 can do).
Chris Murphy
On Sun, 2012-11-04 at 00:10 +0100, Chris Murphy wrote:
On Nov 3, 2012, at 10:10 PM, Adam Williamson awilliam@redhat.com wrote:
I don't know, though, if it's actually been implemented yet, or if it's still on someone's todo list. I couldn't find anything in the git log for it, but I may have missed it. I've added bcl and dlehman to the bug and asked them to comment.
Bug 861192?
That was just your specific problem with a certain case of actually installing the bootloader to a partition, doing it manually. It's not the bug for the general case of adding the ability to do so back into anaconda.
I'm a little mystified by people who want to force a bootloader into a file system that doesn't offer a sufficient bootloader region for a bootloader to fit (e.g. ext[234] and XFS). I think there should be a none option, rather than a redirect and force option.
It's not that they want to force a bootloader into a filesystem. They want to multiboot by chainloading, and that's the way you do that.
we should make this possible via a command line parameter rather than a UI option; it's an 'advanced' option that's only of use to multiboot pokemoners (you know...gotta catch 'em all) and is a 'dangerous' option for anyone who doesn't understand it - if you pick it when you don't know what you're doing, you get a non-bootable install.
It seems ugly to implement an esoteric command line parameter that changes the behavior of the Fedora installer. If the capability is valuable, it should be part of the new user interface, and the installer should make a "best effort" attempt to keep the user from shooting himself in the foot - at least warn that this option is dangerous, and demand confirmation this is what the user really wants to do.
you get a non-bootable install.
Actually, one reason a user might choose to put the Fedora bootloader elsewhere than the MBR is to insure his existing boot process remains intact, in the event the new Fedora installation fails to boot, or fails to find and successfully boot his other operating systems already installed.
On Sat, 2012-11-03 at 20:30 -0400, Richard Ryniker wrote:
we should make this possible via a command line parameter rather than a UI option; it's an 'advanced' option that's only of use to multiboot pokemoners (you know...gotta catch 'em all) and is a 'dangerous' option for anyone who doesn't understand it - if you pick it when you don't know what you're doing, you get a non-bootable install.
It seems ugly to implement an esoteric command line parameter that changes the behavior of the Fedora installer.
If the capability is valuable, it should be part of the new user interface, and the installer should make a "best effort" attempt to keep the user from shooting himself in the foot - at least warn that this option is dangerous, and demand confirmation this is what the user really wants to do.
you get a non-bootable install.
Actually, one reason a user might choose to put the Fedora bootloader elsewhere than the MBR is to insure his existing boot process remains intact, in the event the new Fedora installation fails to boot, or fails to find and successfully boot his other operating systems already installed.
I've already had this argument, twice, and am not very interested in rehashing it. If you want to, post to anaconda-devel or in #anaconda, but be ready for flames...:)
-
Adam Williamson -
Chris Murphy -
Dennis Jacobfeuerborn -
Jesse Keating -
Richard Ryniker -
Ron Yorston