Major problem with upgrade to F17

[AndyW]

I have just tried upgrading to F17 x86_64. CPU is AMD FX-6100, M/b Gigabyte GA-970A-DS3.

The installer failed due to lack of space on /usr. Now when I try to boot on previous F16 (kernel 3.3.7-1) or any earlier kernel I get the following after

Loading initial ramdisk...

switch_root: failed to execute /etc/init: Permission denied
     Kernel panic - not syncing: Attempted to kill init!     
     Pid: 1, comm: switch_root Not tainted 3.3.7-1.fc16.x86_64 #1

If I boot into rescue mode from the install DVD I am told "You don't have any Linux partitions", and if I go straight into the installer again it fails to recognise the previous installation.

Is the system completely borked, or is there some way I can straighten it out at least to the point I can increase the /usr LV size?

Thanks,
Andrew

[tashirosgt]

Originally Posted by AndyW

If I boot into rescue mode from the install DVD I am told "You don't have any Linux partitions",

I think you should boot something that will let you use a terminal or a console and do some command line things to investigate the state of your hard drive (like fdisk -l ). I'm not familiar with the rescue mode of the install DVD. Will it let you get to a terminal? The LiveCD will.

[george_toolan]

Try to boot a Fedora 16 or Fedora 17 live cd.

[AndyW]

I can boot into F16 KDE LiveCB with no problem.

It looks like the issue is with LVM. While /boot is on a standard partition, all the other storage is on LVM. The O/S is installed on a 32 GB OCZ SSD with separate LVs for /, /var, /usr and /usr/local, while on a 1 TB Samsung HD there are LVs for /home, /tmp and swap. Using vgdisplay and lvdisplay I can see that all the VGs and LVs appear to be there intact, and can mount them in LiveCD.

It looks like something in the F17 install (not sure whether it is related to the upgrade failure due to lack of space on /usr or not) has caused the LVM storage to no longer be recognised at startup. Red Hat Bugzilla #819604 (https://bugzilla.redhat.com/show_bug.cgi?id=819604) looks like it may be related. I have been using this partitioning scheme since FC9 so it has been through plenty of previous upgrades without any problems.

Grateful for any further suggestions...

Andrew

[tashirosgt]

My uninformed suggestion is that you boot with the FC 17 liveCd and use the vgchange command to activate the logical volume group(s) and then try to install from the liveCd. Perhaps the installation DVD would give you a similar option. I haven't used the installation DVD.

( I don't use LVM anymore. I see no point for it on the typical home computer. Another obvious suggestion is to repartition your drives to be non-LVM.)

[AndyW]

I have fixed the kernel panic preventing booting...

Although /usr-move failed due to lack of space, it looks like it had moved /sbin and replaced it with a symlink to /usr/sbin. When the bootloader tried to switch to the "real" init it couldn't find it as /usr wasn't mounted yet. When I added

rd.lvm.lv=VolGroup00/LogVol02

(this is the LV where /usr resides) to the grub command line in /boot/grub2/grub.cfg, it booted without problem. I can't find much info on grub / grub2 syntax but this appears to be the way to tell it to temporarily mount, or at least be able to read, a LVM filesystem. When resources make statements like

...must be mounted by the initramfs during early boot

this is presumably how it happens.

However...when I now run the FC17 x86_64 upgrade DVD, it still fails to recognise the existing intallation. I am aware that I wil have to resize LVs and FSes in order for /usr-move to complete, but it doesn't get as far as even starting that. And LVM can't be a problem per se, as the original upgrade attempt started OK with exactly the same storage config as I still have.

Any ideas on why it is not seeing the existing FC16 install?

UPDATE:
Adding

rd.lvm.lv=VolGroup00/LogVol01 rd.lvm.lv=VolGroup00/LogVol03

which is where /var and /usr/local reside (i.e. letting the Anaconda installer "see" all of he OS install) doesn't make a difference. I also have

insmod lvm

in grub.cfg, to no effect.