Super Linux Guru required with strong boot-fu!

Peon said:
Im finishing up now and noticed on the good working drive the swap partition (sda2) is not mounting as it does not contain superblocks. Ive searched for the backup blocks and are unable to restore the backup blocks to assemble md1 (swap) with sda2.

Any advice?
Click to expand...

The swap partition doesn't have a file system on it, its treated as a raw block device for speed so there won't be any superblocks. Try "swapon /dev/sda2" and then "swapon -s" to see if its up. If its hosed for some reason just go "mkswap /dev/sda2" and then try again. If its not starting at boot up then the /etc/fstab file is incorrect. Naturally make sure /dev/sda2 is a swap partition before running mkswap.
 
mxc said:
The swap partition doesn't have a file system on it, its treated as a raw block device for speed so there won't be any superblocks. Try "swapon /dev/sda2" and then "swapon -s" to see if its up. If its hosed for some reason just go "mkswap /dev/sda2" and then try again. If its not starting at boot up then the /etc/fstab file is incorrect. Naturally make sure /dev/sda2 is a swap partition before running mkswap.
Click to expand...

swapon /dev/sda2 works and using -s verifies it is running. md0 array is sda1+sdb1. md1 array is sda2+sdb2. md1 array is a swap partition. Im trying to get sda2 back into md1. sdb2 assembles in md1 no problems.

Trying to assemble sda2 into md1 complains about that superblock and thats perhaps where I went wrong?
 
Could I not try recreate the partition layout using sfdisk?

sfdisk -d /dev/sdb | sfdisk /dev/sda

sdb partitions mount successfully in both arrays. Its just sda2 which is broken.
 
Peon said:
Could I not try recreate the partition layout using sfdisk?

sfdisk -d /dev/sdb | sfdisk /dev/sda

sdb partitions mount successfully in both arrays. Its just sda2 which is broken.
Click to expand...


You could just delete the raid array used for swap. Not much point in having swap on a raid device. Better to have two separate swap partitions. But if you want to keep it as is it seems the raid metadata on sda2 is corrupt.

*You must first make sure sda2 has been marked as faulty and removed from the /dev/md1 "mdadm /dev/md1 -f /dev/sda2; mdadm /dev/md1 -r /dev/sda2"
*then you may need to dd the sda2 partition to wipe out all meta-data "dd if=/dev/zero of = /dev/sda2". You can do the whole partition or just enough to kill the metadata. "dd if=/dev/zero of=/dev/sda2 bs=1024 count=100"
* then readd it to the raid device "mdadm /dev/md1 --add /dev/sda2"
 
mxc said:
You could just delete the raid array used for swap. Not much point in having swap on a raid device. Better to have two separate swap partitions. But if you want to keep it as is it seems the raid metadata on sda2 is corrupt.

*You must first make sure sda2 has been marked as faulty and removed from the /dev/md1 "mdadm /dev/md1 -f /dev/sda2; mdadm /dev/md1 -r /dev/sda2"
*then you may need to dd the sda2 partition to wipe out all meta-data "dd if=/dev/zero of = /dev/sda2". You can do the whole partition or just enough to kill the metadata. "dd if=/dev/zero of=/dev/sda2 bs=1024 count=100"
* then readd it to the raid device "mdadm /dev/md1 --add /dev/sda2"
Click to expand...

I did just that. I deleted the md1 array and recreated it by forcing it to take sda2.

hit the mkswap on the new md1 array and re-created the mdadm.conf. Checked it all by swapon -s and its running. Still curious as to know why it refuses to grub-install on md0 and keeps LILO.

Nonetheless the server is back up and running.

Thank you mxc and everyone else for helping.
 
mxc said:
You could just delete the raid array used for swap. Not much point in having swap on a raid device. Better to have two separate swap partitions.
Click to expand...
You should keep swap on the RAID array. If you have two separate swap partitions, your machine will crash if one of your drives goes offline.
 
ginggs said:
I have several machines with grub on software (mdadm) RAID 1 arrays. All running Ubuntu, but should be no different with Debian.
Click to expand...

I agree, its a simple matter of grub-installing on the RAID1 array. But I promise you it bombs out. It refuses to install even if I force it.
 
Peon said:
I agree, its a simple matter of grub-installing on the RAID1 array. But I promise you it bombs out. It refuses to install even if I force it.
Click to expand...

