F11 x86_64 DVD install crashes with existing LVM

gogalago · #1 10th June 2009, 11:27 AM

I can't get F11 x86_64 to install on my main system - although the DVD seems fine as it installed successfully on my laptop.

The problem box has a few partitions on it as well as an LVM setup with a partition spanning across two physical disks. Almost everything is ext3. The install crashes after choosing keyboard layout and during "finding storage devices" with an exception similar to https://bugzilla.redhat.com/show_bug.cgi?id=493181

The exception is:
PartedException: Assertion (!disk->update_mode) at disk.c:421 in function
ped_disk_destroy() failed.

I can't save my own crash report, because it gets stuck "finding storage devices" again when I try to, but apart from the line numbers in the above bug, its identical.

Pretty sure its an LVM issue, but am open to suggestions.

I have an F7 install currently on the drives, and would really prefer to get the F11 up and running and transfer things gradually before I trash it. Was planning to create new partitions for F11 and not really re-use any of the partitions (except for the big "datastore" partition). That is the partition that's spanning across the two drives, and I could theoretically remove it and replace from backups later if that's causing the problem, but at 300gb of data, I'd rather not.

Any ideas I could try?

Further info:

Code:

[root@localhost ~]# fdisk -l

Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          33      265041   83  Linux
/dev/sda2              34       25529   204796620   8e  Linux LVM
/dev/sda3           25530       26040     4104607+  82  Linux swap / Solaris
/dev/sda4           26041       29687    29294527+   5  Extended
/dev/sda5           26041       29687    29294496   83  Linux

Disk /dev/sdb: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          32      257008+  83  Linux
/dev/sdb2              33        2582    20482875    b  W95 FAT32
/dev/sdb3           34454       38913    35824950    5  Extended
/dev/sdb4            2583       34453   256003807+  83  Linux
/dev/sdb5           38392       38913     4192965   82  Linux swap / Solaris
/dev/sdb6           34454       38391    31631922   83  Linux

Partition table entries are not in disk order

Disk /dev/dm-0: 10.4 GB, 10468982784 bytes
255 heads, 63 sectors/track, 1272 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/dm-1: 20.9 GB, 20971520000 bytes
255 heads, 63 sectors/track, 2549 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-1 doesn't contain a valid partition table

Disk /dev/dm-2: 10.4 GB, 10468982784 bytes
255 heads, 63 sectors/track, 1272 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-2 doesn't contain a valid partition table

Disk /dev/dm-3: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-3 doesn't contain a valid partition table

Disk /dev/dm-4: 10.4 GB, 10468982784 bytes
255 heads, 63 sectors/track, 1272 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-4 doesn't contain a valid partition table

Disk /dev/dm-5: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-5 doesn't contain a valid partition table

Disk /dev/dm-6: 332.8 GB, 332859965440 bytes
255 heads, 63 sectors/track, 40467 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-6 doesn't contain a valid partition table

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       60801   488384001    c  W95 FAT32 (LBA)

Code:

[root@localhost ~]# vgdisplay
  --- Volume group ---
  VG Name               VolGroup00
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  12
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                7
  Open LV               6
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               439.41 GB
  PE Size               32.00 MB
  Total PE              14061
  Alloc PE / Size       12441 / 388.78 GB
  Free  PE / Size       1620 / 50.62 GB
  VG UUID               YWaOKP-amoX-Zpfd-ByVW-yKl4-DpXU-JcGaHw

Code:

[root@localhost ~]# pvdisplay -v
    Scanning for physical volume names
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               VolGroup00
  PV Size               195.31 GB / not usable 28.70 MB
  Allocatable           yes
  PE Size (KByte)       32768
  Total PE              6249
  Free PE               1620
  Allocated PE          4629
  PV UUID               aAPgLz-TWOW-OMGn-s8v1-UOmC-twXq-BNKHeN

  --- Physical volume ---
  PV Name               /dev/sdb4
  VG Name               VolGroup00
  PV Size               244.14 GB / not usable 19.72 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              7812
  Free PE               0
  Allocated PE          7812
  PV UUID               20psUv-Vsf3-LnYq-pbkZ-eK1f-NGbK-OwqkF8

