Description of problem:
I tried to install from the live CD (F16 Beta RC) using anaconda-16.18-1.fc16.i686
Anaconda recognised the 8Gb USB disk and internal 60Gb SSD. I was offered two locations to install the bootloader
/dev/sdb MBR (this is the USB disk)
/dev/sda1 start of first partition (this is the SSD)
I wasn't able to install the bootloader to the MBR of the internal SSD and thus wasn't able to make the system bootable. Advanced choices didn't include the option to install to the MBR of sda which is what I needed.
Running grub2-install from the command line at the end of anaconda being finished wasn't successful (I tried with --force and --no-floppy but it complained of not recognising the partition.
I repeated this using LVM and not, in both cases I wasn't given the option to install to /dev/sda
Version-Release number of selected component (if applicable):
anaconda-16.18-1.fc16.i686
How reproducible:
100%
Steps to Reproduce:
1.install from live usb disk
2.
3.
Actual results:
no option to install to /dev/sda
Expected results:
system installs to /dev/sda by default and is bootable.
Additional info:
sfdisk didn't recognise the partition table, maybe my bios doesn't recognise it either and that stops the bootloader in /dev/sda1 from working.

This from anaconda program log:
00:57:00,454 INFO program: Running... grub2-install --force --no-floppy (hd0,1)
00:57:05,296 ERR program: /sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea..
00:57:05,300 ERR program: /sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..

that's normal when installing to a partition rather than 'MBR': grub2 doesn't really like to do it, and you have to use --force to make it happen. however, it alone shouldn't be the issue here, it's just a scary message. (anaconda does use --force.)

