Installing Mint, Screwed Windows
March 3, 2014 1:04 PM Subscribe
I went to install Mint 16 last night (the latest version) as a dual-boot system. I have a 1.5TB disk where Windows 7 lives with Mint 12, and 2 encrypted 3TB disks. (Mint 12 is no longer bootable, BTW.) Obviously, things did not go as planned...
I chose to overwrite the Mint 12 partition, and everything was golden until the installer asked where I wanted to install the boot loader. The suggestion was one of the 3TB disks; that wouldn't do.
Not being sure, I picked the Windows 7 partition, partly because it was labelled as "Windows 7 boot loader". In retrospect... obviously a bad idea.
Anyway, now it doesn't boot into anything. :\ I'm not panicky, because everything is backed up to the cloud, and I have install disks for everything important (including Win7).
So, first: where should I have installed the boot loader?
And: Can I save Windows without reinstalling it, somehow?
I chose to overwrite the Mint 12 partition, and everything was golden until the installer asked where I wanted to install the boot loader. The suggestion was one of the 3TB disks; that wouldn't do.
Not being sure, I picked the Windows 7 partition, partly because it was labelled as "Windows 7 boot loader". In retrospect... obviously a bad idea.
Anyway, now it doesn't boot into anything. :\ I'm not panicky, because everything is backed up to the cloud, and I have install disks for everything important (including Win7).
So, first: where should I have installed the boot loader?
And: Can I save Windows without reinstalling it, somehow?
Response by poster: wierdo: "but generally speaking you "install" GRUB to the MBR of the first disk, not a particular partition."
Yeah, that part struck me as extra-weird. Maybe I misread it...
posted by IAmBroom at 1:27 PM on March 3, 2014
Yeah, that part struck me as extra-weird. Maybe I misread it...
posted by IAmBroom at 1:27 PM on March 3, 2014
Response by poster: Venadium, Mint 12's boot loader was overwritten when I had to reinstall Win7.
I don't recall where I installed Mint 12's boot loader.
posted by IAmBroom at 9:23 AM on March 4, 2014
I don't recall where I installed Mint 12's boot loader.
posted by IAmBroom at 9:23 AM on March 4, 2014
Best answer: GRUB is bloody huge (for a bootloader) when fully optioned, and all that hugeness has to live somewhere.
If you put it on a partition, its first sector goes in the partition's first sector (which is reserved for boot loaders with most filesystems) but then there's nowhere good to put the rest of it, which generally ends up in a file somewhere whose sectors are then directly referenced inside the first sector (there is nowhere near enough room inside the first sector to allow for general filesystem access). This scheme is very fragile - defragmenting the filesystem, for example, might move the bulk of GRUB somewhere different and leave the first sector's lists referencing free space, which will keep being able to boot for a while until it gets re-used by something else and then bam, no more booting.
GRUB calls this "block list" mode and tries to discourage you from using it. Its only advantage is that it doesn't touch the disk's master boot record, meaning that whatever boot loader you already have stays in charge; if you want to use GRUB you need to get at it via the existing boot loader in some way.
Installing GRUB on a whole disk puts its first-stage boot sector in the MBR, which puts GRUB fully in charge. The second-stage bulk of GRUB then still has to go somewhere, and in most cases the GRUB installer will "embed" it.
With a legacy partition table, traditional alignment requirements usually create a little chunk of free space between the master boot record and the first sector of the first partition, and that's where GRUB's second stage code goes. Windows versions XP and earlier start their first partition at disk block 63, meaning that GRUB's second stage has to fit in a shade under 32KB; only quite simple GRUB configurations end up that small. Vista and later start their first partition at block 2048, giving GRUB most of a megabyte to play with - way more than it ever needs.
With GPT partitioning, you need to create a small dedicated partition specifically for that code to go in and set its bios_grub flag. I generally like to make my bios_grub partitions occupy disk blocks 128 through 2047, which is plenty of room for GRUB but still fits before the first block that installation of any GPT-bootable Windows version will have used.
Note that having made such a dedicated partition, you don't tell grub-install to install GRUB to it, but to the whole disk. The dedicated partition then automatically gets used for embedding.
The most likely thing that's happened to your disk is that it's got legacy (MBR) partitioning, that the Windows first-stage boot loader is still installed inside block 0, and that you've overwritten the Windows second-stage boot block in the first sector of your Windows startup partition with a GRUB boot block that the Windows MBR code doesn't know how to launch. The bootrec /fixboot command that wierdo recommends should put Windows's world back together - I'd be surprised to find that bootrec /fixmbr is actually necessary, though it should be harmless.
There will also be a (possibly hidden) file on that partition containing the GRUB second-stage boot, which it should be completely safe to ignore. Once you've put the Windows boot loader back in the partition's first block, GRUB's second stage will never get called.
So once Windows is booting OK again, you should then let Mint install GRUB to the whole disk. If your disk is actually partitioned GPT rather than legacy, this will fail for want of a dedicated bios_grub partition and you'll need to create one of those (it doesn't have to be first, either in the partition table or on disk - so don't move the Windows partitions because Windows will crack the sads if you do). If the disk has legacy partitioning, or GPT partitioning with a small bios_grub partition available, it should Just Work.
The GRUB installation process should automatically detect your Windows startup partition and make an entry in GRUB's boot menu that you can use to chainload to the Windows boot loader inside that partition. Windows's own master boot record is no great loss.
posted by flabdablet at 9:38 AM on March 4, 2014 [3 favorites]
If you put it on a partition, its first sector goes in the partition's first sector (which is reserved for boot loaders with most filesystems) but then there's nowhere good to put the rest of it, which generally ends up in a file somewhere whose sectors are then directly referenced inside the first sector (there is nowhere near enough room inside the first sector to allow for general filesystem access). This scheme is very fragile - defragmenting the filesystem, for example, might move the bulk of GRUB somewhere different and leave the first sector's lists referencing free space, which will keep being able to boot for a while until it gets re-used by something else and then bam, no more booting.
GRUB calls this "block list" mode and tries to discourage you from using it. Its only advantage is that it doesn't touch the disk's master boot record, meaning that whatever boot loader you already have stays in charge; if you want to use GRUB you need to get at it via the existing boot loader in some way.
Installing GRUB on a whole disk puts its first-stage boot sector in the MBR, which puts GRUB fully in charge. The second-stage bulk of GRUB then still has to go somewhere, and in most cases the GRUB installer will "embed" it.
With a legacy partition table, traditional alignment requirements usually create a little chunk of free space between the master boot record and the first sector of the first partition, and that's where GRUB's second stage code goes. Windows versions XP and earlier start their first partition at disk block 63, meaning that GRUB's second stage has to fit in a shade under 32KB; only quite simple GRUB configurations end up that small. Vista and later start their first partition at block 2048, giving GRUB most of a megabyte to play with - way more than it ever needs.
With GPT partitioning, you need to create a small dedicated partition specifically for that code to go in and set its bios_grub flag. I generally like to make my bios_grub partitions occupy disk blocks 128 through 2047, which is plenty of room for GRUB but still fits before the first block that installation of any GPT-bootable Windows version will have used.
Note that having made such a dedicated partition, you don't tell grub-install to install GRUB to it, but to the whole disk. The dedicated partition then automatically gets used for embedding.
The most likely thing that's happened to your disk is that it's got legacy (MBR) partitioning, that the Windows first-stage boot loader is still installed inside block 0, and that you've overwritten the Windows second-stage boot block in the first sector of your Windows startup partition with a GRUB boot block that the Windows MBR code doesn't know how to launch. The bootrec /fixboot command that wierdo recommends should put Windows's world back together - I'd be surprised to find that bootrec /fixmbr is actually necessary, though it should be harmless.
There will also be a (possibly hidden) file on that partition containing the GRUB second-stage boot, which it should be completely safe to ignore. Once you've put the Windows boot loader back in the partition's first block, GRUB's second stage will never get called.
So once Windows is booting OK again, you should then let Mint install GRUB to the whole disk. If your disk is actually partitioned GPT rather than legacy, this will fail for want of a dedicated bios_grub partition and you'll need to create one of those (it doesn't have to be first, either in the partition table or on disk - so don't move the Windows partitions because Windows will crack the sads if you do). If the disk has legacy partitioning, or GPT partitioning with a small bios_grub partition available, it should Just Work.
The GRUB installation process should automatically detect your Windows startup partition and make an entry in GRUB's boot menu that you can use to chainload to the Windows boot loader inside that partition. Windows's own master boot record is no great loss.
posted by flabdablet at 9:38 AM on March 4, 2014 [3 favorites]
Response by poster: Flabdablet, that is everything and more than I hoped for. I thank you.
posted by IAmBroom at 3:06 PM on March 4, 2014
posted by IAmBroom at 3:06 PM on March 4, 2014
Welcome. Would appreciate a followup answer once you get it going again.
posted by flabdablet at 7:35 PM on March 4, 2014
posted by flabdablet at 7:35 PM on March 4, 2014
By the way, you shouldn't need a full Mint reinstall just to make a non-booting but otherwise complete existing installation bootable. You can do that by booting from any Linux live CD for the same machine architecture as that of the installed but non-booting system, then running the installed system's own instance of grub-install from inside a chroot jail.
Example: suppose the root filesystem for your installed but non-bootable amd64-architecture system is on the third partition of the first hard drive. You'd boot an amd64 live CD, open a root terminal, and do
After grub-install reports error-free completion, ctrl-D once to leave the chroot jail, then unmount everything:
posted by flabdablet at 7:58 AM on March 5, 2014
Example: suppose the root filesystem for your installed but non-bootable amd64-architecture system is on the third partition of the first hard drive. You'd boot an amd64 live CD, open a root terminal, and do
mount /dev/sda3 /mnt for d in dev proc sys; do mount --rbind /$d /mnt/$d; done chroot /mnt grub-install --recheck /dev/sdaWith --recheck and the bind mounts in place, I've never seen grub-install fail even when making GRUB to do clever things like boot from encrypted LVM over mdraid or whatever (if your system is more complicated than a rootfs on a single partition, adapt the first mount above as needed so that once you chroot you're working with its entire userland).
After grub-install reports error-free completion, ctrl-D once to leave the chroot jail, then unmount everything:
for d in sys proc dev; do umount -l /mnt/$d; done umount -l /mnt
posted by flabdablet at 7:58 AM on March 5, 2014
Response by poster: That's a LOT more work than just letting the disk do its job in the background. My time is more precious than my computer's. :)
BTW, I haven't accomplished the boot yet because I broke a metafiltering pin off of the metafiltering SATA power plug. Have to fix that first... >:(=(
posted by IAmBroom at 8:47 AM on March 6, 2014
BTW, I haven't accomplished the boot yet because I broke a metafiltering pin off of the metafiltering SATA power plug. Have to fix that first... >:(=(
posted by IAmBroom at 8:47 AM on March 6, 2014
This thread is closed to new comments.
posted by wierdo at 1:13 PM on March 3, 2014