Code:

[root@localhost ~]# lvdisplay -v
    Finding all logical volumes
  --- Logical volume ---
  LV Name                /dev/VolGroup00/os1root
  VG Name                VolGroup00
  LV UUID                gJTD1k-1TPg-Thhk-2QWs-MyKc-k2lA-iu997Q
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                9.75 GB
  Current LE             312
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:0

  --- Logical volume ---
  LV Name                /dev/VolGroup00/os1usr
  VG Name                VolGroup00
  LV UUID                keAHAK-BDLP-PbgQ-IF5P-13QV-E04g-Jw83qR
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                19.53 GB
  Current LE             625
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:1

  --- Logical volume ---
  LV Name                /dev/VolGroup00/os1tmp
  VG Name                VolGroup00
  LV UUID                2EOCCM-ERQJ-MWAF-MPbt-ihbB-xwVd-HEaG7X
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                9.75 GB
  Current LE             312
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:2

  --- Logical volume ---
  LV Name                /dev/VolGroup00/os1home
  VG Name                VolGroup00
  LV UUID                4w8fcK-rl3n-0d1K-wyhx-M58E-KRSF-X9uObz
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                20.00 GB
  Current LE             640
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:3

  --- Logical volume ---
  LV Name                /dev/VolGroup00/os1var
  VG Name                VolGroup00
  LV UUID                B7Xov3-VChI-qt9f-Crnd-qE1z-9Irz-3eoV5Y
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                9.75 GB
  Current LE             312
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:4

  --- Logical volume ---
  LV Name                /dev/VolGroup00/os2root
  VG Name                VolGroup00
  LV UUID                uv2EHF-QAUA-dHkx-CWJa-4Lak-xMtU-wYTp08
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                10.00 GB
  Current LE             320
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:5

  --- Logical volume ---
  LV Name                /dev/VolGroup00/datastore
  VG Name                VolGroup00
  LV UUID                VxTdl1-uXOM-FLro-IWFH-88P5-9Usa-1HnwBm
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                310.00 GB
  Current LE             9920
  Segments               3
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:6

loomsen · #2 10th June 2009, 02:13 PM

Hello.

I got a similar setup, and encountered the same issue.

Here's what I did: I grabbed the bluewhite64 miniLIVE CD (which includes a VERY nice mkinitrd script.

dd it to your flash drive you want to use, tell your BIOS to boot from USB, and when bluewhite64 starts it will ask you to specify some command, or simply hit enter.

The good about bw64, it ships with a huge.s kernel.

You can use it to boot, and recognize your partitions correctly.

You should however add the options offered...
For example, if your F11 root is on sda5 ---> (in grub annotation this equals(hd0.4) <---

huge.s root=/dev/sda5 noinitrd rdinit= ro

It should provide you with a login prompt. Login as root, cdir to /boot and use
/sbin/mkinitrd --help
to get available options.

I used it, for example, with

Code:

mkinitrd -c -k 2.6.29.4-generic -L -R -m ext4:btrfs -f ext4 -r /dev/sda5

If you have the proper kernel-headers installed this will generate a initrd.gz inside your boot directory which is able to boot ext4,btrfs and whichever module you installed

Then just alter your /etc/grub.conf to use you newly generated initrd, and you should be fine

German howto utilizing a chroot

The mkinitrd script

gogalago · #3 10th June 2009, 04:26 PM

Thanks for the advice, but I think maybe you misunderstand the problem.... or maybe I misunderstand your solution!

My attempt to install from DVD is crashing before anything is written to the disk, so there are no F11 partitions yet... I have an old LVM and partitioning from Fedora 7, and I wanted to install F11 at the same time, but it crashes at the beginning of the install as soon as it tries to detect my drives.... no partitioning or installing is even close yet - I don't need to boot ext4 because I don't have any ext4 yet!

There is something about my partitioning that anaconda doesn't like...

loomsen · #4 10th June 2009, 06:21 PM

No, I got you right.

ext4 is not the point, lvm2 is.

I'd bet this is related to the new autofs feature if had to

I ran into this with different betas, opensuse, ubuntu, bluewhite64 with generic kernel and so on.

It stops (kernel panic or simple installer bug message) as soon as disks containing lvms try to be autodetected.

You could try with appending rootnoverify to your kernel line, but as I said, I'd bet your initrd simply doesn't include lvm2, md and raid modules.

After I used bw64 to create it, my initrd ONLY included ext3,ext4 and lvm support, and it stared as if it had never hesitated.

Same is for F11, appending icantbelieveitsnotbtr will load the proper initrd (including lvm, raid and btrfs support), and you'll be able to install it. *I don't tell you to use it. This option however will load the modules you need**Use at your own risk* You have probably been able to boot so far because there wasn't a autofs option yet (as far as I know. If you created it using some other installation tool, that probably generated the proper initrd back then. It's basically just a gzipped archive containing module headers)

