Bug 734861

Summary: text mode install fails ("you have not created a bootloader stage1 target device")
Product: [Fedora] Fedora Reporter: Andre Robatino <robatino>
Component: anacondaAssignee: Ales Kozumplik <akozumpl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: akozumpl, anaconda-maint-list, awilliam, jonathan, jzeleny, kparal, redhat, tflink, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: anaconda-16.17-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-23 00:43:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 713564, 728923    
Attachments:
Description Flags
one-time panic when attempting to create a KVM guest from the i386 DVD
none
text mode partitioning screen
none
package installation screen during install from 16 Beta TC2 i386 DVD
none
dmesg output during 16 Beta TC2 i386 DVD installation (matches screenshot)
none
/tmp/storage.log during installation (Fedora-16-Beta-x86_64-Live-XFCE) none

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 [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

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 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 15 Andre Robatino 2011-09-09 06:47:05 UTC
Filed bug 736941.

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.