Description of problem: When doing a text-based install from the 16-Beta.TC1 DVD (either i386 or x86_64) in a virtual guest (either VirtualBox 4.1.2 or KVM) with an uninitialized dynamically allocated storage device with 30 GB allocated, I get the error === Automatic Partitioning Errors The following errors occurred with your partitioning: you have not created a bootloader stage1 target device. This can happen if there is not enough space on your hard drive(s) for the installation. Press 'OK' to choose a different partitioning option. === If I go back, this happens when I choose either "Use entire drive", "Replace existing Linux system", or "Use free space". Version-Release number of selected component (if applicable): 16.16 on 16-Beta.TC1 DVD (i386 or x86_64) How reproducible: mostly Additional info: Once, when attempting on KVM with the i386 DVD, I got a panic instead. Screenshot attached below. The rest of the attempts on both i386 and x86_64 failed as described above.
Created attachment 520858 [details] one-time panic when attempting to create a KVM guest from the i386 DVD
can you select 'use entire drive' and check 'review and modify partition layout', and see what partition scheme it's coming up with?
Created attachment 520868 [details] text mode partitioning screen Text mode doesn't allow that. Screenshot attached.
Doing a minimal (as opposed to text-based) install from the i386 DVD works using all defaults (at least I'm past the partitioning now), so this is apparently limited to text installs.
So this is happening with most text based installs? If so, I'd say that it pretty clearly violates the following alpha release criterion [1]: The installer must be able to complete an installation using the text, graphical and VNC installation interfaces. Assuming that I'm understanding this correctly, I'm +1 blocker. [1] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
Discussed at 2011-09-02 blocker review meeting. Accepted as a blocker per Alpha criterion "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces". I reproduced this issue, so we have two reporters. (Note my VM has only 8GB of hard disk, but that's big enough for the graphical installer to work with.)
*** Bug 735790 has been marked as a duplicate of this bug. ***
Patch posted: https://www.redhat.com/archives/anaconda-devel-list/2011-September/msg00035.html
This bug inhibits testing several other things - basically any non-graphical-interactive install path - so it would be great to get it fixed quickly. I'm holding off requesting Beta TC2 compose until this is fixed. thanks!
Fixed on f16-branch by 2db3159cd716e977253352b853d38095e8efcfb3 and 7ca041696e377d31e114e4695301e65651043db5 on master.
Appears fixed in 16 Beta TC2 as I can complete text installs normally. Only possible issue is cosmetic: during package installation, a call trace appears on the screen. I can go to a VT and capture it in dmesg output. Screenshot and dmesg output attached below. If this is a different Component I'll file against that.
Created attachment 522246 [details] package installation screen during install from 16 Beta TC2 i386 DVD
Created attachment 522247 [details] dmesg output during 16 Beta TC2 i386 DVD installation (matches screenshot)
(In reply to comment #11) > Appears fixed in 16 Beta TC2 as I can complete text installs normally. Only > possible issue is cosmetic: during package installation, a call trace appears > on the screen. I can go to a VT and capture it in dmesg output. Screenshot and > dmesg output attached below. If this is a different Component I'll file against > that. Those are unrelated to this bug. Probably to be filed against kernel if they haven't been already
Filed bug 736941.
Other than this unrelated cosmetic bug, works for me.
16.18 went stable; closing this.
Happens with F16 (Fedora-16-Beta-x86_64-Live-XFCE) in a Virtualbox VM (host: Mac with MacOS) too. Is this a different bug?
Created attachment 528876 [details] /tmp/storage.log during installation (Fedora-16-Beta-x86_64-Live-XFCE)
(In reply to comment #19) > Created attachment 528876 [details] > /tmp/storage.log during installation (Fedora-16-Beta-x86_64-Live-XFCE) Does this comment help you: https://bugzilla.redhat.com/show_bug.cgi?id=745196#c3 ?
Thanks, but that was not exactly my question. Of course I was able to *workaround* it by creating a "biosboot" partition. Using a bootloader option is a neat trick. What I don't understand is comments like "16.18 went stable; closing this." and "Closing as not a bug". Why is this not a bug? Or is this not an "official bug" in F16-Beta anymore since it has been mentioned in an ERRATA and will be fixed in F16-final? Shouldn't it be closed as "FIXED" then?
(In reply to comment #21) > What I don't understand is comments like "16.18 went stable; closing this." and > "Closing as not a bug". Why is this not a bug? Or is this not an "official bug" > in F16-Beta anymore since it has been mentioned in an ERRATA and will be fixed > in F16-final? Shouldn't it be closed as "FIXED" then? Imagine this scenario: The user uses a kickstart and expects a fully automatic installation. He specifies his packages, root password, timezone, but no root partition. The installation fails, complaining there's no root partition. Is that a bug? Now, the installer determined that your system is going to boot from gpt (the preferred way now). Gpt booting requires a biosboot partition. But you didn't specify one. So it tells you and stops. This bug we are commenting on was another problem: we failed to create the biosboot partition when automatic partitioning was specified (see http://fedoraproject.org/wiki/Anaconda/Kickstart#autopart). If you see such behavior, then yes, that would amount to a bug.
Of course, not specifying a root partition is not a bug. But not specifying a "biosboot" partition (Whatever that is anyway. And whatever this is needed for in a x86-64 virtual machine) is not a user-error, IMHO. The installer should take care of this the same way it creates a partitiontable before creating the partition the user specified. Or loading the network driver before assigning the user-specified IP-address. If the installer *determines* that it'll boot from GPT, then then the installer should take care of doing the needful to make this happen. I don't consider a "biosboot" partition user-supplyable information. In fact, I've installed F15 (and other distros) on GPT disks w/o explicitly specifying a "biosboot" partition. So, I hope that this whole biosboot thingy vanishes from a sysadmin's (read: user's) POV in F16-final. Otherwise bugs like this might get filed over and over again (and then get closed with "NOTABUG" :-))
your problem is not the problem reported in this bug. please don't comment in it, it's just confusing matters. if you think anaconda should automatically create a bios boot partition if you do partitioning manually in a kickstart file but don't provide a bios boot partition, please file that separately.