--------------------------------------------- Drive caddy jumper issues - /dev/hda /dev/hdb and GRUB/boot issues --------------------------------------------- - Ian! D. Allen idallen@idallen.ca You might find that your hard drive caddy gives an error when accessed as "/dev/hda" in the labs; but, it works when accessed as "/dev/hdb"; or, you might discover that your hard drive caddy appears at home as /dev/hdc, /dev/hdd, or some other Unix device. The /dev/ device Unix uses for your caddy drive is determined by the IDE controller, and whether or not the drive itself is jumpered as Master or Slave on that IDE controller. (If you connect the drive via USB, you might even find the drive appearing as /dev/sda or /dev/sdb.) IDE controllers have two channels. In Unix, the first IDE controller will have channels named /dev/hda (Master) and /dev/hdb (Slave). The second controller will have the names /dev/hdc (Master) and /dev/hdd (Slave), etc. USB or SCSI controllers will get sequential names of the form /dev/sda, /dev/sdb, /dev/sdc, etc. If you have jumpered your hard drive in your caddy as "Master", it will always appear in the Algonquin labs to be /dev/hda (first disk on the first IDE controller). Otherwise, your drive is a "Slave" and it will always appear in the labs as /dev/hdb (second disk on the first IDE controller). If you boot Knoppix (or any other live CDROM Linux system) the "fdisk -l" command will list all the hard drives and hard drive partitions about which Linux knows. The output will tell you whether your caddy drive is /dev/hda or /dev/hdb or some other device. (At home, it may even be /dev/hdc or /dev/hdd or something else.) Be aware of how your drive is jumpered inside your caddy, and use the correct device pathname. Exercises will assume /dev/hda - adjust your work if your drive is jumpered as /dev/hdb. How to boot your caddy drive in other machines ---------------------------------------------- This section assumes you have done a basic Mandriva install following the Notes file: mandriva_install.txt You may want to take your caddy drive into another machine than the one in which it was configured and boot an existing installed Mandriva system inside the new hardware. This is possible; but, it is not something that an installed Linux system is designed to do well. Unlike "live" CDROM images that contain large hardware auto-configuration scripts that run (slowly!) every time you boot them (e.g. Knoppix), an installed Linux system has all its hardware fixed and hard-coded into its configuration files. The system boots quickly because it knows what hardware exists. Unfortunately, this quick-boot fails badly if you move your caddy drive into new hardware that doesn't match the Linux configuration files! You may find it easier to simply boot the Mandriva installer on your new hardware and do a fresh Mandriva install into a new partition, rather than try to make an existing install work with the new hardware. A fresh install on new hardware will have the installer configure things for the new hardware. Making the existing install work with the new hardware will require considerable editing of configuration files, and the result will be an installation that no longer works properly on the original hardware. If you really want to make an existing Mandriva installation work for new hardware, you need to adjust the following things: 1. your GRUB boot sequence has to change to adapt to the possibly different disk number of your caddy in the new machine 2. your Linux ROOT and SWAP file systems may be on a different IDE controller in the new machine, as well as your CDROM, requiring a new /etc/fstab file 3. your hardware may be different: network card, usb controllers, sound card, video card, SCSI card, etc., requiring edits to many configuration files To boot the system in the first place, we have to fix the first two items. Even once the system is booted, the differences in hardware may make the system difficult to use. In particular, if the network card is not working, it may be awkward to fetch any missing drivers to make the rest of the system usable (including making the network card work!). The rest of this document will cover getting the system to boot (items 1 and 2 above). Fixing item #3 is not covered completely, if at all. For new hardware, I recommend doing a fresh install into a new partition, rather than trying to re-configure and boot an existing partition. You have been warned. If your drive was configured in the lab to boot off /dev/hda, then after you have done a successful Mandriva installation your GRUB menu (/boot/grub/menu.lst) will contain an entry similar to this: title System-1-(hd0,6)-hda7 kernel (hd0,6)/boot/vmlinuz root=/dev/hda7 initrd (hd0,6)/boot/initrd.img This won't work at home, if your caddy isn't /dev/hda or if your caddy isn't GRUB disk (hd0). At home, you can use GRUB to change this boot information temporarily at boot time, so that GRUB does boot off whichever disk and root partition your caddy appears as. If you can get your system to boot from your caddy drive at home (you may need to tell your computer BIOS to choose this disk), you will get the familar black-and-white basic GRUB menu showing the above title as one of the boot options. You will note that /dev/hda7 is mentioned explicitly as the root= device in the boot menu. If your caddy is used at home, you may need to temporarily alter this at boot time to say /dev/hdc7 or some other value, depending on the actual Unix device that your caddy uses at home. You may also have to edit this boot entry and adjust hd0 to say hd1 or hd2 or some other value, if GRUB doesn't treat your caddy drive as the "first" hard drive. If you are booting from the caddy, GRUB should treat the caddy as its first disk (hd0); but, perhaps not! You can make a temporary change in any GRUB menu item by following the on-screen instructions that GRUB gives: use the arrow keys to move down to the System-1 boot line and type the letter 'e' to temporarily edit this line. You will now be given a choice of two lines to edit - the "kernel" line or the "initrd" line. Use the arrow keys to choose the "kernel" line and type 'e' again. You will now be in a line editor where you can use the arrow keys and backspace to make changes. Backspace to delete /dev/hda7 and change it to /dev/hdc7 (or whatever your correct device is). Also change hd0 to the correct GRUB disk number, if necessary. At the end of the "kernel" line, type a space and add the word "single" (no quotes) to select booting the system in "single user" or maintenance mode. Push RETURN when you are done editing a line. The result will look something like this: kernel (hd0,6)/boot/vmlinuz root=/dev/hdc7 single initrd (hd0,6)/boot/initrd.img You may have had to change hd0 to be hd1 or some other disk number, in both lines. Remember the changes you make here - you will have to make them again any time you boot from home, until you create a new GRUB boot menu item in menu.lst that incorporates these changes. Follow the on-screen instructions and type 'b' to boot this new GRUB menu entry. The boot should continue and linux should start loading. If instead you see an immediate GRUB error "file not found", you probably need to edit and change (hd0,6) to refer to the actual GRUB disk number of your Mandriva installation - perhaps (hd1,6) or (hd2,6), etc. Remember to edit both the "kernel" and the "initrd" lines! Linux should load, displaying the "Welcome to Mandrakelinux" banner, and then grind to a halt right after saying "Checking root filesystem", with messages such as "The superblock could not be read", "no such file or directory", "Failed to check file system" and "Do you want to repair the errors?". Answer "no". You may need to type your ROOT password to enter "Repair filesystem" mode. If instead of this repair question the system boots part-way but halts dead with a message about "kernel panic", "no init", then you didn't get the root= parameter to point to the right partition name containing your installed Mandriva system. Try editing the "kernel" line again and choose the correct /dev/hdX7 partition name for your Mandriva system. At the "Repair filesystem" prompt, we have to edit a file in the Mandriva partition to permit a proper boot. Linux fails to finish booting because a Linux table of file system names still thinks you are booting from /dev/hda and not from the real /dev/hdX of your home system. The file that we must edit at the "Repair filesystem" prompt is named /etc/fstab, and we need to enable writing to the disk to allow this. We re-mount the root file system in read-write mode, make a back-up of the file, and then use vim to change all "hda" to "hdc" in this file: (Repair filesystem) # mount -o rw, remount / (Repair filesystem) # cp -p /etc/fstab /etc/fstab.hda (Repair filesystem) # vim /etc/fstab :1,$s/hda/hdc/ (choose the correct hdX for your home system!) You should also comment out or fix any other /dev/hdX file system entries in this file that are wrong for your home system. (Probably your CDROM drive is not on the same IDE controller slot as it was in the lab. Comment out the CDROM or fix its /dev/hdX reference to be correct.) When you are done, your /etc/fstab will contain at least these two critical entries for your hard disk (with the hdc below referring instead to *your* correct disk controller, hdb, hdc, hdd, sda, sdb, etc.): /dev/hdc7 / ext3 defaults 1 1 /dev/hdc5 swap swap defaults 0 0 If there are any other /dev/hdX entries that are not commented out, you must be sure that they refer to correct disk partitions for your home system. If unsure, comment out the /dev/hdX line. Lines that refer to devices other than /dev/hdX should be left alone. After writing out the file, you can now test your /etc/fstab by typing: (Repair filesystem) # umount -a (Repair filesystem) # mount -a If you see any errors, you need to edit /etc/fstab to fix them. Once the mount works error-free, unmount and then reboot by typing "exit": (Repair filesystem) # umount -a (Repair filesystem) # exit The system will reboot into GRUB again. You will have to make the same temporary edits you made before (fixing root= and perhaps the hd0 numbers); but, you don't need to add "single" before booting. The system should come up; but, since you probably have different hardware, you may find you have no working network. If you boot directly into X11 graphics mode (not recommended for a caddy installation!) your video probably won't work. Good luck. You can mount your Mandriva installation partition (it may already be mounted as /mnt/hd - go look) and edit the GRUB menu.lst file to create a GRUB menu entry that boots your new hardware correctly using the correct GRUB and Linux device names, to avoid having to manually edit the GRUB menu on every boot: # mount /dev/hdc6 /mnt/hd # vi /mnt/hd/boot/grub/menu.lst Here is a sample entry to boot a partition as hda or hdc: title System-1-(hd0,6)-hda7 kernel (hd0,6)/boot/vmlinuz root=/dev/hda7 initrd (hd0,6)/boot/initrd.img title HOME-HDC System-1-(hd0,6)-hdc7 kernel (hd0,6)/boot/vmlinuz root=/dev/hdc7 initrd (hd0,6)/boot/initrd.img Of course when you go back to booting the system from hda, the /etc/fstab file will be wrong again. (You edited /etc/fstab to make it work for /dev/hdc.) You will have to boot single-user and rename the /etc/fstab that you created for hdc, and put back the old fstab that works for hda. And you have to switch these back and forth every time you switch hardware! My advice is to create a separate installation in a new partition for home use; don't try to use the same partition at home and at school.