(In reply to comment #13)
> that's normal when installing to a partition rather than 'MBR': grub2 doesn't
> really like to do it, and you have to use --force to make it happen. however,
> it alone shouldn't be the issue here, it's just a scary message. (anaconda does
> use --force.)
Is the bootloader in /dev/sda1 supposed to boot the system though (without an old grub in the MBR to chainload it for instance)?

no. the option to install to a partition header rather than the 'mbr' is there for those who want to chainload and know what they're doing. the bug here is as you initially suggested, that for some reason you don't get an option to install to the mbr.

Putting grub on the boot partition will require another bootloader to
chainload it.
The reason you were not offered your SSD's MBR as an option is that it has a
GPT disklabel but does not contain a BIOS Boot partition. That's a partition of
type 'BIOS Boot" of size 1MB, which you can create in anaconda.

(In reply to comment #16)
> Putting grub on the boot partition will require another bootloader to
> chainload it.
>
> The reason you were not offered your SSD's MBR as an option is that it has a
> GPT disklabel but does not contain a BIOS Boot partition. That's a partition of
> type 'BIOS Boot" of size 1MB, which you can create in anaconda.
Ah.. I used the whole disk option in Anaconda, so the unusual GPT disklabel thing comes from that. Should Anaconda be more proactive in offering to create a BIOS boot partition (should it even be the default?)

anaconda is actually supposed to pop up a dialog if you're installing to a GPT-labelled disk without a BIOS boot partition, and not let you out of the partitioning stage without one. And if you use the 'complete disk' option rather than custom partitioning, it's supposed to create one for you.
we're not entirely clear why it didn't in your case. It may be something to do with the presence of the USB stick (/dev/sdb) confusing it.

That's unfortunate!
When I added a BIOS boot partition manually, it then still offered to put grub2 on the boot partition (/dev/sda2 now) or the USB disk. I went for the boot partition but the resulting disk doesn't look bootable from this BIOS. I think maybe I should add some flags to the BIOS boot partition (I didn't look closely so there may have been a check box I missed in anaconda).
From parted there are a bewildering array of options for toggling flags on partitions and it's not clear which I should use... boot, bios_grub or legacy_boot? And for which partitions, BIOS boot (/dev/sda1) or linux boot (/dev/sda2)?

(In reply to comment #19)
> That's unfortunate!
>
> When I added a BIOS boot partition manually, it then still offered to put grub2
> on the boot partition (/dev/sda2 now) or the USB disk. I went for the boot
Can you upload /tmp/storage.log from this last attempt?
> partition but the resulting disk doesn't look bootable from this BIOS. I think
> maybe I should add some flags to the BIOS boot partition (I didn't look closely
> so there may have been a check box I missed in anaconda).
There's not much to it. It's just a raw/empty partition with the bios_grub flag set, which anaconda will do.
>
> From parted there are a bewildering array of options for toggling flags on
> partitions and it's not clear which I should use... boot, bios_grub or
> legacy_boot? And for which partitions, BIOS boot (/dev/sda1) or linux boot
> (/dev/sda2)?
bios_grub on sda1. sda2 should be bootable. Anaconda should have done this for you.

Discussed in the 2011-09-16 blocker review meeting. We agreed that there isn't enough information to make a decision on the blocker status of this bug right now. It will be revisited when more information is available

I'm going to repeat the install and will upload the log. I have been fiddling with the GPT using parted and the best looking partition I can get is:
Model: ATA OCZ-VERTEX2 (scsi)
Disk /dev/sda: 60.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 526MB 524MB ext4 ext4 boot
3 526MB 37.1GB 36.6GB ext4
4 37.1GB 42.2GB 5067MB linux-swap(v1)
5 42.2GB 60.0GB 17.9GB ext4
A 1Mb bios boot partition with the bios grub flag set, boot partition (/dev/sda2) with grub in it. This does not boot on my netbook (Insyde BIOS rev F12, HP mini 311c 1101SA). The BIOS doesn't recognise it as a system or bootable disk.
I will repeat the install to get the logs, but will then try using fdisk to make a traditional disk layout and get Anaconda to retry that.
If this doesn't turn out to be a blocker, because we don't know how many systems might be affected, at least it would be good to have the default GPT well documented and a traditional workaround available in case systems are installed non-bootable.

Created attachment 523687[details]
storage.log copied after the filesystems have been laid out but before the bootloader is installed
I used LVM and whole disk, then edited the partitions. I had to steal 1Mb from the boot partition before anaconda would let me create the bios boot partition. Bios boot was then /dev/sda1 and linux boot was bumped to /dev/sda3.
Anaconda offered to install the bootloader to /dev/sda3 or /dev/sdb (live USB MBR)

I was able to install successfully by using the last option in Anaconda - create my own partition layout. The top two options seem to enforce GPT based layouts.
I used fdisk to check the layout and mark the boot partition bootable.

3 tests fail
1 network install of usb key default next next with unhashed lvm partion mbr gets installed on usb
2. Dvd on usb key same result
3. netboot of cd same result as in unbootable since it kinda goes without saying you cant write on the cd.
Definitely a Beta blocker

Custom partitioning also fails resulting in unbootable system
Just out of curiosity cold hard reality how prepared is anaconda for Grub2 ?
Is there a mandatory mbr partitioning that does not get created by default beside /boot?

I used live tools to create the the bootable usb key and used x86_64 bit
Icelandic keyboard
Installed using whole disk
Anaconda shows USB and HD on left side; choose HD for install ==> to right ( Internal HD as in /dev/sda ) and I also clicked that circle in front of the HD for install.
Rest default next next...
All installation resulted in the bios not finding the master boot record on the internal drive.
When installing both via netboot and via dvd it installed the required boot partition on the usb key.
( bios found that one and successfully booted off it )
Performing netboot install of the cd resulted in the same thing.

damn, sorry, seem to have got bugs mixed up at some point. This one is for installing *from live*. satellit, johann: can you please file a new bug for the traditional-install-image-written-to-usb case? we should keep this for the live case.

I just hit something similar to cam's issue. I did a live install in a VM which had a USB key attached (via USB host passthrough), and anaconda failed to write a BIOS boot partition. I chose 'erase entire disk' with LVM checked, and didn't adjust the partitioning at all. I chose the VM's hard disk as an install target and did *not* choose the USB key as one, I left it on the left-hand side of the dialog.
There's some weird stuff going on in storage.log. The USB stick is /dev/sda ; it gets _gpt_disk_has_bios_boot partition run on it repeatedly, despite the fact that it a) is not an install target and b) does not have a gpt disk label (it's ms-dos). The test returns True, despite the fact that the USB stick does not have anything that resembles a BIOS boot partition; it's a single giant ext4 partition. The test is also run against vda - the VM's hard disk and actual install target - and fails as it should.
I see "skipping unneeded stage1 biosboot request" just after the first two runs of _gpt_disk_has_bios_boot against sda and vda. It subsequently gets run another two times against vda and three against sda.
Will attach all logs.

oh, i see. gpt_disk_has_bios_boot should return 'true' for sda, it's designed to only return false if the disk is gpt-labeled and has no bios boot partition - so if the disk is msdos-labeled, then the test passes.
but if I set the disk in question only as storage and did not radio-button it as the bootloader target, it should not be considered a candidate for bootloader installation.

Created attachment 523929[details]
storage.log from my test
sda is the USB stick attached to the system: it's not being installed from, it's just a device that's present. I did not choose it as an install target.
vda is the actual target drive, it's the VM's hard disk.
it looks like there's a hole in the logic somewhere: if you have a device present which passes the is_valid_stage1_device test and a device present which doesn't, and you explicitly pick the device which doesn't as the bootloader target, instead of checking whether it can make the chosen device pass the test, anaconda just decides the device which passes the test is a better candidate and goes with it.

I was able to reproduce this using anaconda-16.18-1 using the following setup:
KVM virtual machine
- minimal x86_64 install using netinstall boot.iso
- 20G disk (install target
- 10G disk (contains nothing, just exists on the system)

so i'm figuring some stuff out by inference here.
this same basic bug affects live and regular installs, but it looks slightly different.
in a regular install, you pick the bootloader location *after* partitioning and package install. in a live install, you pick it before.
in a live install, you can pick the hard disk, but it then decides not to install to it after all. in a regular install, it doesn't show the hard disk mbr as an option.
so it seems like anaconda checks for potential bootloader targets at the partitioning stage. if the only disk available doesn't have a bios boot partition, it decides to create one, and all's good; but if the target disk doesn't have a bios boot partition, but any other device it sees looks like a valid bootloader target, it figures that's good enough, and doesn't bother creating a bios boot partition on the target disk.
so in the regular install case, it then does the bootloader check again, figures that the target disk is no good, and doesn't offer to let you install the bootloader to the MBR of the target disk: it gives you a choice of the MBR of the 'valid' disk, or /boot on the target disk. in the live install case, it doesn't have any UI at that point, so it just decides for itself to install to the MBR of the 'valid' disk.
it looks like there's a few weak points in this chain, but the best thing to do might be to always have the bootloader target device selection done *before* the partitioning step, and have it try harder to use the target device at partitioning: if it's invalid but it can be made valid (by e.g. creating a BIOS boot partition...), do that. if it absolutely can't manage to do what you asked for, ask you again. that's a pretty major change for the non-live installer, though...
assigning to dlehman, this is his area.

(In reply to comment #35)
> so i'm figuring some stuff out by inference here.
>
> this same basic bug affects live and regular installs, but it looks slightly
> different.
I'm wondering if there can be a better way of testing this. How viable would it be to record a data set representing the interesting / relevant aspects of a system as seen by Anaconda; then record the user choices as another data set. Would it then be possible to record the actions of Anaconda and wrap the whole lot up in a regression test suite that gives developers a good impression that changes to Anaconda's logic are likely to result in a working install and not likely to break anything?
When it works, it's amazing, and seems faster every time it changes (or is that my move to SSD), but it seems far too easy to break.

At least part of the problem is indeed the difference between automatic
partitioning and custom partitioning: if you use automatic partitioning you
choose your boot device before partitioning, while if you enter the custom
partitioner you can choose the boot device afterwards. This is hard to fix for
F16.
Another problem is related to the filtering of devices suitable as bootloader
stage1 and stage2 devices. We have a concept of "protected" devices in
anaconda, but there's a difference between being able to repartition and being
able to write a bootloader to a device. I have uploaded an updates image that
should improve this by marking as protected not only the live image's backing
device but also whatever devices it resides on. Currently, if the backing
device is a partition we only mark the partition as protected, and on non-live
installs we don't even do that even though there is a live-rw device that needs
protecting. With my updates we'll a) protect the backing device in both live
and non-live installs and b) in the case of a partition we will mark both it
and the disk it resides on as protected. This should resolve most of what's
being reported here.
I'm not in my normal work environment so this image is completely untested.
http://dlehman.fedorapeople.org/updates-738964.img

I came to about the same conclusion in re the live image :). Unfortunately, there's still one significant failure case the above fix won't address - the case where you have two hard disks, one with a safe F15 (say) installation on it, and one for 'experiments'. If you install F16 to the 'experiment' disk, you'll likely hit this bug, and F16's bootloader will get written to the MBR of the 'safe' disk, which is pretty impolite. This is the case tflink hit.

(In reply to comment #40)
> New updates available. These should come about as close as possible to making
> sure that all disks that might need a bios boot partition have one. Also
> untested.
>
> http://dlehman.fedorapeople.org/updates-738964.1.img
When I try this update, I get the following traceback immediately after selecting language and keyboard layout:
Traceback (most recent call last):
File "/usr/sbin/anaconda", line 582, in <module>
from pyanaconda import kickstart
File "/tmp/updates/pyanaconda/storage/__init__.py", line 21, in <module>
from storage.deviceaction import *
File "/tmp/updates/pyanaconda/storage/__init__.py", line 42, in <module>
from devicetree import DeviceTree
File "/tmp/updates/pyanaconda/storage/devicetree.py", line 1041
root_path = os.path.realpath(value.split(":", 1)[1]))
^
SyntaxError: invalid syntax

looks like one parenthesis too many...
the background on the proposed fix is it basically sticks a bios boot partition on any gpt disk it can find, if there's space for one. this is a big hammer, but it sure ought to sort out this bug. :) we will need to do careful testing of it, though.

I'm a bit doubtful about the default of using GPT, having tried it on two machines and my best efforts failing to make either one boot. Are there any hard facts about compatibility? Maybe there are further bugs in the way Grub2 / Anaconda put together the GPT.
I'm thinking LVM merits a prominent opt-out check box, yet it's not half as dangerous as GPT from my experience.

cam: we're pretty clear on the bug, and how to fix it. the entire partitioning / bootloader bit of anaconda is being fundamentally redesigned for f17 anyway, so for f16, we just get to whack it with the big hammer.
gpt is not really the same case as lvm. gpt disk labels, and grub2, are The Future, with capital letters: we need to make them work properly. long experience has taught us that the fastest way to shake out all the bugs in supporting some Shiny New Thing is to get as many people using the SNT as possible in order to expose all the bugs. you are currently the meat in this particular sausage. =) given that pretty much everything going forward is going to have a gpt disk label and boot via grub2, it doesn't really make sense to have an 'opt out' option: we just need to suck it up and get the conversion done. remember, you're not even testing a beta, but the *release candidate* for a beta...this is kind of what's supposed to happen.
this isn't really an issue with gpt per se. there is nothing wrong with the disk label written to your machines. it's more to do with anaconda's workflow being based on assumptions that are valid for an msdos/grub world but are not really true for a gpt/grub2 world. this is a pretty classic bug category, and it's usually impossible to think through *all* the implications in advance: you have to throw actual use at the SNT, and then you realize all the things that look obvious with hindsight - like 'a bootloader location choice is not much use if it comes after the partitioning screen where you could have created the partition you'd need to install the bootloader where you want to install it.'
To be specific as to what happened in your case: you chose custom partitioning. if you choose that path, in current anaconda, you get to choose where the bootloader is installed much later in the install process than you do the partitioning step. Now, booting from a disk with a gpt disk label on a BIOS-based system with grub2 requires there to be this 'bios boot partition' thing on the disk.
In the simplest case - you install from a DVD on a system with one disk, and wipe that disk entirely - anaconda realizes at the partitioning stage that you won't be able to boot the system without the BIOS boot partition. There's only one place you could put the bootloader - on the target disk - and to do that, you need the special partition. So it forces you to create it.
In your case, though, there was another disk present: the USB stick you were installing from. anaconda has code to not consider a USB stick it's installing from as a valid target for installation, but thanks to this bug, we realized it only excepts it from consideration as a place *to put the system files*: it doesn't except it from consideration as a place where you could put the bootloader.
So in your case, at the partitioning stage, anaconda knew that you wouldn't be able to boot from your hard disk - but it then took a look at your USB stick, which passed all the tests required for a device to be a valid bootloader location, and thought 'hey, there's at least one valid place to put a bootloader', and moved straight along: it didn't see any need to alert you that you'd need a BIOS boot partition to boot from your hard disk, because that's not how the check is written to run.
That meant that when you got to the bootloader installation choice screen, anaconda correctly did not list your hard disk (at least, the 'mbr' of it) as a place you could put the bootloader - because it knew you *couldn't* put the bootloader there, it wouldn't work. there's no provision to 'go back' to the partitioning stage and put in a bios boot partition (and anyway, that might well not help, as you might already have partitioned up the entire disk by this point).
in a sense anaconda was never 'wrong', but it's clearly sub-optimal behaviour, because you're not likely to actually want to put the bootloader on the USB stick you're installing from. :)
there's several angles of attack for this. one that would fix your specific case of this bug is simply to extend the 'don't consider the USB stick we're installing from as a valid install target' code to also except it from consideration as a valid bootloader location; this was one way dave considered fixing this, but there are other cases of the bug which wouldn't be fixed by that. so in the end we decided that it's 'safest' - in the sense of being sure this bug is fixed - to just write a bios boot partition to any gpt-labelled disk we find, as long as there's space for one (and it doesn't have one already). that way, they'll all definitely be available as bootloader installation targets.
For F17, it'll likely be possible to make this more fine-grained, because the partitioning and bootloader installation steps will be ordered more sensibly. But it would be too disruptive to change that in F16.
are we likely to find other things like this that need rejigging in the Brave New World? well, probably. that's what betas are for. We're not *always* kidding when we say they can eat your babies.
In a larger sense, that's what *Fedora* is for: we do a lot of trying out the shiny new things when they're very shiny and very new.
well, I hope that explained things a bit :)

