Catastrophic Hardware Failure - Moving to Sabayon...

[BHReach]

I had a catastrophic hardware failure over the weekend, the memory on my main computer failed. I am going to have to move to Sabayon sooner than expected even though my test phase is not really completed.

I put all my hard drives (3 SATA -> 1TB, 320GB and 120GB and 2 IDE -> 40GB each) in a computer with my latest Sabayon installation and am trying to extract data. The disks all seem to be OK and the data appears to be intact.

I booted System Rescue Disk and Ultimate Boot CD in an attempt to boot from partitions on some of my hard drives but I failed at that because I think those OSes don't like my hardware. In the process I managed to trash the MBR of my Sabayon installation disk. I wasted several hours trying to fix that until I discovered that the Sabayon installation disk can repair it.

Once that was fixed, the next problem was that none of my file managers would let me access the partitions. pcmanfm lists the partitions (gnome-comander and mucommander don't) but says I am not authorized to mount them, even when it is launched as root. I will investigate this more for a solution later.

I mounted the partitions manually and prepared to extract my data. I plugged my USB external hard disk in and Sabayon would not recognize it.

Code: Select all

dmesg

new high speed USB device number xxx using ehci_hcd
unable to enumerate USB device on port 3

repeats over and over.

After some research, I discovered a solution, disable ehci_hcd. Fortunately Sabayon has that loaded as a kernel module so:

Code: Select all

modeprobe -r ehci_hcd

removes it. The USB drive was now 'enumerated' and usable but it caused 2 very bad consequences. First it is pig slow running at USB 1.1 speed (it is taking an hour to burn a DVD with data from it and it is not even full) and my USB wifi adapter stopped working. It is not a slow drive, here are the specs:

Western Digital My Book Essential WDG1U2500N

USB 2.0, Capacity 250GB, 7200 RPM

Average Seek Time: 8.9ms

Average Latency: 4.2ms

I don't understand why I have to disable USB 2.0 to get a USB 2.0 device to work? This is a serious bug.

Next problem is with LVM. I have to disconnect my 300GBG drive to get Sabayon to boot. When the drive is connected, Grub gives an error

No such device 5b....

A big long number with 5 and b near its start, it wasn't on the screen long enough for me to copy it down. Then when it boots I see an error message

Failed to start LVM

It finishes booting and I get a text login screen but cannot login. I turn the computer off and disconnect the 320 GB HD. The next time the computer boots I get a kernel panic and it hangs.

I reboot and it boots normally (if I don't let it finish booting after the grub error and just turn it off, I never get the kernel panic).

I found this section in the grub.cfg file:

insmod lvm
insmod part_msdos
insmod ext2
set root='(vg_kiwi-lv_root)'
search --no-floppy --fs-uuid --set=root b5018f04-340e-49be-ad9a-5950a1cba0bf
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=1024x768
load_video
# vga= is deprecated, grub2 handles this just fine
# making grub2 res == linux fb res
set gfxpayload=keep
insmod gfxterm
fi
terminal_output gfxterm
if sleep --interruptible 0 ; then
set timeout=5
fi

That long b5 number might be the one grub says "No such device" for.

I have not looked at the internal workings of grub for quite a while ( since the original grub before grub2) so the config file looks strange to me but the b5 device looks like it's the one Sabayon is installed on. I think the 320 GB drive has an earlier version of Sabayon on it so that may be confusing grub. The uuid numbers are randomly generated and possibly the 1 TB and 320 GB hard drives were assigned the same number.

Why I suspect that is because there is a logic puzzle game called Einstein and the solution to the 1st puzzle when you start the game is identical under Gentoo even several years ago and Sabayon today, the puzzles after that are random; however, when I play the game under Slackware the 1st puzzle's solution is always random. Gentoo might be doing something unusual with the system random number generator to cause that.

I think I will boot from a live DVD and wipe that 320 GB drive clean to see if that makes a difference.

[BHReach]

I wiped the 320 GB HD and rebooted, 1st time I got a screen full of Segmentation Faults. I pressed reset and it booted normally. It must have been some kind of Logical Volume problem.

Add the 320 GB SATA drive, /dev/sdb to LVM:

First get current state of Sabayon File System:

Code: Select all

pvscan

PV /dev/sda2 VG vg_kiwi lvm2 [931.00 GiB / 0 free]
Total: 1 [931.00 GiB] / in use: 1 [931.00 GiB] / in no VG: 0 [0 ]

Code: Select all

vgscan

Reading all physical volumes. This may take a while...
Found volume group "vg_kiwi" using metadata type lvm2

Code: Select all

lvscan

ACTIVE '/dev/vg_kiwi/lv_root' [50.00 GiB] inherit
ACTIVE '/dev/vg_kiwi/lv_home' [871.19 GiB] inherit
ACTIVE '/dev/vg_kiwi/lv_swap' [9.81 GiB] inherit

Sabayon divided the disk space into root (lv_root) on /, home (lv_home) on /home and boot (not part of LVM) on /boot.

Code: Select all

df -T |grep  'Type\|boot\|home\|/$'

Filesystem Type 1K-blocks Used Available Use% Mounted on
rootfs rootfs 52327276 10104612 39601224 21% /
/dev/mapper/vg_kiwi-lv_root ext4 52327276 10104612 39601224 21% /
/dev/sda1 ext4 508745 66614 416531 14% /boot
/dev/mapper/vg_kiwi-lv_home ext4 912589416 20402616 846511488 3% /home

All formatted with ext4.

Use cfdisk to create a primary partition using the entire new disk of type 8e, LVM, and write the partition table.

Code: Select all

fdisk /dev/sdb -l

Disk /dev/sdb: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 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: 0x000de2cd

Device Boot Start End Blocks Id System
/dev/sdb1 63 625142447 312571192+ 8e Linux LVM

Format the partition as ext4:

Code: Select all

mkfs.ext4 /dev/sdb1

Code: Select all

fsck.ext4 /dev/sdb1

e2fsck 1.41.14 (22-Dec-2010)
/dev/sdb1: clean, 11/19537920 files, 1275064/78142798 blocks

Code: Select all

pvcreate /dev/sdb1

Code: Select all

pvscan

PV /dev/sda2 VG vg_kiwi lvm2 [931.00 GiB / 0 free]
PV /dev/sdb1 lvm2 [298.09 GiB]
Total: 2 [1.20 TiB] / in use: 1 [931.00 GiB] / in no VG: 1 [298.09 GiB]

I want to extend vg_kiwi with the new disk space and then extend lv_home with it. With ext4, I think I can do it on-the-fly without unmounting.

Code: Select all

vgextend vg_kiwi /dev/sdb1

Volume group "vg_kiwi" successfully extended

Code: Select all

pvscan

PV /dev/sda2 VG vg_kiwi lvm2 [931.00 GiB / 0 free]
PV /dev/sdb1 VG vg_kiwi lvm2 [298.06 GiB / 298.06 GiB free]
Total: 2 [1.20 TiB] / in use: 2 [1.20 TiB] / in no VG: 0 [0 ]

Code: Select all

lvextend -l +100%FREE /dev/vg_kiwi/lv_home

Extending logical volume lv_home to 1.14 TiB
Logical volume lv_home successfully resized

Code: Select all

lvscan

ACTIVE '/dev/vg_kiwi/lv_root' [50.00 GiB] inherit
ACTIVE '/dev/vg_kiwi/lv_home' [1.14 TiB] inherit
ACTIVE '/dev/vg_kiwi/lv_swap' [9.81 GiB] inherit

Code: Select all

df -h |grep 'Size\|home'

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_kiwi-lv_home 871G 20G 808G 3% /home

Not resized?

Code: Select all

resize2fs /dev/vg_kiwi/lv_home

Code: Select all

df -h |grep 'Size\|home'

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_kiwi-lv_home 1.2T 20G 1.1T 2% /home

Could have used lvresize instead of lvextend and would not have had to resize separately.

The problem with 320GB HD is resolved.