And the mkinitrd --help tells me

Quote:

-L Add support for LVM partitions
-R Add support for RAID partitions

which probably is what you want.

SlowJet · #5 10th June 2009, 07:21 PM

I only see 1 LVM partition type 8e.
Soooooo,
when you did the vgextend orginally to the partition on the sdb,
did you
1. change partition type on sdbn to LVM - no.
2. Did you do a pvcreate /dev/sdbn before vgextend -no
S0 what is happening?
The installer is looking at the partition table and seeing Linux type 83 on sdbn
and it is going nuts.

Now loomsen may be on to something but I don't know.
I do remember reading a blurb that the partition table would NOT be used any more under some condition because the new LVB (lib, kernel, ...) doesn't use partition type any more ..., but who knows whatt the anaconda is doing?

SJ

loomsen · #6 11th June 2009, 01:20 AM

Your dmesg.

Even tells you. Warning, the partition table moved and doesn't equal the one in /proc

Thats because the logical volumes get renamed upon boot by the device mapper. so, dm and lvm2 modules should be in the ram in order to boot (or try disabling autofs or the rootnoverify option)

The difference is the autofs function. Prior your OS simply didn't mount anything not in the fstab. Now it tries to.
ls -a /

gogalago · #7 11th June 2009, 08:44 AM

Yaaaaaaaaay!

Finally sorted it out.

Will go through all the steps I tried, even though it seems it was only really the final step that solved it - I think some of the other things I discovered along the way would probably also have caused the issues.

1) Considering there seemed to be something wrong with my partition layout, I wanted to check them first... to do this I booted into rescue mode (can't check mounted volumes) - had to use an Ubuntu 9.04 disc, because the F11 DVD would crash in the same way even when trying to get into rescue... I then checked all my partitions using e2fsck. Found a few orphaned inode type errors, but the last partion gave me a major error: "Superblock invalid .... the superblock could not be read or does not describe a correct ext2 filesystem"....etc. Fortunately there was nothing important on this partition, so instead of trying to fix it, I just deleted it and re-created another in its place.

Was expecting that would have cured it, but no luck...

2) fdisk -l had always had the message "Partition table entries are not in disk order" after it, so I was never too concerned, but noticed someone else mention issues with that (sorry, can't find the thread now to credit you), and as the drive that seemed to be causing the issues didn't have the boot, or unrecoverable data on it, I thought I'd give it a try: (read below before you try this)
fdisk /dev/sdb
then 'x' for extended options
'f' to fix partition order
and then 'w' to write table and exit
(NOTE: if you try this with partitions that are being mounted you should insert some 'p' s between those steps to keep track of what's going on, because you will have to update your fstab and potentially grub to reflect new partition numbers. I didn't need this because it was only really an LVM partition that was extended onto the drive and its change from sdb4 to sdb3 doesn't seem to give LVM any problems - there is an entry in /etc/lvm/archive/volgroup00_XXXX that refers to the position, but its "just a hint" and having it wrong didn't affect anything, but should probably fix it sometime)

Anyway, system seemed ok after a reboot and could still see the sdb lvm partion fine, so tried the installer again - still crashed in the same place but different error: "Error processing drive sdb. Maybe it needs to be re-initialized. YOU WILL LOSE ALL DATA ON THIS DRIVE. Ignore drive/Re-initialize?" Wasn't sure which would result in data-loss, so I rebooted...

3) back into F7... fdisk-l looked fine fine and reported all my partitions, but gparted (and a few other tools) were very unhappy and reported the entire drive as unallocated, even though I was able to access the data and could see the partitions fine in system-config-lvm. Google turned up a lot of reading material and seems to be a longstanding problem with fdisk and gparted or libparted...

