2:42 p.m.
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
4:10 p.m.
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:
https://bugzilla.redhat.com/show_bug.cgi?id=872826
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:10 p.m.
On Nov 3, 2012, at 10:10 PM, Adam Williamson <awilliam(a)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
6:53 p.m.
On 11/04/2012 12:10 AM, Chris Murphy wrote:
On Nov 3, 2012, at 10:10 PM, Adam Williamson <awilliam(a)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
7:03 p.m.
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(a)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? :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:36 p.m.
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(a)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
8:50 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:29 p.m.
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
10:39 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:34 p.m.
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
10:20 p.m.
On Nov 3, 2012, at 17:03, Adam Williamson <awilliam(a)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
7:13 p.m.
On Nov 4, 2012, at 12:53 AM, Dennis Jacobfeuerborn <dennisml(a)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
7:29 p.m.
On Sun, 2012-11-04 at 00:10 +0100, Chris Murphy wrote:
On Nov 3, 2012, at 10:10 PM, Adam Williamson
<awilliam(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:30 p.m.
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.
7:41 p.m.
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
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4205
days inactive
4206
days old
14 comments
6 participants
participants (6)
-
Adam Williamson -
Chris Murphy -
Dennis Jacobfeuerborn -
Jesse Keating -
Richard Ryniker -
Ron Yorston