Grub removes Windows boot option when NTFS partition needs recovery

(In reply to comment #0)
> Just guessing at the package, please reassign if necessary!
>
> After the latest Breezy upgrades, including a new kernel, I have found that my
> Windows partition and Thinkpad Rescue Partition, both previously automatically
> detected and inserted into the grub menu, have disappeared from my bootup
> options. Although this is essentially a Good Thing, it's clearly a bug. See URL
> for the hardware information.
>
> Matt

I can confirm the same behavior over here, on my Dell laptop and intel desktop
as well.

marking as confirmed, then

Does the kernel see the partitions and can you mount them yourself? Can you send
the output of /proc/partitions on hoary and breezy kernels.

I'm thinking this is a grub bug (or whatever does the partition checking).

(In reply to comment #3)
> Does the kernel see the partitions and can you mount them yourself? Can you send
> the output of /proc/partitions on hoary and breezy kernels.

I only have Breezy installed. Here is the output:

matt@kalliope:~$ cat /proc/partitions
major minor #blocks name

   8 0 39070080 sda
   8 1 14651248 sda1
   8 2 4142880 sda2
   8 3 19406520 sda3
   8 4 1 sda4
   8 5 859446 sda5
 253 0 14651248 dm-0
 253 1 4142880 dm-1
 253 2 19406520 dm-2
 253 3 859446 dm-3

Here is my partition table:

matt@kalliope:~$ sudo fdisk -l /dev/sda

Disk /dev/sda: 40.0 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot Start End Blocks Id System
/dev/sda1 1 1824 14651248+ 7 HPFS/NTFS
/dev/sda2 * 4348 4864 4142880 2 XENIX root
Partition 2 does not end on cylinder boundary.
/dev/sda3 1825 4240 19406520 83 Linux
/dev/sda4 4241 4347 859477+ 5 Extended
/dev/sda5 4241 4347 859446 82 Linux swap / Solaris

Partition table entries are not in disk order

and here is what I get when I try to mount /dev/sda1:

matt@kalliope:~$ sudo mount -t ntfs /dev/sda1 /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/sda1,

[4296730.205000] NTFS driver 2.1.22 [Flags: R/O MODULE].
[4296730.245000] NTFS-fs error (device sda1): read_ntfs_boot_sector(): Primary
boot sector is invalid.
[4296730.245000] NTFS-fs error (device sda1): read_ntfs_boot_sector(): Mount
option errors=recover not used. Aborting without trying to recover.
[4296730.245000] NTFS-fs error (device sda1): ntfs_fill_super(): Not an NTFS volume.
[4296745.723000] NTFS-fs error (device sda2): read_ntfs_boot_sector(): Primary
boot sector is invalid.
[4296745.723000] NTFS-fs error (device sda2): read_ntfs_boot_sector(): Mount
option errors=recover not used. Aborting without trying to recover.
[4296745.723000] NTFS-fs error (device sda2): ntfs_fill_super(): Not an NTFS volume.
[4296749.694000] NTFS-fs error (device sda1): read_ntfs_boot_sector(): Primary
boot sector is invalid.
[4296749.694000] NTFS-fs error (device sda1): read_ntfs_boot_sector(): Mount
option errors=recover not used. Aborting without trying to recover.
[4296749.694000] NTFS-fs error (device sda1): ntfs_fill_super(): Not an NTFS volume.
[4296809.817000] NTFS-fs error (device sda1): read_ntfs_boot_sector(): Primary
boot sector is invalid.
[4296809.817000] NTFS-fs error (device sda1): read_ntfs_boot_sector(): Mount
option errors=recover not used. Aborting without trying to recover.
[4296809.817000] NTFS-fs error (device sda1): ntfs_fill_super(): Not an NTFS volume.

Dunno if this helps, but it is certainly weird. Windows was working fine since
my massive dist-upgrade yesterday.

Yeah, it looks like it's just a matter of the ntfs module being broken.

so is there any way I can boot Windows? I'll do a system restore if there is no
change of this being fixed today.

Sure, add this in /boot/grub/menu.lst

title Microsoft Windows
root (hd0,0)
savedefault
makeactive
chainloader +1

Change hd0,0 to whatever is your actual windows partition. From the looks of
your partition table, it should be correct. You can probably just copy the entry
in /boot/grub/menu.lst~ if it's still there.

Can you try adding -o errors=recover with the mount command? If that works, then
try unmounting and remount without that option. I'm wondering if your NTFS
volume has errors, and it is just failing because the errors need to be
recovered (probably booting to Windows one time will resolve this too).

I think this bug is that the NTFS partition needs recovery. Which is not a bug
in itself, however grub should probably handle this a bit better. It should not
remove the boot option, which is probably the best way to handle the recovery.

(In reply to comment #7)
> Sure, add this in /boot/grub/menu.lst
>
> title Microsoft Windows
> root (hd0,0)
> savedefault
> makeactive
> chainloader +1
>
> Change hd0,0 to whatever is your actual windows partition. From the looks of
> your partition table, it should be correct. You can probably just copy the entry
> in /boot/grub/menu.lst~ if it's still there.

This doesn't work :( I get the error "File System Type Unknown" or something
similar after the root line, and nothing happens.

I can mount the drive as you suggest with the option errors=recover, but after I
unmount it and try and mount it without that option, it fails again.

Windows appears to be unbootable right now. I haven't worked in Windows since it
was working and the only thing I've done on the computer is a dist-upgrade on my
Breezy installation.

Matt

Help!?

Windows is still unbootable on my machine, and given that I'm not the only
person who has reported this bug I'm increasing the severity to major: it would
be terrible is this happens to others when Breezy is released.

Matt

Hello Matthew,

Can you try:

  title Windows chainloader directly
  chainloader (hd0,0)+1

or if that doesn't work:

  title Windows rootnoverify
  rootnoverify (hd0,0)
  chainloader +1

FWIW, "makeactive" shouldn't be needed by anything modern, and causes the
on-disk partition table to be changed.

(In reply to comment #12)
> Hello Matthew,

Hi Paul,

Neither work.

> Can you try:
>
> title Windows chainloader directly
> chainloader (hd0,0)+1

Error 13: Invalid or unsupported executable format

> or if that doesn't work:
>
> title Windows rootnoverify
> rootnoverify (hd0,0)
> chainloader +1

This is as before, except without the error message on the partition. It just
goes to a sort of cmd prompt, which looks like this:

GRUB _

But I can't type anything and have to restart the computer.

Hope this helps.

Bug 19000 explains what I think has happened here. And though it talks about
ntfs resizing, the partition start shifting issue is filesystem and even
resizing independent and fairly often happens with any distros using libparted
based partitioners since the end of 2003. The situation was improved last summer
significantly but still not fully fixed. This may be a libparted or a libparted
usage bug.

Hey

I got the same problem but, I added this which I found above but changed the hd0,0 to hd0,1 because of the dell recovery partition which is under hd0,0. When Windows booted it checked for consistency and did whatever it thought it had to do and worked fine after wards

So editing the menu.lst file does work

title Microsoft Windows
root (hd0,1)
savedefault
makeactive
chainloader +1

Thanks

While not a duplicate, the recovery partition accessibility problem is also discussed in Bug 19634.

you need to fix the ntfs bootsector, which solves this issue ( it did for me at least ). use "fixboot" from the win recovery console, and grub should boot win fine.

I don't think this is related to Windows partitions, since I updated the kernel lately to 2.6.22-14 with the update manager and my grub menu was clean fresh. Just like a new install. I did made some modifications to the menu. I moved the Vista option second, added a MEM=3000 to my Ubuntu boot options, but all gone after this update.

Oddly, my nvidia drivers installed with Envy are still working perfectly.

Hi Alexandre,

When you update your kernels, the part that runs is update-grub, which has no knowledge of Windows whatsoever. Instead, this is a script that manages the part of your /boot/grub/menu.lst file between the "### BEGIN AUTOMAGIC KERNELS LIST" and "### END DEBIAN AUTOMAGIC KERNELS LIST" markers. If you add a Windows boot entry between these markers, you're absolutely right that it will disappear on a kernel upgrade, and that this has nothing to do with Windows partitions - that's bug #21412 in grub, which has been fixed for Ubuntu 8.04.

Your symptom does not match what has been originally reported in this bug, however, so I have not presumed that this is a duplicate of bug #21412 - it appears to be a real problem with grub loading Windows at boot time, unrelated to problems with menu.lst being overwritten.

Thanks Steve for this good explanation. In this case, I created a request in Bug #191738 .

I think this may also happen if you abort an NTFS partition resize operation (during installation of Ubuntu), because then the NTFS filesystem becomes dirty and need checking.

happened to me on 9.10. It was alright until IT update program in windows installed safeboot.

then after the next kernel update in ubuntu, the grub script simply removed the windows entry.

os-prober returns nothing.

I strongly suggest to add a simple backup of the generated grub.conf since important information may be lost on those cases.

an easy patch:
--- grub-mkconfig
@@ -266,6 +266,8 @@
fi

if test "x${grub_cfg}" != "x" ; then
+ # backup previous one
+ cp ${grub_cfg} ${grub_cfg}.backup_`date +%Y%m%d_%s`
  # none of the children aborted with error, install the new grub.cfg
  mv -f ${grub_cfg}.new ${grub_cfg}
fi

Thank you for taking the time to report this bug and helping to make Ubuntu better.
Looks like the bug was accidentally marked incomplete by vingslagsvisvidare.

However, You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

I don't have the relevant hardware any more so can't test further. Perhaps some other subscribers to the bug can help.

can't test either. grub install is not something you do regularly :)

This bug isn't about installing grub, but simply about starting system with a/the NTFS partition with "dirty" flag. E.g. while running Windows, cut down the AC power. Running ntfsresize also used to set the dirty flag so that the Windows chkdsk would kick in during (Windows) boot.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Sorry, should not have marked invalid. It is considered incompletely closed.

Should not have touched this, my apologies.

--- grub-mkconfig
@@ -266,6 +266,8 @@
fi

if test "x${grub_cfg}" != "x" ; then
+ # backup previous one
+ cp ${grub_cfg} ${grub_cfg}.backup_`date +%Y%m%d_%s`
  # none of the children aborted with error, install the new grub.cfg
  mv -f ${grub_cfg}.new ${grub_cfg}
fi

There isn't really anything that we can do about this. os-prober can't detect Windows if it can't mount the partition. It can't mount the partition if it needs recovery.