|Summary:||text mode install fails ("you have not created a bootloader stage1 target device")|
|Product:||[Fedora] Fedora||Reporter:||Andre Robatino <robatino>|
|Component:||anaconda||Assignee:||Ales Kozumplik <akozumpl>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||akozumpl, anaconda-maint-list, awilliam, jonathan, jzeleny, kparal, redhat, tflink, vanmeeuwen+fedora|
|Fixed In Version:||anaconda-16.17-1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-09-23 00:43:26 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||713564, 728923|
Description Andre Robatino 2011-08-31 16:21:59 UTC
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.
Comment 1 Andre Robatino 2011-08-31 16:24:05 UTC
Created attachment 520858 [details] one-time panic when attempting to create a KVM guest from the i386 DVD
Comment 2 Adam Williamson 2011-08-31 17:02:46 UTC
can you select 'use entire drive' and check 'review and modify partition layout', and see what partition scheme it's coming up with?
Comment 3 Andre Robatino 2011-08-31 17:55:29 UTC
Created attachment 520868 [details] text mode partitioning screen Text mode doesn't allow that. Screenshot attached.
Comment 4 Andre Robatino 2011-08-31 18:19:30 UTC
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.
Comment 5 Tim Flink 2011-09-02 15:54:14 UTC
So this is happening with most text based installs? If so, I'd say that it pretty clearly violates the following alpha release criterion : 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.  https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
Comment 6 Adam Williamson 2011-09-02 17:32:55 UTC
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.)
Comment 7 Ales Kozumplik 2011-09-05 12:42:39 UTC
*** Bug 735790 has been marked as a duplicate of this bug. ***
Comment 8 Ales Kozumplik 2011-09-06 12:05:11 UTC
Comment 9 Adam Williamson 2011-09-07 21:52:37 UTC
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!
Comment 10 Ales Kozumplik 2011-09-08 06:01:45 UTC
Fixed on f16-branch by 2db3159cd716e977253352b853d38095e8efcfb3 and 7ca041696e377d31e114e4695301e65651043db5 on master.
Comment 11 Andre Robatino 2011-09-09 05:51:27 UTC
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.
Comment 12 Andre Robatino 2011-09-09 05:52:47 UTC
Created attachment 522246 [details] package installation screen during install from 16 Beta TC2 i386 DVD
Comment 13 Andre Robatino 2011-09-09 05:53:51 UTC
Created attachment 522247 [details] dmesg output during 16 Beta TC2 i386 DVD installation (matches screenshot)
Comment 14 Ales Kozumplik 2011-09-09 06:12:08 UTC
(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
Comment 16 Andre Robatino 2011-09-10 03:50:27 UTC
Other than this unrelated cosmetic bug, works for me.
Comment 17 Adam Williamson 2011-09-23 00:43:26 UTC
16.18 went stable; closing this.
Comment 18 Christian Kujau 2011-10-18 19:06:02 UTC
Happens with F16 (Fedora-16-Beta-x86_64-Live-XFCE) in a Virtualbox VM (host: Mac with MacOS) too. Is this a different bug?
Comment 19 Christian Kujau 2011-10-18 19:07:28 UTC
Created attachment 528876 [details] /tmp/storage.log during installation (Fedora-16-Beta-x86_64-Live-XFCE)
Comment 20 Ales Kozumplik 2011-10-19 05:46:45 UTC
(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 ?
Comment 21 Christian Kujau 2011-10-20 07:27:39 UTC
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?
Comment 22 Ales Kozumplik 2011-10-20 08:05:34 UTC
(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.
Comment 23 Christian Kujau 2011-10-20 09:53:21 UTC
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" :-))
Comment 24 Adam Williamson 2011-10-20 18:33:51 UTC
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.