RE: Installing Debian on second hard disk
> -----Original Message-----
> From: Dhiraj [mailto:email@example.com]
> Sent: Thursday, January 29, 2004 3:43 AM
> To: firstname.lastname@example.org
> Subject: Re: Installing Debian on second hard disk
> Thanks for your reply. I now see some possibility that it
> might work.
> However, for the problem you are facing, that even when you setup the
> second(slave ?) HDD as the first one in BIOS, that drive ends
> up as hdb
> instead of hda. That I think is because, Linux ignores the BIOS and
> finds out info about the disks on its own, so it knows that
> hd0 is not
> the first hard disk but the second one. I think windows 2000 also
> functions like this. So, I need to know whether your hard
> disk was hda
> or hdb at the time of installation of Debian. If the disk
> name changes
> will debian still boot or will it refuse to boot ?
It's not really a problem for me at all - anymore at least. It just caused a
bit of grief for me when I was setting up grub on both drives, as I didn't
initially realize that grub labels drives differently than the kernel does.
In any case, in answer to your question:
I initially installed Debian on the hda drive that came with the box - a 30GB
drive, which is a bit old and slow by today's standards. So a few months
later, I bought a newer, faster 120GB drive (hdb) and copied (using dd) the
contents of hda to it. I then changed the BIOS so that it would boot off of
hdb (which it did) and I figured I was done.
Recently, though, when I tried to install an upgraded kernel on hdb, I
discovered that the configuration I had created was actually booting grub and
the kernel from off of hda instead of hdb like I intended.
That's when I started playing around with grub to straighten it all out, and
learned about how grub and the kernel handle drive labels while booting.
> I want a separate grub on both hard disks and I will load the second
> grub from the first one when I want to boot an OS on the
> second disk, I
> will remap hd0 and hd1 to fake the BIOS change. Hope I can
> fool them !
> Why don't you too try this out instead of making changes in BIOS
> everytime you want to boot from the second hard disk. Just write map
> (hd0) (hd1) and map (hd1) (hd0). This should swap your HDD's without
> making changes to the BIOS everytime. Then you load the grub on the
> second disk using chainloader just like we load windows bootloader.
> thanks a lot
The reason I didn't want to do this is so that I could have a "backup drive"
for disaster recovery purposes. I wanted to make it so that either drive
would be able to boot completely independently of the other. More
specifically, I wanted a setup whereby if I messed up something in my config
on the main drive (the fast, new, 120GB hdb) in such a way that I couldn't
boot off of that drive, I wanted to be able to just tweak the bios and boot
off of hda, so that I could then fix whatever was wrong on hdb. Basically
this is the equivalent of having a knoppix/rescue disk pre-installed in the
Why don't I just use knoppix instead of hda as a backup? I don't know. hda
was already there and not doing anything, so this seemed like a good use for
it. I also use to hold backups of some files from hdb, in case hdb gets
FYI - you should make sure to read the other response on this thread from Tom
> Debian can be installed to any drive, but if Debian is
> installed to hda
> and then you later move that drive to hdb, you'll need to change the
> /etc/fstab entry for the root partition from hda to hdb. BIOS swapping
> or remapping in Grub won't work because the kernel ignores
> these once it
> takes over on the boot.
He makes a good point here. This is an argument for you not moving the drives
around in your machine too much while you're doing these installs, since
you'll have to keep updating the /etc/fstabs on the machines to reflect their
new drive label.
Hope this helps, and answers your questions.
Good luck with the setup!
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.