Created attachment 775912 [details]
Anaconda traceback log file from /tmp

Thanks for your report.

"... a new PC (Dell) with Windows 7 preinstalled ..."
Do you know how Dell came up with sector 36?

Bug 979805 also reports a bootloader install failure due to an insufficient post-MBR gap:
Bug 979805 - insufficient post-MBR gap not detected before installation

In that case, the first partition began at sector 28 (Bug 979805, Comment 2).

For the record, the grub2 documentation says:
"You must ensure that the first partition starts at least 31 KiB (63 sectors) from the start of the disk; on modern disks, ..."
http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation

Snippet from attached anaconda-tb-sazfOB:
...
13:59:33,557 DEBUG blivet:     DeviceTree.addUdevDevice: info: {'DEVLINKS': '/dev/disk/by-id/scsi-36b8ca3a0ec0ed3001972a6cb137aca11-part1 /dev/disk/by-id/wwn-0x6b8ca3a0ec0ed3001972a6cb137aca11-part1 /dev/disk/by-label/DellUtility /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:0:0-part1 /dev/disk/by-uuid/5450-4444',
 'DEVNAME': 'sdc1',
 'DEVPATH': '/devices/pci0000:00/0000:00:01.1/0000:02:00.0/host7/target7:2:0/7:2:0:0/block/sdc/sdc1',
 'DEVTYPE': 'partition',
 'ID_BUS': 'scsi',
 'ID_FS_LABEL': 'DellUtility',
 'ID_FS_LABEL_ENC': 'DellUtility',
 'ID_FS_TYPE': 'vfat',
 'ID_FS_USAGE': 'filesystem',
 'ID_FS_UUID': '5450-4444',
 'ID_FS_UUID_ENC': '5450-4444',
 'ID_FS_VERSION': 'FAT16',
 'ID_MODEL': 'PERC_H310',
 'ID_MODEL_ENC': 'PERC\\x20H310',
 'ID_PART_ENTRY_DISK': '8:32',
 'ID_PART_ENTRY_NUMBER': '1',
 'ID_PART_ENTRY_OFFSET': '36',
 'ID_PART_ENTRY_SCHEME': 'dos',
 'ID_PART_ENTRY_SIZE': '65952',
 'ID_PART_ENTRY_TYPE': '0xde',
 'ID_PART_TABLE_TYPE': 'dos',
 'ID_PATH': 'pci-0000:02:00.0-scsi-0:2:0:0',
 'ID_PATH_TAG': 'pci-0000_02_00_0-scsi-0_2_0_0',
 'ID_REVISION': '2.12',
 'ID_SCSI': '1',
 'ID_SCSI_SERIAL': '0011ca7a13cba6721900d30eeca0a38c',
 'ID_SERIAL': '36b8ca3a0ec0ed3001972a6cb137aca11',
 'ID_SERIAL_SHORT': '6b8ca3a0ec0ed3001972a6cb137aca11',
 'ID_TYPE': 'disk',
 'ID_VENDOR': 'DELL',
 'ID_VENDOR_ENC': 'DELL',
 'ID_WWN': '0x6b8ca3a0ec0ed300',
 'ID_WWN_VENDOR_EXTENSION': '0x1972a6cb137aca11',
 'ID_WWN_WITH_EXTENSION': '0x6b8ca3a0ec0ed3001972a6cb137aca11',
 'MAJOR': '8',
 'MINOR': '33',
 'MPATH_SBIN_PATH': '/sbin',
 'SUBSYSTEM': 'block',
 'TAGS': ':systemd:',
 'UDISKS_IGNORE': '1',
 'USEC_INITIALIZED': '43675',
...

(In reply to Steve Tyler from comment #2)
> Thanks for your report.
> 
> "... a new PC (Dell) with Windows 7 preinstalled ..."
> Do you know how Dell came up with sector 36?

I have no idea; but 36 is at least better than 63 for sector alignment with 4k sector disks.

> Bug 979805 also reports a bootloader install failure due to an insufficient
> post-MBR gap:
> Bug 979805 - insufficient post-MBR gap not detected before installation
> 
> In that case, the first partition began at sector 28 (Bug 979805, Comment 2).
> 
> For the record, the grub2 documentation says:
> "You must ensure that the first partition starts at least 31 KiB (63
> sectors) from the start of the disk; on modern disks, ..."
> http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation

Understood.  But from a distribution perspective this means we're failing to install a boot loader... when grub2 *CAN* succeed with blocklists.  blocklists have a certain usability loss, as you're vulnerable to the core image moving on the /boot filesystem, but this is outweighed by the usability loss of not installing a boot loader at all.

Thanks, Stephen.

ISTM, the problem here isn't about blocklists. The problem here is that the assumptions about OEM disk partitioning appear to be invalid.

It would be very helpful if you could call Dell and ask them why they are using non-standard disk partitioning on their products.

Please note that this bug also reports non-standard partitioning on an OEM disk:
Bug 979805 - insufficient post-MBR gap not detected before installation

Chris, I'm CCing you, because this bug is very similar to:
Bug 979805 - insufficient post-MBR gap not detected before installation

In both cases, an OEM disk has been partitioned with fewer than 63 sectors before the first partition.

(In reply to Stephen Tweedie from comment #3)
...
> I have no idea; but 36 is at least better than 63 for sector alignment with
> 4k sector disks.
...

When you put 36 next to 63, it becomes apparent that they are anagrams.
Maybe 36 is a typo ...

(In reply to Steve Tyler from comment #6)
> (In reply to Stephen Tweedie from comment #3)
> ...
> > I have no idea; but 36 is at least better than 63 for sector alignment with
> > 4k sector disks.
> ...
> 
> When you put 36 next to 63, it becomes apparent that they are anagrams.
> Maybe 36 is a typo ...

And if so, Dell sold you a defective product, and they need to fix it.

36 is a not-unreasonable default for alignment reasons.  And the cause is irrelevant, there's no standard I'm aware of mandating that we have to have part1 starting at >=sect63, and grub2 is *already* capable of handling this case, we're just not enabling that support in anaconda.

We can argue all day about the right way to partition a disk in theory, but in reality we need to be as compatible as possible with the way things are in the real world, or we're just doing our users a dis-service.  "Complain to your OEM" is not a particularly user-friendly response when anaconda leaves behind an unbootable system.

(In reply to Stephen Tweedie from comment #3)
> (In reply to Steve Tyler from comment #2)
> > Thanks for your report.
> > 
> > "... a new PC (Dell) with Windows 7 preinstalled ..."
> > Do you know how Dell came up with sector 36?
> 
> I have no idea; but 36 is at least better than 63 for sector alignment with
> 4k sector disks.
...

Chris reports that a Windows 7 Ultimate install allocates 2048 sectors:
Bug 979805, Comment 7.

That is how your disk should have been partitioned.

The standard here is what the Windows installer does, not what Dell's inept manufacturing process produces.

Have you called Dell tech support yet about the defective product they sold you?

Dell Technical Support
http://support.dell.com/support/index.aspx

This new Windows 7 notebook has sda1 starting at sector 2048.

NB: sda5 was shrunk to makes space for Fedora partitions.

$ sudo parted /dev/sda u s p free
Model: ATA TOSHIBA MQ01ABD0 (scsi)
Disk /dev/sda: 625142448s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start       End         Size        Type      File system     Flags
        63s         2047s       1985s                 Free Space
 1      2048s       52430847s   52428800s   primary   fat32           hidden, lba
 2      52430848s   52635647s   204800s     primary   ntfs            boot, diag
 3      52635648s   302692351s  250056704s  primary   ntfs
 4      302692352s  625141759s  322449408s  extended
 5      302694400s  384614399s  81920000s   logical   ntfs
 6      384616448s  385665023s  1048576s    logical   ext4
 7      385667072s  590467071s  204800000s  logical                   lvm
        590467072s  590469074s  2003s                 Free Space
 8      590469120s  623042559s  32573440s   logical   ext4
 9      623044608s  625141759s  2097152s    logical   linux-swap(v1)
        625141760s  625142447s  688s                  Free Space

$ dmesg | grep -i asustek
[    0.000000] DMI: ASUSTeK Computer Inc. K54C/K54C, BIOS K54C.208 06/20/2012

(In reply to Stephen Tweedie from comment #0)
...
> # fdisk -l
> 
> Disk /dev/sdb: 999.7 GB, 999653638144 bytes, 1952448512 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk label type: dos
> Disk identifier: 0x5fcdd6d2
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1              36       65987       32976   de  Dell Utility
> /dev/sdb2           67584    25753599    12843008    7  HPFS/NTFS/exFAT
> /dev/sdb3        25753600  1030846463   502546432    7  HPFS/NTFS/exFAT
> /dev/sdb4      1030846464  1952448511   460801024    5  Extended
> /dev/sdb5   *  1030848512  1031897087      524288   83  Linux
> /dev/sdb6      1031899136  1032947711      524288   83  Linux
> /dev/sdb7      1032949760  1242664959   104857600   fd  Linux raid autodetect
> /dev/sdb8      1242667008  1952448511   354890752   8e  Linux LVM
...

Your NTFS partitions are aligned to 1 MiB boundaries:

sdb2:
>>> 67584.0*512/1024**2
33.0

sdb3:
>>> 25753600.0*512/1024**2
12575.0

Arithmetic by Python.

(In reply to Steve Tyler from comment #4)
> ISTM, the problem here isn't about blocklists. The problem here is that the
> assumptions about OEM disk partitioning appear to be invalid.

I agree. 36 is an ill advised starting LBA. On a blank disk, the Windows installer starts at LBA 2048. That's compatible with 512e alignment, and is also reasonable for SSDs.

However, that it's Dell doing this, might mean millions of computers are affected. It would be useful to determine the scope of this behavior.

While extlinux could support this configuration and chainload the Windows bootloader, anaconda itself doesn't create Windows boot entries, even for GRUB - that's left up to grub2-mkconfig. So detection and script generation code would be needed for extlinux to support this scenario in the installer.

(In reply to Steve Tyler from comment #6)
> When you put 36 next to 63, it becomes apparent that they are anagrams.
> Maybe 36 is a typo ...

It's odd they'd go with 36, instead of 64 or 2048 like Microsoft. It's probably a minor consequence for an SSD to not be aligned on anything close to its erase block size, but given the option I wouldn't use LBA 36 as a start. It's widely held convention to align on 1MB boundaries.

(In reply to Stephen Tweedie from comment #8)
> grub2 is *already* capable of handling this
> case, we're just not enabling that support in anaconda.

It's unreasonable to expect the anaconda team to use a feature grub maintainers say is not recommended.

> We can argue all day about the right way to partition a disk in theory, but
> in reality we need to be as compatible as possible with the way things are
> in the real world, or we're just doing our users a dis-service.

I think the scope of the behavior is relevant. Only a lot of work, or a simple inquiry to Dell can answer this. I wouldn't just ask them if LBA 36 is intentional, and not a bug, but also how widespread this is on their hardware.


>  "Complain
> to your OEM" is not a particularly user-friendly response when anaconda
> leaves behind an unbootable system.

Yes, but conversely it's not developer friendly to expect anaconda devs to do things they aren't comfortable with; and to expect grub devs to do things they aren't comfortable with. I think this comes down to grub and ext devs agreeing on a better way to support embedding - and this is being worked on but I don't know if/when we'll see results.

(In reply to Chris Murphy from comment #13)
> >  "Complain
> > to your OEM" is not a particularly user-friendly response when anaconda
> > leaves behind an unbootable system.
> 
> Yes, but conversely it's not developer friendly to expect anaconda devs to
> do things they aren't comfortable with; and to expect grub devs to do things
> they aren't comfortable with. I think this comes down to grub and ext devs
> agreeing on a better way to support embedding - and this is being worked on
> but I don't know if/when we'll see results.

The only thing I've asked for is consideration of a completely legal but uncommon preloaded scenario.  If actually booting on legal configurations makes developers uncomfortable then I think we have a deeper problem here.

(In reply to Stephen Tweedie from comment #14 
> The only thing I've asked for is consideration of a completely legal but
> uncommon preloaded scenario.

I don't know what you mean by legal. It's uncertain it's intentional and not a bug. And without knowing scope it's uncertain that it's uncommon.

>If actually booting on legal configurations
> makes developers uncomfortable then I think we have a deeper problem here.

I don't think they'd universally agree it is completely "legal", as GRUB legacy and 2 have always required a sufficiently large MBR gap. GRUB2 needs more space, also not news, as it's one of the reasons fdisk and parted moved to a 1MB gap where the 1st partition starts at LBA 2048. In your case the space is insufficient. If it were insufficient for GRUB legacy, you'd have the same problem, not a new one.

I am guessing that what Stephen means by "legal" is "any partitioning scheme that is compatible with Windows".

IOW, if Windows boots, it's legal ... :-)

Stephen: Have you contacted Dell yet about the "legal" partitioning scheme they sold you?

(In reply to Steve Tyler from comment #16)
...
> IOW, if Windows boots, it's legal ... :-)
...

In Bug 969709, Comment 18, Rostislav reports that he pre-partitioned a disk with exactly 1 sector before the first partition and that he successfully installed Windows XP with that partitioning.

That suggests that Windows can be installed without any post-MBR gap.

Chris, are you up to another Lets-See-What-Windows-Does experiment? :-)

(In reply to Chris Murphy from comment #15)
> (In reply to Stephen Tweedie from comment #14 
> > The only thing I've asked for is consideration of a completely legal but
> > uncommon preloaded scenario.
> 
> I don't know what you mean by legal. It's uncertain it's intentional and not
> a bug. And without knowing scope it's uncertain that it's uncommon.
> 
> >If actually booting on legal configurations
> > makes developers uncomfortable then I think we have a deeper problem here.
> 
> I don't think they'd universally agree it is completely "legal", as GRUB
> legacy and 2 have always required a sufficiently large MBR gap. 

No, they have not.

I've already said that grub2 works perfectly well in this configuration if manually installed with --force.  The support is there --- it just isn't enabled by default.

And pre-grub2 grub will automatically boot straight to stage2 via blocklist if there isn't space for stage1.5 in an embedded area.  I've just installed f12 into a VM with an unaligned /boot partition starting at sector 1, and it went without a hitch (and yes it boots fine.)

An MBR embedded area has always been something grub *can* use, not something it requires.

(In reply to Steve Tyler from comment #17)
> That suggests that Windows can be installed without any post-MBR gap. 
> Chris, are you up to another Lets-See-What-Windows-Does experiment? :-)

I can confirm that the Windows Vista and 7 installers don't have a dependency on an MBR gap existing or of a particular size. What experiment do you have in mind?

(In reply to Stephen Tweedie from comment #18)
>The support is there --- it just isn't enabled by default.

Existence of a feature with a warning disclosing it's not recommended is hardly "support" – it's therefore reasonable for the anaconda team to not want to touch the feature with a 10 foot pole. The use of --force was removed in anaconda 18 for Fedora 18, so it's not a new loss.

> An MBR embedded area has always been something grub *can* use, not something
> it requires.

Look you can criticize the GRUB2 design til the cows come home, it doesn't belong in this bug, and won't progress it. Your case is with GRUB maintainers, not anaconda. In effect GRUB2 requires an MBR gap, a GPT BIOS Boot partition, or a filesystem with a sufficient large bootloader area to avoid the use of --force. ext's bootloader pad is too small. Btrfs's is 64KB and is supported by GRUB2. XFS has none and therefore GRUB won't install to an XFS partition even with --force.

If you want to install a bootloader to an ext volume instead of the MBR gap, you can use the F19 netinst image, and pass extlinux on the kernel command line, and anaconda 19 will use extlinux instead of grub; extlinux by design only installs to a partition (to an ext volume specifically).

I think the only thing that might motivate a solution to the problem you're reporting is if it's a widespread problem, but thus far you haven't made that case.

(In reply to Chris Murphy from comment #19)
> (In reply to Steve Tyler from comment #17)
> > That suggests that Windows can be installed without any post-MBR gap. 
> > Chris, are you up to another Lets-See-What-Windows-Does experiment? :-)
> 
> I can confirm that the Windows Vista and 7 installers don't have a
> dependency on an MBR gap existing or of a particular size. What experiment
> do you have in mind?
...

OK. Is this correct then: The Windows installers will allow creation of a partition beginning at LBA 1 and Windows can be installed to that partition?

(In reply to Steve Tyler from comment #20)
> OK. Is this correct then: The Windows installers will allow creation of a
> partition beginning at LBA 1 and Windows can be installed to that partition?

No. The installer has no option to specify start-end sectors values (LBAs), only partition size. If the installer creates the first partition, it starts at LBA 2048. If something else creates the first partition at LBA 1, the installer will use it if the type is 0x07 and it's of sufficient size.

Thanks, Chris. I believe we have enough information to justify changing the bug component to grub2:

1. Windows can be installed to partitions beginning anywhere from LBA 1 and up.
2. OEMs are shipping Windows computers with partitions beginning at LBA < 63.
3. grub2 cannot install to such computers.
4. Blocklists are deprecated by grub2 developers.

Putting these all together, grub2 is incompatible with known, shipping OEM products, and there is no supported grub2 workaround.

Since Fedora must be compatible with Windows systems, Fedora must change its boot loader technology, by either replacing grub2, or by supporting changes to grub2 that will permit it to function reliably with Windows systems.

Stephen: I changed my mind, but:
1. Blocklists are deprecated by grub2 developers.
2. You still haven't called Dell.

This grub-devel thread discusses block lists:
Subject: GRUB and the risk of block list corruption in extX
http://thread.gmane.org/gmane.comp.boot-loaders.grub.devel/19687

I've added code to anaconda-20.6 that should issue a warning in the case of a too-small MBR gap when /boot is on a normal partition.

Anaconda is not going to use block lists given grub2's stance on them.

I think this is grub2's issue, if anyone's.

Thanks, David. This is still assigned to you. Is that what you intend?

For the record:
Check MBR gap size even when /boot is on a plain partition. (#986431)
https://git.fedorahosted.org/cgit/anaconda.git/commit/?id=637fdb48dc3d9139970704c0d528ce70a95c003e

Bug 969709 reports an install failure when there is no post-MBR gap. Of particular note is that Windows XP could be installed in that case:
Bug 969709, Comment 18.

Bug 969709 - GRUB2 bootloader installation and the whole Fedora 19 installation fails if there is no MBR gap

(In reply to David Lehman from comment #24)
> I've added code to anaconda-20.6 that should issue a warning in the case of
> a too-small MBR gap when /boot is on a normal partition.
> 
> Anaconda is not going to use block lists given grub2's stance on them.

That is also a decision to not support machines with insufficient MBR gab.

The grub2 "solution" is to have the --force option for those who are willing to take the risk. If Fedora wants so support grub2 on machines with insufficient MBR gab now, then anaconda has to expose that option to the user.

Long term the problem is solved by everybody switching to GPT and EFI.

The installer could also suggest resizing the first partition ...

(In reply to Steve Tyler from comment #29)
> The installer could also suggest resizing the first partition ...

No, that is for several reasons not an option.

(In reply to Mads Kiilerich from comment #30)
> (In reply to Steve Tyler from comment #29)
> > The installer could also suggest resizing the first partition ...
> 
> No, that is for several reasons not an option.

<g> What are those reasons?
NB: I said "suggest" ... as in "suggest a workaround".

(In reply to Steve Tyler from comment #31)
> (In reply to Mads Kiilerich from comment #30)
> > (In reply to Steve Tyler from comment #29)
> > > The installer could also suggest resizing the first partition ...
> > 
> > No, that is for several reasons not an option.
> 
> <g> What are those reasons?

Because resize moves the end of the partition, not the start.  It's the start that's the issue here.

(In reply to Stephen Tweedie from comment #32)
...
> Because resize moves the end of the partition, not the start.  It's the
> start that's the issue here.

So move the start ... what's your point?
Have you called Dell yet about the non-standard partitioning on your computer?

*** Bug 979805 has been marked as a duplicate of this bug. ***

*** Bug 969684 has been marked as a duplicate of this bug. ***

*** Bug 924902 has been marked as a duplicate of this bug. ***

Al intentar instalar fedora 19 en el disco duro. Se pega donde dice Instalando gestor de arranque. Aclaro que tengo instalados Windows Xp y Ubuntu.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
other involved packages: python-libs-2.7.5-1.fc19.x86_64
package:        anaconda-19.30.13-1.fc19.x86_64
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Fedora release 19 (Schrödinger’s Cat)
version:        19

Installing Fedora 19 onto a SSD disk. Clear disk befoe installation with a 'mktable gpt' using parted

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 ks=nfs:10.1.1.1:/tmp/ks.cfg BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Cannot get release name.
version:        19

(In reply to Peter Jennings from comment #38)
Since you used parted to force the disk to be GPT, I'm betting this is BIOS not UEFI hardware; and somehow anaconda fails to create or flag the user to create the required BIOSBoot partition. That would be a different bug that this bug, and needs a new bug filed with anaconda.log, program.log, and storage.log attached (they are found in tmp in the booted install environment).

I would use wipefs -a on the whole disk device to remove the current partition table before you begin again. Then use the hidden correct way to do this, which is to boot from install media, hit tab to edit the kernel parameter line, and add gpt to the end. That will cause the installer to create a gpt disk instead of mbr, on BIOS computers.

(In reply to Peter Jennings from comment #38)
> Installing Fedora 19 onto a SSD disk. Clear disk befoe installation with a
> 'mktable gpt' using parted
> 
> cmdline:        /usr/bin/python  /sbin/anaconda
> cmdline_file:   initrd=initrd.img
> inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 ks=nfs:10.1.1.1:/tmp/ks.cfg
> BOOT_IMAGE=vmlinuz 
> hashmarkername: anaconda
> kernel:         3.9.5-301.fc19.x86_64
> package:        anaconda-19.30.13-1
> product:        Fedora
> reason:         BootLoaderError: bootloader install failed
> release:        Cannot get release name.
> version:        19

Please include the logs from /tmp/*log as individual text/plain attachments so we can see what's going on. Also please include the output from:

parted -s /dev/blah u s p

I am unable to reproduce this issue and I didn't save the /tmp/*log files.
In case the hardware information is still useful:
Dell Optiplex 390 series from Oct 2012, BIOS Version A09
UEFI hardware
Mushkin 40 GB SSD - ID=MKNSSDCL040GB-DX

(In reply to Peter Jennings from comment #41)
> UEFI hardware

So in that case, why use parted to set the disklabel to GPT? Anaconda will do that for you if this is a new install on a blank disk, UNLESS the firmware is set to (legacy/compatibility) BIOS mode, sometimes also called UEFI disabled. Was it?

I've got this when installing a new system.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Cannot get release name.
version:        19

As far as I know syslinux officially supports installation into the Linux partition. Then why not just add the syslinux support into Anaconda? Anaconda could:

1. offer two bootloader options to a user: grub2 and syslinux
2. use grub2 by default and switch to syslinux automatically when there is not enough MBR gap space
3. use only syslinux

I heard there is a hidden syslinux support in Anaconda. But it's so hidden that it just doesn't exist for a regular user. Just think about user experience.

(In reply to Rostislav Krasny from comment #44)
http://fedoraproject.org/wiki/Features/SyslinuxOption

Boot with extlinux on the command line. For F19 it needs to be done with Network Install ISO.

(In reply to Chris Murphy from comment #45)
> (In reply to Rostislav Krasny from comment #44)
> http://fedoraproject.org/wiki/Features/SyslinuxOption
> 
> Boot with extlinux on the command line. For F19 it needs to be done with Network Install ISO.

What does it mean and how to do that? Are you talking about the installation ISO boot option? And then what? Will Anaconda use extinux instead of grub2? The article, you pointed me on, is also cryptic and doesn't explain things clear.

Anyway in the previous message I told about Anaconda. Why syslinux (extlinux) support can't be added into Anaconda - the standard graphical Fedora installer? Or it will be added there in Fedora 20?

(In reply to Chris Murphy from comment #19)
> 
> If you want to install a bootloader to an ext volume instead of the MBR gap,
> you can use the F19 netinst image, and pass extlinux on the kernel command
> line, and anaconda 19 will use extlinux instead of grub; extlinux by design
> only installs to a partition (to an ext volume specifically).

Ok, now it's clear that you meant a kernel parameter. It's really hidden in a very deep and dark place. Could you explain why the extlinux option is hidden and not supported by Anaconda straight away?

(In reply to Rostislav Krasny from comment #47)
No. But I suspect it's a matter of resources to design, code and maintain such functionality.

I don't know that anaconda produces the configuration file for extlinux, or if the user needs to do so manually. If manual, such a behavior shouldn't be exposed in the UI by default, because it'd make it too easy for regular users to create unbootable systems which likely violates one or more release criteria.

The maintenance aspect is really important. Every release there are boot related issues that come up, so having a whole separate bootloader method means it has to be tested and bugs fixed. So someone needs to volunteer for this additional work.

> (In reply to Rostislav Krasny from comment #47)
> No. But I suspect it's a matter of resources to design, code and maintain
> such functionality.

anaconda/pyanaconda/bootloader.py already has extlinux support, added by Matthew Miller <mattdm (a) redhat (d) com>. And according to `git log` there were other commits after that. For example Anaconda uses extlinux by default on ARM platform (commit 39dfa711759b3c53ceff7457cd1518adb51a268b) from August 20 this year. Most likely it's enabled on ARM by that secret kernel parameter, because anaconda/pyanaconda/flags.py has self.extlinux = False by default. It could be changed to True by an "extlinux" cmd parameter.

> I don't know that anaconda produces the configuration file for extlinux, or
> if the user needs to do so manually.

According to the code it does produce the /boot/extlinux/extlinux.conf configuration file.

> If manual, such a behavior shouldn't be
> exposed in the UI by default, because it'd make it too easy for regular
> users to create unbootable systems which likely violates one or more release
> criteria.

Currently grub2 seems to violate such a criteria by its design.

> The maintenance aspect is really important. Every release there are boot
> related issues that come up, so having a whole separate bootloader method
> means it has to be tested and bugs fixed. So someone needs to volunteer for
> this additional work.

There already are people, who volunteered for this work or do it for money in RedHat. And you always have a crowd of testers who try all new Fedora alphas, betas, RCs and releases. For example I opened bug 969709 (same to this one) when Fedora 19 was in beta stage.

So my question is still not answered. Why the extlinux option is hidden and not supported by Anaconda straight away? Maybe somebody from RedHat can explain it? Or maybe this support isn't completely ready yet but planned for the next release?

Interesting code chunk from the bootloader.py

# every platform that wants a bootloader needs to be in this dict
bootloader_by_platform = {platform.X86: GRUB2,
                          platform.EFI: EFIGRUB,
                          platform.MacEFI: MacEFIGRUB,
                          platform.PPC: GRUB2,
                          platform.IPSeriesPPC: IPSeriesGRUB2,
                          platform.NewWorldPPC: MacYaboot,
                          platform.S390: ZIPL,
                          platform.ARM: EXTLINUX,
                          platform.omapARM: EXTLINUX}

This is the place of switching from grub2 to extlinux.

I just tried to reinstall Fedora 19 from the netinst ISO with that secret extlinux kernel parameter. I also chose in the Anaconda to install the latest updates. So if there was any syslinux/extlinux update it was installed. The installation process has finished without any error. syslinux and extlinux were installed and also /boot/extlinux directory with many files (including extlinux.conf) was created. These are the good news.

The bad news are that the MBR code was not updated, so it remained with the old grub2 MBR code, from my previous Fedora 19 installation (where I installed grub2 on ext4 partition using --force). The grub2 MBR code doesn't work in this case and only starts the grub2 rescue prompt.

Updating MBR code would be easy, I thought mistakenly, and booted from the Fedora ISO again into a rescue mode shell. While in the rescue shell I didn't find any way to update just the MBR code. I probably searched not too much, because I remember from my short Arch Linux experiense that it's possible to install syslinux and also update the MBR code. Now I see that they do it by following command:

dd bs=440 count=1 conv=notrunc if=/usr/lib/syslinux/bios/mbr.bin of=/dev/sda

In Fedora this command need to be changed to:

dd bs=440 count=1 conv=notrunc if=/usr/share/syslinux/bios/mbr.bin of=/dev/sda

But since I didn't find this in time I've just mooved a boot flag (by fdisk) from /dev/sda2 (Fedora) into /dev/sda1 (Windows), booted from WinXP install CD and ran fixmbr from its rescue shell. It made my computer bootable into Windows. Then I booted again from the Fedora netinst ISO into its rescue shell and moved the boot flag back from /dev/sda1 into /dev/sda2. From now on my computer boots Fedora 19 with a small Fedora emblem splash. And the boot process starts from the Windows standard version of the MBR code.

Now why I wrote this long saga? Just to show following things:

1. extlinux itself (in the ext4 primary partition) works properly
2. Anaconda makes extlinux configuration that works (at least for booting Fedora itself)
3. MBR is not updated during Fedora installation with the extlinux kernel parameter
4. There already is an mbr.bin file, dd and fdisk programs that can be used to install the syslinux MBR code and set partition boot flag to the right primary partition
5. grub2 MBR code is a joke. It has a not standard behavior and can't co-exist with anything but grub2.
6. extlinux can co-exist with any MBR code that knows to load a boot sector primary partition:
  a) syslinux MBR code
  b) Windows MBR code
  c) FreeBSD boot0 MBR code

By the way, FreeBSD boot0 MBR code would be the best choice for dual-boot machines. Because it will continue to be able to boot one OS while the other OS is deleted. For example if I deleted my current Fedora then its extlinux will not work and MBR code will not ask me to boot from other primary partition. Only boot0 will. Alt Linux even has the boot0 RPM.

(In reply to Rostislav Krasny from comment #51) 
> The bad news are that the MBR code was not updated,

I suggest filing a new bug against component anaconda, and assign it to mattdm, and add me to the cc.

(In reply to Chris Murphy from comment #52)
Nevermind, I've reproduced this with Fedora 20 beta live desktop and I've filed a bug. Obviously it can't be fixed for F19 anyway. Bug 1015931.

After lots of trials and tribulations (see today's entry for bug 971179), I finally got through the package installation process to the "Installing bootloader". An error I've seen and reported before.

boot on RAID partition spanning added drive and original win8 drive.  root, home and var on LVM on RAID partition.  New drive is GPT, win8 was booting UEFI, UEFI is disabled, or at least, not required.  Fedora was to boot without UEFI.


cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Cannot get release name.
version:        19

(In reply to Emmett Culley from comment #54)
The but you cite doesn't seem related and there is no entry in it for today.

Please post the installer logs: /tmp if booted from install media, /var/log/anaconda otherwise.

Windows 8 requires UEFI to boot from GPT disks. And mixing and matching UEFI and CSM-BIOS OS's installs on the same hardware is fraught with problems that likely defy a rational support option.

Live install on new Panasonic FZ-G1 tablet with hd4000 graphics in vesa mode on extended paritition having win8 gpt ssd.  All seemed normal util unknown error but I see it stopped at bootloader installation.  I did created the requested bios boot partition along with home, root and swap.  I have the bios set to where I have installed several distros successfully.  My problem has been video though and only the latest Opensuse and Ubuntu have had the driver needed to install without special methods.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 --xdriver=vesa
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-19-1 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 xdriver=vesa nomodeset BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
other involved packages: python-libs-2.7.5-1.fc19.x86_64
package:        anaconda-19.30.13-1.fc19.x86_64
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Fedora release 19 (Schrödinger’s Cat)
version:        19

(In reply to Don Church from comment #56)
> Live install on new Panasonic FZ-G1 tablet with hd4000 graphics in vesa mode
> on extended paritition having win8 gpt ssd...[snip] ... I did created the
> requested bios boot partition along with home, root and swap.

Since this is Windows and a GPT disk that means the hardware is UEFI, thus there is an EFI System partition. The Fedora installer requesting BIOS boot partition, means the Fedora live desktop media is booted with a CSM to emulate BIOS. This bug relates to MBR disks, so there must be some anaconda/libreport confusion sending you to this bug.

Could you file a new bug report against component anaconda and cite the new bug number in this bug? And include in the new report as separate plaintext attachments the anaconda-tb*, program.log, and storage.log from /tmp from the live system? Thanks.

Created new bug reporting: 1026085

Lacking the requested attachments :(

Bootloader failure on FC 19 32 bit. Works on FC 18. Have Windows Vista on sda1

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20i386 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.i686
package:        anaconda-19.30.13-1
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Cannot get release name.
version:        19

The logging system identified the defect to be a duplicate and filed it under this bug. But this don't look right, my partitions seem ok.

/dev/sda1	   1	     13	    102400		   7	   System Reserved HPFS/NTFS
/dev/sda2	   13	    13068	 1048865262	7	   HPFS/NTFS
/dev/sda3	   13069	 60801	 383415322	 5	   HPFS/NTFS
/dev/sda5	   13069	 26136	 104968678	 7	   Extended
/dev/sda6	   26137	 59756	 270052618	 83	  Linux
/dev/sda7	   59757	 60801	 8393931	   82	  Linux Swap

I reformated my sda6 partition of FC12, inorder to install FC19, when the failure took place

File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1550, in install raise BootLoaderError("bootloader install failed")
BootLoaderError: bootloader install failed

Should I use

#grub2-install --force /dev/sda1 (This contains the Vista Boot loader)

OR

#grub2-install --force /dev/sda6 (My Linux / partition)

I would not want to blow up from Windows data/boot loader.

The 2nd option, sda6. However, I'd like to know the output from:

parted -s /dev/sda u s p

parted -s /dev/sda u s p
Model: ATA ST3500418AS (scsi)
Disk /dev/sda: 976773168s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start       End         Size        Type      File system     Flags
 1      2048s       206847s     204800s     primary   ntfs
 2      206896s     209937419s  209730524s  primary   ntfs
 3      209937420s  976768064s  766830645s  extended
 5      209937483s  419874839s  209937357s  logical   ntfs
 6      419874903s  959980139s  540105237s  logical   ext4            boot
 7      959980203s  976768064s  16787862s   logical   linux-swap(v1)

I have moved back to FC18, (bootloader) installs fine; which means this could be a regression. Cannot use FC19 for further tests, sorry.

I've been trying to install fedora from a pen drive, but it wouldn't allow me to select the packages from the pen drive, so I selected the intallation from network. I left the computer installing fedora yesterday and today a window suggesting the bug report was opened.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=LIVE xdriver=vesa nomodeset quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Cannot get release name.
version:        19

Created attachment 915832 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

(In reply to lazeroptyx from comment #65)

'ID_PART_ENTRY_OFFSET': '32',

The first partition appears to start only 32 sectors from the beginning which isn't enough room for grub to be embedded in the MBR gap. The solution is to delete all partitions, or wipefs -a /dev/sdg in this case. The new partition sdg1 will start at offset 2048 which permits grub to be installed

i was installing fedora in my external hard disk & all thing was ok but after installing proccess while post-installation is accure this error shown:

grub2-bios-setup:will not proceed with  blocklists   

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:LABEL=PENDRIVE rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.i686
other involved packages: python-libs-2.7.5-1.fc19.i686
package:        anaconda-19.30.13-1.fc19.i686
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Fedora release 19 (Schrödinger’s Cat)
version:        19

Fedora installation fails to install GRUB on a disk with GPT partition table.
The installation starts normally but when "Installing bootloader" this error occurs.
It allows me to either file a bug report or quit.
NOTE: An error installing Grub should not be fatal, the remaining steps of the Fedora installation should still be performed!
In this case, I was going to install a separate Grub anyway (to chainload into Fedora or another OS).

Steps to reproduce:
1. Format hdd with GPT partition table.
2. Prepare partitions (see below).
3. Boot Fedora installer, manually select prepared partitions and set mountpoints.
4. Wait until it's trying to install Grub.

Partition setup:
sda1: (1 MB) BIOS
sda2: (500 MB) Primary Grub, installed separately, not mounted
sda3: (25 GB) OS partition (mountpoint: /)
sda4: (5 GB) swap
sda5: (20 GB) HOME partition (mountpoint: /home)

# parted /dev/sda unit B print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sda: 53687091200B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start         End           Size          File system     Name  Flags
 1      1048576B      2097151B      1048576B
 2      2097152B      526385151B    524288000B    ext2
 3      526385152B    27369930751B  26843545600B  ext4
 4      27369930752B  32738639871B  5368709120B   linux-swap(v1)
 5      32738639872B  53686042623B  20947402752B  ext4


cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=Fedora-Live-XFCE-x86_64-19-1 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
other involved packages: python-libs-2.7.5-1.fc19.x86_64
package:        anaconda-19.30.13-1.fc19.x86_64
product:        Fedora
reason:         BootLoaderError: bootloader install failed
release:        Fedora release 19 (Schrödinger’s Cat)
version:        19

(In reply to Philip from comment #68)
parted is saying there is no flag set for sda1, it needs bios_grub flag set for grub2-install to use it, hence the likely reason for failure, although I'm not sure why anaconda/blivet aren't either setting bios_grub or complaining rather than failing. Might need a separate bug report if this is reproducible with Fedora 20.

I just tried this with Fedora 21 (I installed a gpt partition table and prepared unformatted partitions, including the 1 MB BIOS boot partition, before starting the Fedora installation). Still the same error - the installer apparently didn't set the bios_grub flag and threw an error when installing grub. But there has been some improvement, because this error is not fatal anymore, it now has a "Continue" button, so the remaining steps of the installation are not skipped.

Then I tried the same thing again, but (when preparing the partitions) I set the bios_grub flag on that first 1 MB partition. The Fedora installer wants to reformat this partition, but the flag was not lost (I checked using parted during the installation). So it worked, the boot loader was installed properly and everything worked fine.

I think the Fedora installer should set the bios_grub flag on that first partition (especially since the user selects "reformat" as "BIOS boot"). Also, the error message could probably show the grub error rather than an unspecific error message.
If this is is not a known issue, I could also open a new bug report for this?

(In reply to Philip from comment #70)
You've commented in the wrong bug. This bug is related to MBR not GPT. Please open a new bug and attached the logs found in /tmp while still booted with the installer media. And cc me on the bug. I tested GPT and bios_boot creation at some point during prerelease testing and it worked, so I'm not sure why it wouldn't work for final release.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.