(In reply to comment #44)
> In a larger sense, that's what *Fedora* is for: we do a lot of trying out the
> shiny new things when they're very shiny and very new.
>
> well, I hope that explained things a bit :)
Thanks for the explanation, I take the Anaconda bugs part, but I still don't understand why my system wasn't bootable at all with GPT. Neither was another netbook I tried. Around about comment 22 I described my attempt to get it to work, and I tried several more variations, ensuring there was a BIOS boot partition. The BIOS just wouldn't boot from this.
I will keep testing GPT based installs to see if they start to work, but for now the only thing that seems reliable is the traditional disk layout.

cam: I think the options don't do what you think they do. 'use existing Linux partitions' does not mean 'try and install to the partitions that are present': it means 'use the space occupied by existing Linux partitions by destroying them and creating new ones in their place'. If you look at the log attached to comment #22 - search for 'clearpart' - you'll see anaconda deleting all those partitions you carefully prepared and creating new ones...not including a bios boot partition, due to this same bug. Right after the clearpart bit, you see it run its is_valid_stage1_device check again, find that sda fails but sdb passes, and skip creating a bios boot partition - "skipping unneeded stage1 biosboot request". Then it goes on to create its new partitions.
you can't really pre-create partitions and then have anaconda install to them by any means other than selecting 'custom layout' and then telling it to mount, but not format, the partitions you pre-created.

