Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I installed F12 onto a 4 disk SW RAID5 array. sda has a /boot partition and a <swap> partition and all of the rest of the storage is raided to make the / partition.
The installer listed sda as the HDD with the boot partition so I updated the MBR on sda durring install. After the reboot I was sent to a grub prompt. I could run,
grub> find /grub/stage1
(hd1,0)
and then
grub> configfile (hd1,0)/grub/grub.conf
and the system boots.
I'm not sure if this a BIOS disk ordering problem. I tried switching a few SATA cables, to try and reorder disks but I couldn't get to the grub prompt with the different configurations I tried.
Should I try copying the MBR from one disk to another? It seems like it's getting past the MBR otherwise grub wouldn't load at all, so is this a grub bug?
Very unlikely a grub "bug" - more likely a problem with the initscripts that mapped it as sda. If it were me I'd simply write the MBR on hd1 - from the command mode you are in at boot
Very unlikely a grub "bug" - more likely a problem with the initscripts that mapped it as sda. If it were me I'd simply write the MBR on hd1 - from the command mode you are in at boot
Code:
setup (hd1)
Thanks for the suggestion, but I'm still having problems...
D'oh - you'll need to set the root (for grub) first
Code:
root (hd1,0)
setup (hd1)
grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd1,0)
Checking if "/boot/grub/stage1" exists... no
Checking if "/grub/stage1" exists... yes
Checking if "/grub/stage2" exists... yes
Checking if "/grub/e2fs_stage1_5" exists... yes
Running "embed /grub/e2fs_stage1_5 (hd1,0)"... failed (this is not fatal)
Running "embed /grub/e2fs_stage1_5 (hd1,0)"... failed (this is not fatal)
Running "install /grub/stage1 (hd1,0) /grub/stage2 p /grub/grub.conf "... succeeded"
Done.
grub> reboot
still goes to grub prompt on boot.
Should I be doing something instead of an immediate reboot after setup?
More info: The root FS is xfs on LVM/RAID5. Should grub be trying to install xfs_stage1_5 when I run setup (hd1,0)? I can see a xfs_stage1_5 file in /boot/grub/ once the system is booted.
D'oh - you'll need to set the root (for grub) first
Code:
root (hd1,0)
setup (hd1)
If I understand correctly this installs the MBR on the disk with the /boot partition. I probably now need to rearrange the sata cables so the bios tries the disk with the /boot partition before the one with the MBR, but not the /boot partition.
Sometimes if you look, the device identified by the kernel as the first drive is not the first drive according to the BIOS.
You can fix this in the /boot/grub/device.map file.
If I understand correctly this installs the MBR on the disk with the /boot partition. I probably now need to rearrange the sata cables so the bios tries the disk with the /boot partition before the one with the MBR, but not the /boot partition.
Yep - it appears the previous MBR is still being read. Two more options to consider:
- over-write that MBR as well - use "setup (hd0)"
- zero out that MBR; probably the way I'd go, but has most potential to screw a system.
Sometimes if you look, the device identified by the kernel as the first drive is not the first drive according to the BIOS.
You can fix this in the /boot/grub/device.map file.
You want to make sure that (hd0) maps to /dev/sda.
[root@storage ~]# cat /boot/grub/device.map
# this device map was generated by anaconda
(hd0) /dev/sda
and
[root@storage ~]# mount
/dev/mapper/vg_storage-LogVol00 on / type xfs (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
Does this mean that during runtime sda == hd0, but during boot sda == hd1?
Yep - it appears the previous MBR is still being read. Two more options to consider:
- over-write that MBR as well - use "setup (hd0)"
- zero out that MBR; probably the way I'd go, but has most potential to screw a system.
Your choice how to proceed.
I tried swapping SATA0 with SATA1, but that didn't work. I'm not sure how to tell which disk is hdX or sdX. I agree that zero-ing out is probably the best way to go since then I can zero out hd0 regardless of which SATAX it is. I'm a bit concerned by what jschiwal asked me to look into since it appears that grub may be enumerating differently than Fedora is.
I'm also not sure if reordering SATA cables would impact RAID/LVM.
Disk /dev/sda: 1500.3 GB, 1500300828160 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00039ce4
Device Boot Start End Blocks Id System
/dev/sda1 * 1 131 1048576 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 131 392 2097152 82 Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3 392 182401 1461990273 fd Linux raid autodetect
Disk /dev/sdb: 1500.3 GB, 1500300828160 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Disk /dev/sdb doesn't contain a valid partition table
Disk /dev/sdc: 1500.3 GB, 1500300828160 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Disk /dev/sdc doesn't contain a valid partition table
Disk /dev/sdd: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Disk /dev/sdd doesn't contain a valid partition table
Disk /dev/md0: 4491.2 GB, 4491233918976 bytes
2 heads, 4 sectors/track, 1096492656 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000
Disk /dev/md0 doesn't contain a valid partition table
Disk /dev/dm-0: 4491.2 GB, 4491231363072 bytes
255 heads, 63 sectors/track, 546027 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Disk /dev/dm-0 doesn't contain a valid partition table
You have new mail in /var/spool/mail/root
[root@storage ~]# dd if=/dev/zero of=/dev/sdb bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.002466 s, 208 kB/s
[root@storage ~]# dd if=/dev/zero of=/dev/sdc bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00119445 s, 429 kB/s
[root@storage ~]# dd if=/dev/zero of=/dev/sdd bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000925447 s, 553 kB/s
rebooted
grub loaded and tried to boot the kernel, but then I got:
Error 5: Partition table invalid or corrupt
Press any key to continue... (<-- this returns me to the grub menu)
I think at this point I may be beyond repair. Unless there are any other suggestions I guess I need to reinstall.
Things look pretty grim - you wiped out the partition table for that /dev/sda disk in addition to the MBR. FWIW, sector zero contains the MBR - as well as the partition table. In future use bs=446 - or even a few less. I find 300 is usually sufficient to bypass the BIOS search code.
Testdisk is the tool to resolve this normally, but I don't know if it'll handle RAIDed partitions. Try it. If that fails you can always just use the listing above in fdisk to recreate the partition table.
As for the rest of those disks, who knows. I presume the entire disks were used for the RAID set - which means you may have trashed the metedata for the RAID.
I reinstalled F12 and ran into the same issue. This time however, I was able to go to the BIOS boot menu and select channel 2 for boot (0 and 1 are IDE). It booted, so I went into the BIOS configuration and found that the boot disk order had channel 4 first. I really thought I had previously looked everywhere in the BIOS for the ordering but obviously I missed it. So, after making channel 2 the first boot disk it seems to boot fine. Now back to scp-ing data back onto the RAID.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.