Automatic partitioning reset boot flag in DOS partition table?

How did you determine that the MBR was modified? What boot loader was in the
MBR previously? Did you install Warty or Hoary?

Actually, I'm not sure that the MBR has been modified, but I asked during the
installation to install grub on a floppy, but the HD still is modified.

Before installing Ubuntu, it was a clean Windows XP installation, without any
other OS or bootloader.
I partitioned the disk before installing Ubuntu, and there wasn't any problem
booting Windows XP with the partitioned drive, before the installation.
There also is no problem if I install grub on the hard drive, except that's not
what I want to do...

I installed Hoary Preview and Hoary Array 7, both had this problem, and I
believe it can easily be reproducted (install Windows XP, create partitions,
install Ubuntu Linux with grub on a floppy and finally notice that it doesn't work).

Actually, the bug seems to be ealier during the install, if rebooting before the
partitioning utility of the installer, Windows XP can still boot normally (I
think it was obvious...), if I reboot just after parted (I believe it's the
program used) has created the 2 partitions (/ and swap), Windows XP can't boot
anymore.

I can still access my files using a Windows XP-based boot CD, BartPE, so, the
data of the NTFS partition isn't modified, but something else on the disk is...

I am ready to test anything necessary to make it work, I tested the last daily
Hoary image (27/03) and the RC3 of debian-installer, and the bug is present on
both of them.

I changed severity to critical, since any Windows XP user who cancels
(voluntarily or not, for instance if there is an electricity problem) and has no
rescue-boot CD or knowledge to fix whatever is broken will loose his OS and data.

(In reply to comment #3)
> I changed severity to critical, since any Windows XP user who cancels
> (voluntarily or not, for instance if there is an electricity problem) and has no
> rescue-boot CD or knowledge to fix whatever is broken will loose his OS and data.

This is demonstrably not true; the problem does not affect all systems with
Windows XP installed (or even many of them).

If you have a system image which demonstrates the problem, it would be very
useful if you could send us:

- The first 64k of the image, including the partition table
- The emulated geometry being used in the virtual machine

How can I get these infos?

It should be noted that most of the users install GRUB on the MBR and don't
cancel (or have to cancel) during the installation.
And a lot of people don't report bugs...

(In reply to comment #5)
> How can I get these infos?

Boot an Ubuntu live CD in the virtual machine.

sudo dd if=/dev/hda of=/tmp/hda.track1 bs=64k count=1
sudo fdisk -l /dev/hda > /tmp/hda.fdisk

And send us /tmp/hda.track1 and /tmp/hda.fdisk

Something really strange: using the live-cd (Warty), I chose "Boot from first
harddisk partition", and it successuly booted Windows...

I'll upload the files ASAP.

Created an attachment (id=1878)
hda.track1 as asked - made from damn small linux live cd

sudo fdisk -l /dev/hda > /tmp/hda.fdisk
creates an empty file...

(In reply to comment #9)
> Created an attachment (id=1878) [edit]
> hda.track1 as asked - made from damn small linux live cd
>
> sudo fdisk -l /dev/hda > /tmp/hda.fdisk
> creates an empty file...

That's strange; what do you see when you run fdisk interactively?

sudo fdisk /dev/hda

(In reply to comment #10)
> (In reply to comment #9)
> > Created an attachment (id=1878) [edit] [edit]
> > hda.track1 as asked - made from damn small linux live cd
> >
> > sudo fdisk -l /dev/hda > /tmp/hda.fdisk
> > creates an empty file...
>
> That's strange; what do you see when you run fdisk interactively?
>
> sudo fdisk /dev/hda

"Unable to seek on /dev/hda"
I'll try to run this from Hoary live CD

Created an attachment (id=1879)
hda.fdisk as asked - made from Hoary daily live CD

Thanks. Can you collect the same information after the disk has been modified
by the Ubuntu installer, so that we can see the difference?

This was the version after the installer modified the harddrive.
I change the hda.fdisk from the french to the english version, it will be more
clear for everyone I guess. Then I upload the before installation files.

Created an attachment (id=1881)
hda.fdisk as asked - made from Hoary daily live CD - after HD changes by
installer - EN version

Created an attachment (id=1883)
hda.fdisk - before install modified the HD

Created an attachment (id=1884)
hda.track1 - before install modified the HD

It looks like the boot flag was removed from the NTFS partition; isn't the
Windows boot loader sensitive about that?

Can you try (after the installer's modifications) using the live CD to set the
bootable flag with fdisk, and see if Windows boots after that?

sudo fdisk /dev/hda
'a' command to set the bootable flag
select partition '1'
write changes with 'w'

fdisk says (after I chose 'w'):
"The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource
busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks."

After reboot, and trying a few times, the boot flag still is on /dev/hda2 (Linux).

--> BUT, using Qtparted (from System Rescue CD) and setting the 1st partition to
"active" (I believe it's the same thing as the boot flag), Windows XP boots
successfully :).

I'll test if the floppy can boot Ubuntu and Windows XP from the GRUB I install
on it (I have to re-install Ubuntu completly).

If you find a fix for this, could you send it to the Debian project as well, I
have the same bug with debian-installer RC3?

I made an install with GRUB installed on a floppy, then I set the boot flag on
the 1st partiton with Qtparted, and now everything works fine: if there is no
floppy, Windows XP boots normally, if there is the GRUB floppy, I have the GRUB
menu, from which I can boot both Ubuntu and Windows XP.

So the problem is about the boot flag, it 'just' has to be kept on the 1st
partition (Windows XP) to make it work.

I've never seen either the Debian or Ubuntu installer mess with the bootable
flag at all unless you explicitly asked it to while partitioning.

(In reply to comment #21)
> I've never seen either the Debian or Ubuntu installer mess with the bootable
> flag at all unless you explicitly asked it to while partitioning.

I used the automatic partitionning utility, I had created a free space on the HD
before, so I just chose "Use all free space" (or something like that, I used the
french version), and it did use it. I didn't choose the advanced partitioning...

Ah, right, it would; partman-auto's recipes set $bootable{ }, which would have
this effect.

The question now is whether there'd be any bad effects from disabling that. Does
LILO still work (in both MBR and partition) if the bootable flag isn't set?

As far as I know, no Linux native boot loader cares one whit about that flag

(In reply to comment #24)
> As far as I know, no Linux native boot loader cares one whit about that flag

And even if it does (which about I have no idea) can't the boot flag be set when
the user chooses to install the bootloader on the harddrive, not at the beginning?

And I'm always ready to test whatever you want, if you explain to me how to do
it :).

Will this bug be fixed in the final Hoary release?

One complication here is that, according to the LILO manual, some BIOSes don't
properly recognise disks with no active partition; so grub-installer and
lilo-installer would have to make sure that at least one partition is marked active.

(In reply to comment #28)
> One complication here is that, according to the LILO manual, some BIOSes don't
> properly recognise disks with no active partition; so grub-installer and
> lilo-installer would have to make sure that at least one partition is marked
active.

Can't partman be modified to set the boot flag ONLY if there isn't one set before?

Theoretically, but there is no hope whatsoever of making that kind of change
before Hoary. I'm investigating a simpler option.

(In reply to comment #30)
> Theoretically, but there is no hope whatsoever of making that kind of change
> before Hoary. I'm investigating a simpler option.

OK, thanks for your work on this.

lilo-installer (1.05ubuntu5) hoary; urgency=low

  * Make sure that the boot disk always has an active partition (part of
    Ubuntu #7906).

 -- Colin Watson <email address hidden> Tue, 5 Apr 2005 17:04:53 +0100

partman-auto (40ubuntu3) hoary; urgency=low

  * Drop the bootable flag from i386/amd64 recipes; it can break existing
    Windows installations when autopartitioning only free space rather than
    a whole disk (closes: Ubuntu #7906).

 -- Colin Watson <email address hidden> Tue, 5 Apr 2005 17:53:31 +0100

(In reply to comment #32)
> lilo-installer (1.05ubuntu5) hoary; urgency=low
>
> * Make sure that the boot disk always has an active partition (part of
> Ubuntu #7906).
>
> -- Colin Watson <email address hidden> Tue, 5 Apr 2005 17:04:53 +0100
>
> partman-auto (40ubuntu3) hoary; urgency=low
>
> * Drop the bootable flag from i386/amd64 recipes; it can break existing
> Windows installations when autopartitioning only free space rather than
> a whole disk (closes: Ubuntu #7906).
>
> -- Colin Watson <email address hidden> Tue, 5 Apr 2005 17:53:31 +0100

Thanks :).

(In reply to comment #32)
> lilo-installer (1.05ubuntu5) hoary; urgency=low
>
> * Make sure that the boot disk always has an active partition (part of
> Ubuntu #7906).
>
> -- Colin Watson <email address hidden> Tue, 5 Apr 2005 17:04:53 +0100
>
> partman-auto (40ubuntu3) hoary; urgency=low
>
> * Drop the bootable flag from i386/amd64 recipes; it can break existing
> Windows installations when autopartitioning only free space rather than
> a whole disk (closes: Ubuntu #7906).
>
> -- Colin Watson <email address hidden> Tue, 5 Apr 2005 17:53:31 +0100

Just one last thing, I swear it will be the last, will this bugfix also be sent
to Debian, since I had this bug with Debian as well? (see #19)

I'm afraid that we had to revert this change, since leaving some systems without
an active partition broke, and grub apparently didn't fix the situation up for
us. Sorry.

This bug existed in Warty too, so given the choice between two bugs we're more
comfortable picking the one that isn't a regression. We'll fix it up in Breezy,
by making grub-installer ensure that there's an active partition.

(In reply to comment #35)
> I'm afraid that we had to revert this change, since leaving some systems without
> an active partition broke, and grub apparently didn't fix the situation up for
> us. Sorry.
>
> This bug existed in Warty too, so given the choice between two bugs we're more
> comfortable picking the one that isn't a regression. We'll fix it up in Breezy,
> by making grub-installer ensure that there's an active partition.

Just for info, it worked for me for the 20050406 daily hoary snapshot (GRUB on
floppy + Windows XP).

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

Looks like the thread has died on this 1 year old bug.
Milobach, is this still an issue? I guess it has been fixed ?

Please respond if this still is an issue.

This is still an issue. Please do not close it.

I installed from a Dapper liveCD a few days ago, and manually created my partitions using the install program's tool. However, when I rebooted, I got an error that is the equivalent of the old "non-system disk or disk error". Basically, none of my partitions were marked with the bootable flag, and therefore didn't boot. This surprised me, since I didn't think grub or lilo gave a damn about that flag. Rebooting with the live CD and marking my root partition as bootable fixed this problem.

Should the install tool not make sure that when all is finished, one of the partitions is marked as bootable, no matter how the partitions were created? That's more or less what this thread is about, right?

that's sill happening on feisty

grub-installer (1.24ubuntu2) gutsy; urgency=low

  * Mark the partition to which GRUB is being installed as bootable, or
    failing that the first available primary partition on the disk to which
    GRUB is being installed (LP: #14244).

 -- Colin Watson <email address hidden> Fri, 24 Aug 2007 12:05:09 +0100

Assigning to Colin, on his request.

This bug was fixed in the package partman-auto - 73ubuntu2

---------------
partman-auto (73ubuntu2) hardy; urgency=low

  * Drop the bootable flag from i386/amd64 recipes; it can break existing
    Windows installations when autopartitioning only free space rather than
    a whole disk (LP: #14244). This reinstates the change from 40ubuntu3 now
    that grub-installer ensures that there is one bootable partition.

 -- Colin Watson <email address hidden> Thu, 28 Feb 2008 14:59:36 +0000