Existing LVM2 volume groups corrupted by intrepid/8.10 server installation AND then fails to boot: GRUB Error 2

Bug #313830 reported by JamesRichardson
4
Affects Status Importance Assigned to Milestone
debian-installer (Ubuntu)
New
Undecided
Unassigned

Bug Description

Package was 8.10 Server Installation CD

System was configured as feisty server, but no direct upgrade path was available due to removal of feisty repositories. Reinstallation was chosen as best way to upgrade to intrepid.

System was originally Efty, but had been upgraded to feisty using on-line dist-upgrade.

System Hardware
sda - JBOD Single Drive BIOS Silicon Image
sdb - JBOD Single Drive 3ware Escalade 8506
sdc - RAID5 3 Drive 3ware Escalade 8506

System was configured as
/boot sda1, / sda2, swap sda3 /home /usr /tmp /var on lvm on sda4
/data on sdc1 (note this has a partition)
/data1 on sdb (note this has no partition)

After chosing manual partitioning of disks, to keep everything the same... i found that BOTH sdc1 and sdb had been pvcreate'd. This overwrote both the pv and vg information.

As this also coincided with a reinstallation over existing /etc, recovering the volume groups was rather difficult. (It took 2 days scanning raw devices to find a back up of /etc that had been made in the raid vg, to rewrite by hand the text vg metadata and then use pvcreate --uuid & vgcfgrestore)

Using the partitioner, i had not selected sdc1 and sdb to be involved in the process at all, figuring that they could be added after the installation.

IN ADDITION - After the installation, the computer failed to boot - Giving GRUB Error 2. It took some time to find a solution that worked, given this hardware setup. In the end, i found that a) removing the silicon image device, and b) removing the whole-disk lvm allowed the system to boot. After booting knoppix, and chrooting into the install, i found that grub-install failed due to "unknown partition table type". This may have been the root cause of the issue, or another issue. One or other of my solutions may have been the 'thing that fixed it'.

This seems like a very serious issue with either the installer as-is, or the installer combined with a grub-install failure.

Partitions marked as "do not use" MUST NOT be touched as part of the installation process. Under any circumstances.

Obviously i'm not in a position to be able to recreate the issue on my production hardware!

Revision history for this message
JamesRichardson (james-time4tea) wrote :

Update: Apologies - slight mistake in the above write up. sdc1 (LVM with partition) was pvcreated. sdb (LVM without partition) had GRUB installed over the LVM metadata, and was made bootable with MBR.

Net result was the same, as the first couple of sectors got trashed...

Revision history for this message
David Tombs (dgtombs) wrote :

Assigning to Ubiquity. Probably wrong, but at least someone more will actually look at it.

affects: ubuntu → ubiquity (Ubuntu)
Revision history for this message
David Tombs (dgtombs) wrote :

Oops, server is d-i.

affects: ubiquity (Ubuntu) → debian-installer (Ubuntu)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.