4) tried deleting and remaking an empty partition on the drive (with fdisk) in the hope that the process might write some kind of partition table gparted could use... assuming that once gparted would work, so would anaconda.... but no luck.

5) decided to try out the testdisk utility to see if it could write a valid table. It seemed to see my partitions fine, but found it a bit confusing to use, so managed to destroy my partition table entirely hehehe... so I had to use it again with a "deep search" to find the partitions I'd just used it to delete in the partition table lol. Anyway after about two hours of scanning I finally managed to get a partition table written and...

Install works fine!
(as Slowjet pointed out the lvm partition is now also marked 8e, along with order changes etc)

Thanks to all for your suggestions - whether the initrd thing would have worked is a bit beyond my understanding, so I was a bit nervous to try it, but maybe you could explain why the installer would be looking for an initrd on the hard drive, and if it does, does it just mean that mine was too old or something?

(Haven't installed yet though - got stuck trying to make new logical volumes from inside the installer, so thought I'd come back here and set up partitions first)

loomsen · #8 11th June 2009, 04:04 PM

Quote:

but maybe you could explain why the installer would be looking for an initrd on the hard drive,

OK, look.
InitRD = Initial RAM Disk

The initrd is copied into the RAM first, then your boot is initialized from there.

Look at this shot:

and maybe this:

Code:

[root@fedora ~]# lvdisplay -C
  LV       VG        Attr   LSize    Origin Snap%  Move Log Copy%  Convert
  root     vg_fedora -wi-ao   18.55G                                      
  swap     vg_fedora -wi-ao 1000.00M                                      
  LogVol00 vg_local  -wi-ao   97.66G                                      
  LogVol01 vg_local  -wi-ao   25.39G                                      
[root@fedora ~]# cat /proc/partitions 
major minor  #blocks  name

   8        0  244198584 sda
   8        1     409600 sda1
   8        2  153600000 sda2
   8        3   20480000 sda3
   8        4          1 sda4
   8        5     204800 sda5
   8        6   12287999 sda6
 253        0   19451904 dm-0
 253        1    1024000 dm-1
 253        2   26619904 dm-2
 253        3  102400000 dm-3
[root@fedora ~]# cat /proc/cmdline 
ro root=/dev/mapper/vg_fedora-root acpi_osi="Linux" rhgb vga=0x365 quiet
You have new mail in /var/spool/mail/root
[root@fedora ~]#

What you need is the capability of your initial disk to remap devices AFTER the boot was initialized. For instance, you could boot from a usb stick without any initrd, or use a floppy and it would probably work.

See?
grub -> /dev/mapper/vg_fedora-root
the kernel: (this is whats in /proc) -> /dev/dm-0

So if you include the device mapping and LVM capabilities inside an initrd, the image (loaded from RAM) will be able to map devices from RAM, not trying to remap itself (what causes the kernel panic as it tries to remap its own root)

Hmm, hope you understood this somehow ^^ if not let me know and I'll try a little more comprehensive explanation

However, this is nothing to fear. You just generate an additional initrd if you want, so nothing at all will happen to your current.
You could then add an additional line to /etc/grub.conf to your new initrd and see if it boots up. If not, well, remove it

for instance, copy your /boot to another drive and do it there.

You may use something like

Code:

dmesg | grep -B1000 initrd

