Comment 3 for bug 190596

Hello Dennis,

I agree with your observations. Marking to Confirmed to move along to ubiquity developers. Linux does have a presumption of working hardware. A power glitch, a hard disk problem, or a CD reader problem will cause installation problems. As just about all computers come with an operating system installed, new users don't go through the pain of installing an OS. Ubiquity makes it easy and quick, but not always successful.

I think (2) is easy enough to do. Windows users are so used to rebooting that if the system boots back into window--the user will think "What happened? But at least my Windows stills works." The next boot they will pay attention to the GRUB menu.

Item (3) may be more difficult because until the new partition table is written and then read back, you don't know if there will be errors. The partition table edits remain in memory until committed to writing. Once written, any problems show up quickly. Rewriting the old table may or may not rescue data depending how the drive was structured. I think there should be extra checks before rewriting NTFS partitions--how about a dialog warning: "You are about to rewrite a Windows NTFS partition. If this contains Windows Operating System, then your system will no longer be able to boot into Windows--Continue or Cancel"

Item (4) is already the last step, but the GRUB installer gets confused with RAID drives, high partition counts, and non-Debian Linux installs (Reiser, ZFS, XFS, HFS partitions). Detection is getting better, but there are several edge cases where the user has to edit menu.lst to recover existing OS's.

I would like to see some Artificial Intelligence where GRUB contacts a server that has captured several thousand use cases (based on voluntary submission of working menu.lst files) so that GRUB can make more intelligent decisions on how to set up menu.lst based on the partitions detected.