If your installed Mint cannot boot
From Linux Mint
Sometimes Mint will not boot after a fresh installation or after you have added a new disk.
If you only have one disk, this guide is not for you.
If you only have IDE disks or only have SATA disks, this guide is probably not for you.
If you have a mix of IDE and SATA disks, then this guide is definitely for you.
If you have an external boot disk connected via USB (or Firewire or e-SATA), this guide is also for you.
This guide will be rendered (very) obsolete with the release of Linux Mint 8, Helena.
Contents |
The basics
This is about how disks appear in your system and as it depends on both hardware and the operating system - Mint - this is not an easy subject
You can boot from any hard disk, but it is strongly recommended to use the first master for this
But - you can have a first master for IDE and another for SATA (one of the SATA connections is considered first master, all SATA disks are master.)
Which disk is the boot disk is set in BIOS. Unless there is an error you are taken directly to this disk at boot. It should not matter if you connect or disconnect disks (except the boot disk of course)
IDE disks and SATA disks are treated as two separate groups (as they are)
The problem
Often, but not always, IDE disks have priority over SATA disks
Already here we see a problem - often, but not always. This makes it very hard to suggest a solution that is known to work. (See below)
Furthermore with the kernel beginning in Daryna there is a new disk driver that makes all hard disks become sdx, the hdx denomination is obsolete. The IDE disks are also placed after the SATA disks.
All this means that if you have a SATA disk set to boot, when connecting an IDE disk the boot disk is still the same, but the numbering of disks change.
The disk you connected becomes sda and the SATA disk you used becomes sdb - and you are out of luck, you can't boot.
However if your BIOS/motherboard considers IDE to be after SATA nothing should happen to your boot.
The same happens if you have a SATA (or IDE) as boot disk that is not the first master and you connect another disk of the same type that is first master - it is "higher" and becomes sda and your boot disk becomes sdb (There is no major difference with several disks)
A solution
This is a well (?) known bug in grub and there is no solution to it as long as you use sda, sdb etc in grub
This is probably one of the reasons why Ubuntu introduced UUID
This stands for Universal Unique IDentifier and it creates a lot of problems. As soon as you change anything in the basics of a disk, a new UUID is created. this could be that you reinstall your Mint - and a new UUID is created
There is a wiki about the problems this creates UUID_-what_is_it_and_why_is_it_a_problem
Because of this we abandoned UUID in grub.
However when you add/remove a disk that is "prior" to the boot disk UUID is the only solution (at least that I know of)
Take a look at this section of /boot/grub/menu.lst (this is the "configuration file" for grub) from Elyssa:
title Linux Mint, kernel 2.6.24-16-generic root (hd0,1) kernel /boot/vmlinuz-2.6.24-16-generic root=/dev/sda2 ro quiet splash initrd /boot/initrd.img-2.6.24-16-generic
When the computer boots the BIOS hands over control to the boot disk and the file is read from top to bottom one line at a time
So regardless of everything else we are "here" after the boot - provided this is (hd0,1) which it is if you have grub in the MBR of the boot disk.
Grub uses it's own denomination where (hd0,1) is the same as sda2 and sda is the boot disk. Normally you have grub placed like this (it does not matter if it's (hd5,1) or as here (hd0,1))
If you do not have grub on the boot disk you have to chainload it.
I have no possibility to check what happens but I suspect this will be broken if you add a disk
As you can see there are two instances of root - the first one we have just discussed
Between the first and the second instance of root there is a change and now grub uses Linux denomination
If a disk is added with a higher priority than (in this case) sda it becomes sdb and it is impossible to boot. But if you use UUID instead of "/dev/sdx" booting will continue
So if instead you have
title Linux Mint, kernel 2.6.24-16-generic root (hd0,1) kernel /boot/vmlinuz-2.6.24-16-generic root=UUID=db4dcb0c-02bd-4d2e-a4fa-deb420b3bfa0 ro quiet splash initrd /boot/initrd.img-2.6.24-16-generic
booting will continue normally (Note - this UUID is the right one for that disk and that disk alone)
What do you do?
This is a solution for Daryna and Elyssa (and possibly the following Mint editions)
To find out your different UUIDs run
sudo blkid
in a terminal.
Exchange in /boot/grub/menu.lst /dev/sdx with the proper UUID you just found out .
Caution - the quotation marks you get in the result in the terminal must be removed
If you can't boot, this has to be done from the live CD (where sudo has no password - be careful)
Another solution
This is not the scenario this wiki was written for, but it's well worth mentioning.
It should not look like this in Daryna and later as all disks now are sdx
If you get hdx in Daryna and later it's in itself a bug.
A workstation with 4 disks: 1 IDE + 3 SATA.
After installation and rebooting there was GRUB error 22.
The solution to this problem is by editing /boot/grub/device.map.
It looks like this
Before:
(hd0) /dev/hdb (hd1) /dev/sda (hd2) /dev/sdb (hd3) /dev/sdc
After:
(hd0) /dev/sda (hd1) /dev/sdb (hd2) /dev/sdc (hd3) /dev/hdb
And, of course, it is necessary to edit /boot/menu.lst. (and not necessary to use UUIDs :) )
Whether it is necessary to use UUID depends on if you have a removable disk or not
What happened here is that during installation the IDE is seen before the SATA but during normal boot it is seen after the SATA (and the fact that it is hdb indicates some sort of bug)
So one can say that this is a stationary variant of the above :)
It's hard to say why this happened, but grub is complex and interacts with complex hardware