Yeah the problem isn't grub - your disks have a gpt and not an mbr partition table and you are trying to boot from a bios system or maybe a uefi system that is in legacy mode. For this to work you need a special "bios boot partition" on your drive to host the 1.5 stage boot loader binary but you have not space available to create one.

You could delete the swap partition and free up some space for a bios boot partition, about 1-2MB, and then you may be good to go. You can create a smaller swap partition. You will need to set the grub_bios flag on the partition. "parted /dev/disk set partition-number bios_grub on"

You could also try put the motherboard firmware into efi mode - but you will still need an efi partition for that to work too.

PS: I did this a while ago so my memory may be hazy.
 
mxc said:
Yeah the problem isn't grub - your disks have a gpt and not an mbr partition table and you are trying to boot from a bios system or maybe a uefi system that is in legacy mode. For this to work you need a special "bios boot partition" on your drive to host the 1.5 stage boot loader binary but you have not space available to create one.

You could delete the swap partition and free up some space for a bios boot partition, about 1-2MB, and then you may be good to go. You can create a smaller swap partition. You will need to set the grub_bios flag on the partition. "parted /dev/disk set partition-number bios_grub on"

You could also try put the motherboard firmware into efi mode - but you will still need an efi partition for that to work too.

PS: I did this a while ago so my memory may be hazy.
Click to expand...

Thanks again mxc for your input. I tried that. But that stupid LILO boot loader still comes up. grub-install still failed on the new little boot partition I created. It complained that its in a raid array and cant be embedded.
 
Peon said:
Thanks again mxc for your input. I tried that. But that stupid LILO boot loader still comes up. grub-install still failed on the new little boot partition I created. It complained that its in a raid array and cant be embedded.
Click to expand...

mmmm - the machine god is angry. The only thing I can suggest now is sacrificing an Apple Mac to appease him. If that's not an option a windows machine might do but that might piss him off even more - might work if its an entire server farm of windows machines :)
 
Peon said:
I did just that. I deleted the md1 array and recreated it by forcing it to take sda2.

hit the mkswap on the new md1 array and re-created the mdadm.conf. Checked it all by swapon -s and its running. Still curious as to know why it refuses to grub-install on md0 and keeps LILO.

Nonetheless the server is back up and running.

Thank you mxc and everyone else for helping.
Click to expand...


/dev/mdX isn't a partition or a drive, it's a mdraid device and an mdraid device doesn't have a boot area.
grub only installs to the physical drives.

By default if you are installing linux with mdraid, grub will only install to 1 of the drives in the mdraid array.
Normally if we are doing something with mdraid, the first thing we do is install grub to the remaining physical drives.


What you could try is boot up off a live ISO.
assumping the "OK" drive is /dev/sda


Code: 
mkdir /mnt/system
mount /dev/sda1 /mnt/system
mount -t proc proc /mnt/system/proc
mount --rbind /dev /mnt/system/dev
mount --rbind /sys /mnt/system/sys

chroot /mnt/system /bin/bash
source /etc/profile

Then install grub on the new drive:

Code: 
grub-install /dev/sda
grub-install --recheck /dev/sda

Then edit /boot/grub/grub.cfg
Change the root=(X,X) values to root=(hd0,0)

then exit out of everything and reboot:

Code: 
exit
umount /mnt/system/dev
umount /mnt/system/proc
umount /mnt/system/sys
umount /mnt/system
reboot
 
Last edited:
Thank you murmaider.

I would have loved to have tried what you said, the server is back in the DC now.

I understand everything you said except this:
mkdir /mnt/system
mount /dev/sda1 /mnt/system
mount -t proc proc /mnt/system/proc
mount --rbind /dev /mnt/system/dev
mount --rbind /sys /mnt/system/sys

chroot /mnt/system /bin/bash
source /etc/profile
Click to expand...

Why would one need to remount the filesystem into the system folder one creates? Please could you also explain the --rbind
 
Peon said:
Why would one need to remount the filesystem into the system folder one creates?
Click to expand...
You have booted off a live ISO, but you want to make changes to the filesystem on /dev/sda1, so you mount it.

You then want to change root (chroot) so that / appears to be the filesystem you have just mounted, so that when you install grub, it modifies the filesystem on /dev/sda1 not your running live OS.

But, if you do this now, /dev, /proc and /sys will be the empty directories from /dev/sda1, so first you remount (bind mount) them from your running live OS over the empty directories in /mnt/system, and then you chroot. See 'man mount'.
Peon said:
Please could you also explain the --rbind
Click to expand...
rbind is a recursive bind mount, it will include any possible submounts.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X