Posted: 19 April 2011 | Author: V. T. Eric Layton | Filed under: Hardware | Tags: Arch Linux, device map, fdisk-l, GRUB, hard disks, menu.lst, SATA, sda, sdb, sdc |
I know that a lot of very knowledgeable gurus read this site, and I’d like to ask a favor of some assistance with an unusual issue that I’m currently having. Any help would be appreciated.
This article was originally posted as a forum submission at two different forums. You can read those threads here and here for some more info and progress.
Here’s a little background for everyone…
I am running Slackware as my primary operating system and Arch as my secondary (backup) operating system on my main computer (ericsbane05). I also have installations of MS Windows XP, CentOS, and Debian on a separate hard drive.
SATA looks like this on my system:
SATA0 channel = /dev/sda, /dev/sdb
SATA1 channel = /dev/sdc, /dev/sr1
SATA2 channel = vacant, vacant
Originally, these drives were in ericsbane03 and 04 with one exception. I only had two SATA drives and one EIDE drive then. The EIDE drive was removed when building this new system and replaced with the drive /dev/sdc that you see above on the SATA1 channel (/dev/sr1 is a DVD R/W, by the way).
Arch Linux’s GRUB controls /dev/sda’s MBR and is the main bootloader for all operating systems on this system. Here’s what my menu.lst looks like:
<snip># IMPORTANT –> Arch GRUB sees /dev/sda as hd0, but /dev/sdb as hd2 (should be hd1).
#
# (1) Slackware64-13.37
title Slackware Primary
root (hd0,0)
kernel /boot/vmlinuz root=/dev/sda1 ro
initrd /boot/initrd.gz
#
# (2) Arch64
title Arch Linux Secondary
root (hd0,4)
kernel /boot/vmlinuz26 root=/dev/sda5 ro
initrd /boot/kernel26.img
# (3) MS Windows XP/SP3
title MS WIN XP Pro
root (hd2,0)
map (hd0) (hd2)
map (hd2) (hd0)
chainloader +1
# (4) CentOS64 5.6
title CentOS Tester01
root (hd2,5)
kernel /boot/vmlinuz-2.6.18-238.9.1.el5 root=/dev/sdb6 ro
initrd /boot/initrd-2.6.18-238.9.1.el5.img<snip>
You can see that Arch’s GRUB thinks that /dev/sdb is (hd2), when in fact, it should be (hd1). This was like this originally because of the hybrid EIDE/SATA setup that I had on previous systems. Now that I’m running pure SATA, I’d like to get this fixed. Here’s what I’ve done so far:
1) I manually edited /boot/grub/device.map to look like this:
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc
It was originally incorrect, but this didn’t fix the issue. GRUB was still seeing the drives incorrectly.
2) I then deleted all files from the /boot/grub directory and used pacman to uninstall GRUB completely.
3) I then reinstalled GRUB and created a new menu.lst with the correct /dev to (hd) conversions. It looks like this now:
<snip>
# (1) Slackware64-13.37
title Slackware Primary
root (hd0,0)
kernel /boot/vmlinuz root=/dev/sda1 ro
initrd /boot/initrd.gz
#
# (2) Arch64
title Arch Linux Secondary
root (hd0,4)
kernel /boot/vmlinuz26 root=/dev/sda5 ro
initrd /boot/kernel26.img
# (3) MS Windows XP/SP3
title MS WIN XP Pro
root (hd1,0)
map (hd0) (hd1)
map (hd1) (hd0)
chainloader +1
# (4) CentOS64 5.6
title CentOS Tester01
root (hd1,5)
kernel /boot/vmlinuz-2.6.18-238.9.1.el5 root=/dev/sdb6 ro
initrd /boot/initrd-2.6.18-238.9.1.el5.img<snip>
The entries for Windows and CentOS reflect the new (and correct) device.map in /boot/grub.
4) After all this, I reinstalled GRUB to the MBR like this:
# grub-install /dev/sda
Unfortunately, GRUB is still seeing /dev/sdb as (hd2). I can get all my operating systems to boot just fine by using the wrong (hd) strings in menu.lst, but I’d really like to get GRUB to work the way it’s supposed to. I’m sure there is something simple here that I’m missing. Any help would be appreciated.
Thanks,
~Eric
Addenda: Here’s a copy of my fdisk -l output along with notations. It might be helpful:
Disk /dev/sdb: 250.0 GB, 250000000000 bytes
255 heads, 63 sectors/track, 30394 cylinders, total 488281250 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009e140
Device Boot Start End Blocks Id System
/dev/sdb1 * 16384 51216383 25600000 7 HPFS/NTFS/exFAT <– MS Windows XP C partition
/dev/sdb2 51232768 102432767 25600000 7 HPFS/NTFS/exFAT
/dev/sdb3 102453181 488270159 192908489+ 5 Extended <– swap
/dev/sdb5 102453183 106550639 2048728+ 82 Linux swap
/dev/sdb6 106565823 137289599 15361888+ 83 Linux <– CentOS /
/dev/sdb7 137304783 188501039 25598128+ 83 Linux
/dev/sdb8 188516223 219239999 15361888+ 83 Linux <– Debian /
/dev/sdb9 219255183 270451439 25598128+ 83 Linux
/dev/sdb10 270466623 301190399 15361888+ 83 Linux <– tester /
/dev/sdb11 301205583 352401839 25598128+ 83 Linux
/dev/sdb12 352417023 383140799 15361888+ 83 Linux <– tester /
/dev/sdb13 383155983 434352239 25598128+ 83 Linux
/dev/sdb14 434367423 488270159 26951368+ 83 Linux <– storage
Disk /dev/sdc: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002cd1d
Device Boot Start End Blocks Id System
/dev/sdc1 16065 102414374 51199155 83 Linux <– Slackware backups
/dev/sdc2 102430440 204828749 51199155 83 Linux <– Arch backups
/dev/sdc3 204844815 488392064 141773625 5 Extended
/dev/sdc5 204860880 307259189 51199155 b W95 FAT32 <– MS Windows backups
/dev/sdc6 307275318 409673564 51199123+ 83 Linux <– tester backups
/dev/sdc7 409689693 488392064 39351186 b W95 FAT32 <– common storage
Disk /dev/sda: 250.1 GB, 250058268160 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488395055 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x24812481
Device Boot Start End Blocks Id System
/dev/sda1 * 16065 51215219 25599577+ 83 Linux <– Slackware primary operating system /
/dev/sda2 51247350 153645659 51199155 83 Linux
/dev/sda3 153661725 488392064 167365170 5 Extended
/dev/sda5 153661788 204860879 25599546 83 Linux <– Arch secondary operating system /
/dev/sda6 204877008 307275254 51199123+ 83 Linux
/dev/sda7 307307448 311403959 2048256 82 Linux swap <– swap
/dev/sda8 311420088 488392064 88485988+ 83 Linux <– archives
Thanks again. 🙂
Posted: 18 April 2011 | Author: V. T. Eric Layton | Filed under: Hardware | Tags: Arch Linux, CompUSA, device map, ericsbane, ericslaptop, ericsshop, framerate, GRUB, hard drives, micro, motherboard, S.T.A.L.K.E.R., Slackware, Tiger Direct |
What is ericsbane? Well, that’s what I name some of my computers. I also have ericslaptop01 and ericsshop01 and 02.
What a strange name this ericsbane thing. Where’d that come from? you might be wondering. The definition of bane is a person or thing that ruins or destroys or the name of a deadly poison. HA! Both are accurate sometimes when it comes to my computering hobby. Computers can be my bane, but I love ’em, anyway.
As some of you may know from reading here and here, I have been having some hardware issues with my main system. And as a sidebar to this, I’ve also been trying to put together a system for my shop. Well, it’s finally all come together. What a nightmare it’s been. Of course, if I had money to burn, this wouldn’t have been an issue at all. Unfortunately, money is very tight right now. We won’t even go into that.
So, what happened this weekend? I woke up Saturday morning jonesing to play one of my vid games on my system. S.T.A.L.K.E.R., Far Cry, Deus Ex, anything. I just wanted to frag stuff. Know what I mean? I haven’t been able to play any games on my main system due to issues with a bad PCIe socket, which has forced me to use crappy onboard graphics. Hmm… can’t play many games these days with a 2900fps framerate.
I made the mistake of going to the local CompUSA (Tiger Direct) store after seeing a really decent mobo/micro bundle advertised online. Hmm… I had spent a few bucks recently on a replacement mobo from them, but it didn’t work out, so I was given a refund. I figured that money was already spent. I had it set aside for a rainy day. Well, that day was Saturday. I went to the CompUSA and got myself a mobo/micro combo.
I came home and, after much travail and gnashing of teeth, I managed to cobble together ericsbane05. Here are the specs:
Cooler Master Chassis Mid Tower Elite 334 Nvidia Edition ATX Casing
Cooler Master Extreme Power Plus – 650watt power supply
785GTM-E45 socket AM2+ motherboard
AMD Phenom 9750 Quad-Core Processor
AMD chipset
4Gig Centon DDR2 800 PC-6400 RAM DDR 800 (slots 1 & 2)
EVGA Nvdia GeForce 450 GTS
IDE 0 Master: Master: DVD Writer 840
IDE 0 Slave: ZIP 100
SATA 0: Western Digital 250Gig
SATA 1: Western Digital 250Gig
SATA 2: Western Digital 250Gig
SATA 3: HLDS GH30N DVD±RW
Standard 3.5″ floppy
Seven (7) cooling fans
=====
HP Deskjet 842C printer
HP Scanjet 3400 flatbed scanner
HP W1907 LCD monitor
Altec Lansing (front) + Harman Kardon (rear) speakers
Dell USB keyboard
Logitech Trackball mouse
So, there ya’ have it. Here’s what the framerate on this baby looks like now:
So much gooder! I can play games again! I can shoot and frag away my frustrations. It’s better than religion, I’m telling you. Woo-hoo!
Oh, and as a by-product of this adventure, I also was able to salvage ericsbane04. I slapped the guts of that system into another box and changed its name to ericsshop02. It’s loaded with Slackware current and is sitting on the bench outside in my shop. I put ericsshop01 on the shelf as a backup system. We are just on a roll here, huh?
I have 99.9% of the kinks worked out of the new ericsbane05. There are always issues when you install pre-existing operating systems onto new hardware. There are issues with drivers, disk nomenclature, sensor daemons, GRUB, etc. I’ve got them all squared away but one, I think. I’m having a minor issue with Arch’s GRUB, the bootloader for my entire system (numerous operating systems installed). It has incorrectly mapped the hard drives. I’m working on it, though.
That, friends, is how I spent the last three days of my life. Bane, indeed. See what I mean?
We’ll have some new lessons coming along shortly. Stay tuned…
Until next time…
~Eric, the happy 19000fps framerate, fraggin’ Slacker!