HDD not bootable if ubiquity fails

Bug #190596 reported by Dennis Heinson
6
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: ubiquity

If Ubiquity fails for some reason (for me, it was a corrupted/unreadable CD), it leaves my existing NTFS Windows partition unbootable (boot flag is not set).

It took me about 3 hours to figure this out and restore the partition.

Can you imagine how it feels - being left without bootable HD? :(

This is not an exact duplicate of the following bugs, but it might be related:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/115633
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/113370

So I am filing it again here.

Please, this is a REALLY serious bug.

Revision history for this message
TerryG (tgalati4) wrote :

Triaged to Incomplete. Thanks for your bug submission and research. Did the Live CD load successfully before you attempted to install? It's unfortunate that OS installation can result in data loss of existing partitions on the drive. The nature of repartitioning involves some risk that cannot be entirely eliminated. The entire installation chain needs to be perfect: Download an ISO image perfectly, burn a CD perfectly, Load the CD such that your CDROM reader can read the entire disk, then Load the LIVE CD to make sure that Ubuntu even works correctly on the hardware, then install. Any failures in this chain can cause fits. As you have discovered. Perhaps additional warnings can be added at various steps, but once partitioning takes place, it's possible for these problems to occur.

Changed in ubiquity:
status: New → Incomplete
Revision history for this message
Dennis Heinson (dheinson) wrote :

Yes, the LiveCD booted without an error message. The installer runs fine, too, but cannot copy data and exits at some point. In my opinion, the installer should during all times assume that something can go wrong or that it is being aborted. I bet you could reproduce my problem by switching off the computer while the Installer is copying files to the computer. This should never result in an ENTIRELY unbootable system. Here is my suggestion how the process could work:

1. Ask for all the partitioning and so on
2. If there is any partitioning to be done, do it, but put it in a state where the pre-existing system is booted by default.
3. Install Ubuntu on one of the partitions. ONLY if this does not produce any errors, continue:
4. Install GRUB at the very end, then in a final step make the Ubuntu partition the default.

What do you think?

Revision history for this message
TerryG (tgalati4) wrote :

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.

Revision history for this message
TerryG (tgalati4) wrote :

Triaged to Confirmed to preserve reporter's comments.

Changed in ubiquity:
status: Incomplete → Confirmed
Revision history for this message
Dennis Heinson (dheinson) wrote :

Yes, I agree. Number two should be fixable with just a few lines of code and get rid of the initial problem. I hope it gets implemented - this is really a nasty bug...

Revision history for this message
Phillip Susi (psusi) wrote :

Grub *is* installed at the last step, so I don't see anything to fix here. The boot flag also is not modified, ever. Can you provide better reproduction steps? Such as pull the plug right when the installer is at step X?

Changed in ubiquity (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

Changed in ubiquity (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.