I would implore you to consider 4096 byte sector USB spindles when you're working through this BIOS/GPT/GRUB2 issue, as I've been trying to set up a new 3TB Seagate USB drive as a secondary boot disk (to plug in and boot my test distros in the same manner that I've been able to in the past with a 250GB WD USB "Book" drive with MBR partitioning on it). I've been unsuccessful with either F16pre-beta or Ubuntu Oneiric Ocelot (11.10) beta, despite having a 1MB bios_grub as the first partition on the drive. My laptop is an HP9000z (about 4 years old) with a Phoenix BIOS that doesn't recognize GPT/EFI at all, and limits me a choice of two spindles. Usually they're the two internal SATA hard drives, but when I plug in the 250GB WD drive, it sees it as the second drive and I can boot off of it. Not so with the 3TB Seagate with a GPT on it. (It's been very unclear if either F16 or Oneiric actually wrote a boot block to the Seagate spindle - I don't even get a GRUB> prompt as a teaser!)
Having gutted through SNTs such as PulseAudio and NetworkManager, I'm ready to test GPT/GRUB2 on a BIOS-based laptop.

Created attachment 524273[details]
storage.log from successful install using .4 update
I was able to successfully install when 2 disks were present using the .4 updates image.
Note that while this isn't part of the originally reported issue, it was still showing the same symptoms.

Discussed during the 2011-09-21 Fedora 16 beta go/no-go meeting. Accepted as a blocker for Fedora 16 beta because it violates the following alpha release criterion [1] :
In most cases, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode.
Since this bug can cause problems with existing installations and result in non-bootable installations, it was judged common enough to take as a blocker.
[1] http://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria

I ran a test of the two-hard-disk case.
Procedure:
1) create a VM with two hard disks, both VirtIO backed by image files on the host.
2) install Fedora 15 from the DVD to the first disk (/dev/vda), using 'use all space' and selecting only /dev/vda as an install target, leaving /dev/vdb out completely.
3) confirm the F15 install boots and works, using grub1.
4) install Fedora 16 from the Beta RC1 DVD to the second disk (/dev/vdb - note, I made the disks different sizes, so I could be sure which was which, despite any potential enumeration issues), using 'use all space' and selecting only /dev/vdb as an install target, leaving /dev/vda out completely. Click the radio button for /dev/vdb as the bootloader install location on the 'device selection' screen.
I performed this exact procedure twice, once using the F16 Beta RC1 DVD only, once using updates-738964.4.img. In the first case, the result was thus:
* grub2 on vda's MBR, loading its config and second stage from vdb, with only Fedora 16 entries in the menu
* no bootloader in vdb's MBR
upshot: neither drive could boot with the other drive disconnected, and it was impossible to access F15, though F16 would boot correctly from this configuration.
In the second case, the result was thus:
* grub-legacy remained on vda's MBR, loading its config and second stage from vda, with only Fedora 15 entries in the menu
* grub2 on vdb's MBR, loading its config and second stage from vdb, with only Fedora 16 entries in the menu
This is clearly a significant improvement, and I encountered no bugs in this test.
(It's worth noting as an aside that I actually could not boot the F16 disk in the second case; I couldn't seem to convince KVM to boot from it even by using the boot menu, it would always boot from the F15 disk. Disconnecting the F15 disk from the VM would cause it to try and boot from the F16 disk, confirming that the bootloader was present there, but it would fail to find the root device and boot to dracut's rescue mode. But I think that's beyond the scope of this bug; anaconda did its job correctly. I suspect that it would work in the case of real hardware - at least, you'd be able to make the BIOS boot from the second disk without disconnecting the first).

as a fallback, if we're struggling, we could go with a build that tightens up the exclusion check for installer media and tries harder to honor the user's choice of bootloader location. If done right that should fix most problem paths except custom partitioning, and that one is not actually a Beta blocker.

The updates=http://dlehman.fedorapeople.org/updates-738964.4.img patch allowed Anaconda to offer me a new additional partition (sdc8) that was a bios_boot partition and offered to format it for me and use it as my bios_boot partition. That was nice, but it kind of ignored the one that I tried to set up/reserve at sdc1, although it's possible that mine wasn't quite big enough. In any case, it did NOT allow me to specify a boot location of "sdc", only "sda" (my first internal hard drive) or "sda4" (my system partition). I chose the latter, and it (understandably) still won't boot. I'm in the process of adjusting my openSUSE 11.4 legacy GRUB 0.97 boot stanza to point to whatever the UUID for sdc4 is now.
(When it tried to boot off of the "wrong" one, Dracut came up on the black screen, but I didn't know how to coax it into starting a real system from there).

Only reason I can think of stems from reading the info file for GRUB2 which seems to imply that if there's already a boot block on the spindle, it won't write another one. However, as I said earlier, I couldn't prove that one way or the other. BTW, the disk was carved up as follows (but has since been overwritten):
GNU Parted 2.3
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Seagate FA GoFlex Desk (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB BIOS boot partition bios_grub
2 2097kB 539MB 537MB ext4 boot
3 539MB 4834MB 4295MB Linux swap
4 4834MB 112GB 107GB ext4 boot
5 112GB 220GB 107GB Linux filesystem
6 220GB 327GB 107GB Linux filesystem
7 327GB 434GB 107GB Ubuntu boot
8 434GB 434GB 1049kB bios_grub
I just did another installation, using David Lehman's patch and followed your suggestion that I let Anaconda have its way with the spindle. It didn't boot, and instead, as usual, the openSUSE 11.4 legacy GRUB 0.97 splash came up.
It now looks like this (as seen from openSUSE 11.4):
GNU Parted 2.3
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Seagate FA GoFlex Desk (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 525MB 524MB ext4 boot
2 525MB 526MB 1049kB bios_grub
3 526MB 3001GB 3000GB lvm
I can't mount /dev/sdb3 (as it's an LVM member), but I did mount sdb1 and
sniffed around. There's a decent looking grub.cfg, and it wants to
set root='(hd2,gpt1)' which is all well and good, but my BIOS thinks that
spindle is 'hd1'. F16's device.map says:
# this device map was generated by anaconda
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc
(hd2,1) /dev/sdc1
So, I'm thinking this is the classic case of needing to twiddle with that
to get the drives ordered properly. (Been there, been doing that for about
2-3 years with the other USB drive...). I'll look at it in the morning, but
it's heartening to see that the GPT is OK, and that Anaconda *did* offer to
write the bootloader to the 3TB drive. Whether it actually did so is TBD.

Created attachment 524674[details]
storage log showing "out of space" error using .7 update
While cleaning off the existing partitions to set up for testing, I got a dialog box with "Could not allocate requested partitions, not enough free space on disks".

7-nohammer does fix my two-hard-disk reproducer, where the first hard disk has a working F15 install, the second is blank, and the second is chosen as the install target and bootloader device: even without the hammer, a bios boot partition is created on the second disk and the bootloader written to the second disk's MBR. I'm able to boot the second disk by disconnecting the first (I didn't use LVM for the second disk this time).
didn't try and reproduce tflink's issue yet. will now test the 'random usb key' case, then go on to think of others.

Created attachment 524682[details]
error when reformating bios boot partition
I was also able to receive "Could not allocate requested partitions: not enough free space on disks." error. This happened when I selected existing BIOS Boot partition and selected to reformat it (to the same type). I used .7-nohammer.img. Attaching traceback log.

'random USB stick' test case is good with -nohammer: this is the one where I first reproduced the bug, doing an install in a VM from the live 'CD' to the VM's hard disk, with a USB stick attached during install. without the fix, anaconda puts the bootloader on the USB stick. With -nohammer, if I select the hard disk as the target device, it puts the bootloader on the hard disk.
so far the fixes in -nohammer are looking good, but the bug tflink and kparal hit needs to be fixed before we can go ahead, I think.

I tested both with the same setup as previously, but added an external USB hard
disk, so had:
Internal SSD with F16 installed
Bootable USB flash device
External USB hard disk
I used .7-nohammer and tried custom layout including a BIOS boot partition. The
closest option for installing a bootloader was /dev/sdc2 (the boot on the
external disk I think) which only booted as far as a GRUB string.
Second test was with .7, I used the whole disk and was given the option to
install to the MBR at last. Strangely I had the desktop trying to mount the
external disk, so had to click 'eject' (on the notification), then Anaconda
wouldn't recognise the external disk until I replugged it (it reappeared as
/dev/sdd). Anyway the installation went smoothly and, I'm pleased to say it
made the disk bootable, GPT and all.
I haven't checked to see if the internal SSD has been affected, I will try and
reinstall that next. It may be that I can get .7-nohammer to work if I try the same approach I used for .7

yes, please re-test with .7-nohammer using 'use entire disk'.
we're hitting various issues with the 'custom partitioning' path, but that's not actually beta-critical, and given how hard it seems to be to zap this damn bug, we might have to settle for shipping it as long as the non-custom paths seem to work well.

fwiw, I have a VM here which seems to act the same as cam; if you have a 'spare' USB stick attached and use custom partitioning, even though you ensure that there's a BIOS boot partition on the hard disk - and I checked via storage.log that is_valid_stage1_device returned true for vda - the bootloader location choice dialog from the custom partitioning path only offers the MBR of sda or the /boot partition of vda. It seems like the dialog just can't cope with two possible MBR locations being available, and only offers you one.

Created attachment 524691[details]
traceback using .7-nohammer.img and fulldisk autopart with 2 disks
Using the same setup as comment 69, I tried using the "Use all space" option with BOTH 160GB disks.
I got a crash during partitioning, will attach tb and storage.log

Well, we just discovered something that explains quite a lot. updates-738964.7-nohammer.img has the hammer; it is byte-identical to .7.img.
So all the tests we did with that image actually included the hammer. On the one hand, that likely explains the tb that tflink and I have been hitting, but on the other hand, it means we have no testing to ensure that the fixes without the hammer are enough to solve the bug.
anaconda 16.19 has been built without the hammer, and tflink is building a boot.iso for us to test with that version of anaconda in it. We can re-test our reproducers with that boot.iso and see how things stand.

Cam, I know that ironically your exact initial case of this bug has not been solved. I'm planning to file two new bugs about that, though, to keep things straight; this bug is a huge monster and it's probably best off closed.

Filed https://bugzilla.redhat.com/show_bug.cgi?id=740986 to suggest adding an advisory warning in the case where you do custom partitioning and don't create a BIOS boot partition, but there's some other disk which would be a valid bootloader location (currently anaconda doesn't give you any warning in this case).

Aargh .. Thanks for the tip. I could successfully install grub2 to /dev/sda using grub2-install /dev/sda but the system is not booting up. I am using Lenovo T420 with UEFI BIOS and I tried all UEFI options -> UEFI only / Legacy only / Both. It just shows me the option to select the hard disk for booting up and then grub does not load. Its as if its not reading from the MBR.

vivek: ah. Just caught that you're on a Thinkpad. You're almost certainly hitting https://bugzilla.redhat.com/show_bug.cgi?id=735733 : some thinkpads appear not to be capable of booting via BIOS from a GPT-labelled disk.
For Final, we'll have a workaround available for this.

Note

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