+++ This bug was initially created as a clone of Bug #986431 +++

Description of problem:
I have a new PC (Dell) with Windows 7 preinstalled on legacy BIOS / MBR (not GPT), and the Dell Utility partition starts at sector 36.  Anaconda attempts to install grub2 on the correct disk, but grub2 fails because of the restricted space before partition 1.

grub2 *can* succeed, it just needs --force; manually invoking grub2 fails in exactly the same way, but I've installed just fine with --force and the system is booting perfectly now (including dual boot.)

Ideally, if we can install a working bootloader then we should do so rather than aborting at the end of install.  In this case grub2 has to fall back to using blocklists for stage2, but it can still work, even though it currently needs --force to actually do so.

If it matters, I was using the GA f19 x86_64 usb live image.

Additional info:

I've shrunk the windows partition and installed linux on partitions 4+, but partitions 1--3 are still otherwise as delivered from factory:

# 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

Relevant Anaconda logs:

19:45:45,982 INFO program: Running... grub2-install --no-floppy /dev/sdc
19:45:46,947 INFO program: /usr/sbin/grub2-bios-setup: warning: your embedding area is unusually small.  core.img won't fit in it..
19:45:46,947 INFO program: /usr/sbin/grub2-bios-setup: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
19:45:46,947 INFO program: /usr/sbin/grub2-bios-setup: error: will not proceed with blocklists.
19:45:46,947 DEBUG program: Return code: 1

Running grub2 manually with (from memory!)

grub2-install --no-floppy --boot-directory=/mnt/sysimg/boot /dev/sdc

failed with the same error (the /dev/sdb boot disk was /dev/sdc during anaconda install, /dev/sda was the additional usb disk at that time); but adding --force was enough to succeed.

I'll attach the full anaconda-tb- log.

NB I'll be on PTO for two weeks, if you need more info/debug I'll be able to answer after Aug.5.

--- Additional comment from Stephen Tweedie on 2013-07-19 15:14:40 EDT ---



--- Additional comment from Steve Tyler on 2013-07-20 14:20:38 EDT ---

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',
...

--- Additional comment from Stephen Tweedie on 2013-08-05 08:34:59 EDT ---

(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.

--- Additional comment from Steve Tyler on 2013-08-05 09:05:50 EDT ---

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

--- Additional comment from Steve Tyler on 2013-08-05 09:15:14 EDT ---

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.

--- Additional comment from Steve Tyler on 2013-08-05 09:28:03 EDT ---

(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 ...

--- Additional comment from Steve Tyler on 2013-08-05 09:30:53 EDT ---

(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.

--- Additional comment from Stephen Tweedie on 2013-08-05 09:54:14 EDT ---

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.

--- Additional comment from Steve Tyler on 2013-08-05 10:21:53 EDT ---

(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

--- Additional comment from Steve Tyler on 2013-08-05 11:19:39 EDT ---

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

--- Additional comment from Steve Tyler on 2013-08-05 11:44:03 EDT ---

(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.

--- Additional comment from Chris Murphy on 2013-08-05 12:42:16 EDT ---

(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.

--- Additional comment from Chris Murphy on 2013-08-05 13:14:19 EDT ---

(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.

--- Additional comment from Stephen Tweedie on 2013-08-12 08:03:26 EDT ---

(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.

--- Additional comment from Chris Murphy on 2013-08-12 10:51:26 EDT ---

(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.

--- Additional comment from Steve Tyler on 2013-08-13 07:10:53 EDT ---

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?

--- Additional comment from Steve Tyler on 2013-08-13 07:29:45 EDT ---

(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? :-)

--- Additional comment from Stephen Tweedie on 2013-08-13 10:42:03 EDT ---

(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.

--- Additional comment from Chris Murphy on 2013-08-13 12:01:57 EDT ---

(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.

--- Additional comment from Steve Tyler on 2013-08-13 12:16:55 EDT ---

(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?

--- Additional comment from Chris Murphy on 2013-08-13 12:47:49 EDT ---

(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.

--- Additional comment from Steve Tyler on 2013-08-13 15:08:22 EDT ---

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.

--- Additional comment from Steve Tyler on 2013-08-13 18:11:38 EDT ---

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

--- Additional comment from David Lehman on 2013-08-22 14:05:08 EDT ---

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.

--- Additional comment from Steve Tyler on 2013-08-22 14:58:12 EDT ---

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

--- Additional comment from Steve Tyler on 2013-08-22 15:12:19 EDT ---

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

--- Additional comment from Steve Tyler on 2013-08-22 15:44:41 EDT ---

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

--- Additional comment from Mads Kiilerich on 2013-08-31 10:21:38 EDT ---

(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.

--- Additional comment from Steve Tyler on 2013-08-31 10:30:36 EDT ---

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

--- Additional comment from Mads Kiilerich on 2013-08-31 11:40:29 EDT ---

(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.

--- Additional comment from Steve Tyler on 2013-08-31 12:07:08 EDT ---

(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".

--- Additional comment from Stephen Tweedie on 2013-09-02 04:50:05 EDT ---

(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.

--- Additional comment from Steve Tyler on 2013-09-02 07:19:50 EDT ---

(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?

--- Additional comment from David Shea on 2013-09-03 11:39:40 EDT ---



--- Additional comment from David Shea on 2013-09-03 11:44:43 EDT ---



--- Additional comment from David Shea on 2013-09-03 11:45:09 EDT ---