/boot is on root partition by default

[Steve Hill]

Using the alternative CD, the /boot directory is, by default, placed on the root filesystem instead of on it's own partition. The result is that data needed by GRUB can end up past cylinder 1024 on the drive which some systems will be unable to access at boot time.

This is very bad - the installer claims to have compelted successfully, but the system is left in an unbootable state.

Worse - it's theoretically possible that by some fluke the data will all end up below cylinder 1024 and the system will work - then at some point an update will break it by installing a new kernel beyond cyl 1024.

Whilest it may not always be possible to place a separate /boot partition at the start of the drive (e.g. people dual-booting probably can't), there isn't really anything to be lost by doing it where possible. At the very least, the installer should check whether the BIOS can handle reading from the end of the drive and warn that the system will be unbootable before partitioning.

[Sitsofe Wheeler (sitsofe)]

Probably related to bug #34353 or bug #9006 ...

[Sitsofe Wheeler (sitsofe)]

(by the way, the fluke case might be being seen in bug #79578 )

[Brian Murray (brian-murray)]

Thanks for your suggestion. The changes you are requesting require more discussion, which should be done on an appropriate mailing list or forum. http://www.ubuntu.com/community/forums/ might be a good start.

[Sitsofe Wheeler (sitsofe)]

Brian,
Please reconsider this bug. At a minimum please dup it against one of the other bugs mentioned and publishing a warning in the release notes that Ubuntu can be troublesome to install on pre 2001 hardware. This is a real issue that keeps cropping up...

[towsonu2003 (towsonu2003)]

I think this is almost dupe of bug #9006 (except this one is on ubiquity). If you agree, I'll open this one there (I'd guess it's easier to track that way).

[towsonu2003 (towsonu2003)]

xubuntu is especially nice for older machines, so xubuntu people might wanna look at this?

[Steve Hill (steve-nexusuk)]

Yes - looks like a dupe of #9006.

It's worth noting that Fedora Core has always created a separate /boot by default and I've not heard any convincing arguments as to why this is a Bad Thing.

[Colin Watson (cjwatson)]

Rejecting bogus xubuntu-meta task. There's really nothing that Xubuntu gets to do specially here.

[Colin Watson (cjwatson)]

Automatic partitioning is more complicated than just about anyone thinks who hasn't looked into it, and adding partitions increases the complexity, particularly with the hopeless inadequacies of the PC partition table format, and especially if you install more than one version of Linux. In addition, creating a small /boot partition has the obvious problem that the size needs to be chosen extremely carefully lest you end up either running out of space there as you install more kernel versions (noting that we don't yet automatically remove older kernels, and they'll take up more space in /boot over time) or wasting space on small disks that people would rather use for the OS and data. Note that old machines of the sort that are susceptible to this problem are particularly likely to have disks small enough that carving them up into more pieces is liable to create a usability problem later.

Fedora are welcome to the decision they've made here, but I don't want to share the problems they must face as a result. I would rather do just about anything else, and for preference I would very much like to see grub fixed. Either it should just be cleverer about finding its metadata (after all, it's not entirely reliant on the BIOS) or grub-install could even be taught to fail when it detects this situation; if nothing else surely no more of these BIOSes are being made so even a blacklist would be a tolerable approach.

Does anyone know if grub2 fixes this problem for good?

[Steve Hill (steve-nexusuk)]

> Note that old machines of the sort that are susceptible to this
> problem are particularly likely to have disks small enough that
> carving them up into more pieces is liable to create a usability
> problem later.

It seems that in cases of older systems then you have to choose between two problems:
1. Splitting the disk space up may cause future problems due to a lack of total disk space.
2. Failing to split the disk space up will prevent the system from working at all.

It seems to me that (1) is the lesser of the two evils, and any system modern enough to not suffer from the cyl>1024 problem will also have a hard drive big enough to deal with losing ~100MB of space to a /boot partition.

I'm certainly happy to see a warning that explains what I have to do to fix the problem if an automatic solution is considered too complex. However, the current state of affairs is bad - I upgraded the machine from (fully working) Fedora Core to Ubuntu Edgy and it just plain didn't boot - no warnings that there might be problems or anything. Not a good user experience.

I'm a seasoned Linux developer, so it was pretty easy for me to spot the problem, but a normal user would just conclude that Ubuntu is "broken" since another distro has been shown to work on the same hardware flawlessly.

[PRMan (ubuntu-marlareid)]

Couldn't you just include an option in the installer that says,

Use full space with a 200MB /boot partition (use if you previously got a GRUB 18 error)

That way, the vast majority don't run into the problems listed above, but people like me who got an error and tried again would choose this option instead.

[Phillip Susi (psusi)]

I would suggest at least that a message be added if there is no /boot partition in the lower portion of the disk to inform the user that the system may not boot properly unless they add a /boot partition on the start of the disk. In the case where they choose the auto partition, then a 100 MB /boot partition should be created by default if the disk is over 2 gb.

As for fixing grub, this is impossible as this is a bios issue, not a grub one.

[Ryan Braley (soularis-dark)]

I had this problem with the alternate cd and it left my computer unbootable, but grub will work if you replace all instances of /boot/ with / in the grub boot entry

[Frank H. Ellenberger (f-ellenberger)]

Hi,

I run in this, as I tried to install 7.04.
If you remove all this annoying quiet and splash strings from the boot options, you can see messages, that the BIOS reports another disk sizes than the disks themself. This information should be used.
Then the installer at least should warn the user, that he is wasting his time, if he doesn't create a small boot partition at the beginning of the disk.
If you want do more, you can:
If the user decided, to use the entire disk for the installation, you can do some calculation for him.
If there are other partitions, the user wants to keep, you could give him some advice, depending of his real disk size and his selected istallation type (server/desktop) and then switch to manual partitioning.
AFAIK there are 3 different critical sizes for old BIOSes: 512MB, 8GB and 32GB, but it is possible to use a 200GB disk which the BIOS tells a capacity of 32GB.

Please remember, that a beginner, who runs in this problem, and doesn't get some hint, how to solve the problem, would think Ubuntu and/or Linux doesn't work on my machine and is lost for the community.

[Markus Birth (mbirth)]

My preferred way would be to let the update-initramfs check that all files are in the first 1024 cylinders of the disk. Maybe it could move out-of-boundary-files more to the beginning of the drive using some technique like e2defrag does.

[EdwinOlson (ebolson)]

I have a machine that was working well, but after a kernel update, failed at boot with grub error 24. At the time, I suspected file system corruption and installed to a new disk. Note that this system was Ubuntu 8.10 (x86/64) with a 1TB disk. I used autopart and there was no separate /boot partition.

Today, on a completely different machine (albeit with similar hardware), I've had the exact same symptoms again. I got a new kernel update and upon reboot, I cannot boot the new kernel (I get grub error 24), but I can boot old kernels. Fsck is happy with my drive, and this machine has a 1.5TB disk... again, no separate /boot partition. I'll add that I've inspected my grub menu.lst and there's nothing unusual here.

My best explanation of these two independent failures is that the kernel image has been written to some part of the disk that confuses grub, triggering grub to fail at boot. It appears to be a "time bomb" in the sense that the system works perfectly normally for an extended period of time (months in the case of my system today), until a kernel update "tickles" the problem. Note that these are modern machines (Intel Core2Duo), and so the problem does not appear to be limited to old machines or the ancient 32GB barrier.

I am happy to try to find some identifying characteristic of this machine that might explain which machines will have trouble. (i.e., a particular motherboard, bios setting?) Please let me know what information would be helpful to you.)

[Markus Birth (mbirth)]

We had these problems with VMware ESX and a JeOS/Ubuntu Server installation. Everything worked fine but after some kernel update, the new initramfs was written beyond the 1024th cylinder and grub failed (and this was inside a VM, so there's no BIOS update which could fix this; shame on you VMware!). After migrating all VMs to separate 100MB-/boot-partitions, everything works fine now.

[Phillip Susi (psusi)]

Setting this to won't fix since it has been decided not to change this and I'm tired of seeing it on my list of high priority bugs that need fixed.