To show what happens from your initrd. When the kernel becomes alive this memory is freed, so the line above will show

Quote:

docter[~] dmesg | grep initrd
Freeing initrd memory: 6706k freed

this and 1K lines before that line.

*edit*

Quote:

why the installer would be looking for an initrd

Usually a generic initrd shipped with most installers doesn't initialize LVM and RAID. Thats why ubuntu, for instance, offers an alternate installation disk. (... if you need LVM and RAID...)

Quote:

The alternate install CD allows you to perform certain specialist installations of Ubuntu. It provides for the following situations:
setting up automated deployments;
upgrading from older installations without network access;
LVM and/or RAID partitioning;

from
http://bw.releases.ubuntu.com/jaunty/

Just for explanation purposes, don't download jaunty, it sucks

gogalago · #9 11th June 2009, 04:59 PM

Thanks for the explanation... I don't know much about how the boot sequence works, so its good to find out more.

I didn't try it because I just thought that as it was an install, it would be using an initrd off the dvd (maybe its a "blank") system, and not looking for one on the hard disk... also because by the time it was crashing, it had already booted from the DVD, so I didn't know how I would be able to force it to use the one on the hard drive, because it was booting off the DVD and not using the hard drive grub either. And if it was using the one on my hard drive, it wouldn't have problems when trying to look at my drives, because my system was working fine with lvm2 and I didn't have any ext4 then... if it was trying to use an initrd from my drive, but it was too old for the stuff on the dvd, then I thought it would crash during boot, or when trying to do something with the things on the DVD, not just while trying to see my hard disk.

Anyway, thanks again, I'm glad to have it finally installed - wanted to spend these two days setting up the system, not just fighting to get it to boot!

Pluribootent · #10 28th June 2009, 07:00 PM

hi I have the same problem reported here and mentione din this bugreport https://bugzilla.redhat.com/show_bug.cgi?id=493181.

Code:

# fdisk -l

Platte /dev/sda: 160.0 GByte, 160000000000 Byte
255 Köpfe, 63 Sektoren/Spuren, 19452 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0xbd296e65

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1               1           8       64228+  de  Dell Utility
/dev/sda2   *           9        3198    25623675    7  HPFS/NTFS
/dev/sda3            3199       19060   127411515    f  W95 Erw. (LBA)
/dev/sda4           19061       19452     3148740   db  CP/M / CTOS / …
/dev/sda5            3199        5186    15968578+   b  W95 FAT32
/dev/sda6            5187        5448     2104483+  82  Linux Swap / Solaris
/dev/sda7            5449        8975    28330596   83  Linux
/dev/sda8            8976       12629    29350723+  83  Linux
/dev/sda9           12630       15832    25728066   83  Linux
/dev/sda10          15833       19060    25928878+  83  Linux

Platte /dev/sdb: 500.1 GByte, 500107862016 Byte
255 Köpfe, 63 Sektoren/Spuren, 60801 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0xcb3d087c

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdb1   *           2       60801   488376000    f  W95 Erw. (LBA)
/dev/sdb5           12775       19123    50998342+   b  W95 FAT32
/dev/sdb6               2        3194    25647709+  83  Linux
/dev/sdb7            3195        6336    25238083+  83  Linux
/dev/sdb8            6337        9542    25752163+  83  Linux
/dev/sdb9            9543       12774    25961008+  83  Linux
/dev/sdb10          19124       44186   201318516    b  W95 FAT32
/dev/sdb11          44187       60801   133459956    b  W95 FAT32

Partitionstabelleneinträge sind nicht in Platten-Reihenfolge

i dont want to lose any of the partitions as they all contain installed Linux distributions or important Data. I once started prtition magic 1 year ago and it moved sdb12 to sdb5, which made me then correct it by editing all fstab. So my problem is the order of partitions.

Is it possible to get sdb5 back to be sdb12 without losing any partitions or data ?
and how would I do that (I think id need a little tutorial) - Im not really experienced in partitiontables.

Thanx for any help at all, just want to get that upgrade to F11.

Greetings