Description of problem: Version-Release number of selected component (if applicable): f7t3 rescue i386 iso How reproducible: on that machine {hp omnibook 4150}, yes. Seems to be to do with the lvm. Steps to Reproduce: 1. Using f7t3 rescue iso 2. ftp server 3. upgrade fc6{updated 2007-03-31} Actual results: Error Error mounting device VolGroup00/LogVolhome as /home: No such file or directory {no fullstop} This most likely means this partition has not been formatted. {very incorrect!!!!} Press OK to reboot your system. [ OK ] Expected results: user happily testing f7t3 :) Additional info: - The names for the lvm's where chosen manually {to represent where they are mounted rather than the default 00/01 etc. - Machine has an || ide disk, so the /dev/sdX issue could be coming in to play, although /boot /bootbak and / are mounted without problem. - attempting to manually mount failed.
Created attachment 151491 [details] results of ls, mount, lvdisplay, in attempting to diagnose bug.
With the same ftp boot, same issue occurred. Letting it do the default graphical install/upgrade, then selecting to upgrade the FC6 on sda3 also failed. Same message but in a graphical dialog.
This isn't obvious anywhere, but Fedora 7 test bugs should be filed against the "devel" version.
Could you please attach your complete fstab from the installed system and a copy of the /tmp/anaconda.log to this bug report? Thanks.
Created attachment 153198 [details] /etc/fstab from existing fc6 install I have retested with rescue cd form 2007-04-20 -rw-r--r-- 1 root root 103391232 Apr 20 08:31 FC-development-i386-rescuecd.iso -rw-r--r-- 1 root root 5778351 Apr 20 08:29 initrd.img -rw-r--r-- 1 root root 270 Apr 20 08:29 README -rw-r--r-- 1 root root 75 Apr 20 08:31 SHA1SUM -rw-r--r-- 1 root root 1919604 Apr 20 08:29 vmlinuz [davidt@davidtdesktop fedora_development]$ sha1sum * b4dc9c2a042bd4b4b1f4483e568d191e36bd69cc FC-development-i386-rescuecd.iso db8fc280e04039a3a5eeb48155f1dba91bffe71b initrd.img 637780241779f3fa07c23c5bc0a6d06cf2772ca2 README 212205943402ad2103b576de623cfb29c9250cf6 SHA1SUM f4829256008a38188f9d6469a53250a15e69a279 vmlinuz [davidt@davidtdesktop fedora_development]$ sha1sum -c SHA1SUM FC-development-i386-rescuecd.iso: OK Unfortunately, I can't get past the Retrieving or trying to retrieve stage2 image screen (even though it is on the rescue cd I'm booting from) (eg after 20 mins, normally would take 7). The logs are from the fc6 install.
The install is unable to proceed to the point where a useful shell is on vt2. Is there some way I can get the installers /tmp/anaconda ? In case it is useful, # fdisk -l Disk /dev/hda: 20.0 GB, 20003880960 bytes 240 heads, 63 sectors/track, 2584 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 4 30208+ 83 Linux /dev/hda2 2581 2584 30240 83 Linux /dev/hda3 5 559 4195800 83 Linux /dev/hda4 560 2580 15278760 5 Extended /dev/hda5 560 698 1050808+ 82 Linux swap / Solaris /dev/hda6 699 2580 14227888+ 8e Linux LVM Partition table entries are not in disk order
I believe FTP installs are known to be broken right now (which I'm setting up to test). Is it possible for you to test with an HTTP install instead and try to get the /tmp/anaconda.log file? You won't be able to grab it until you get a useful shell on tty2.
Created attachment 153261 [details] anaconda loglevel=debug Retested with: ftp install {now set up local mirror with initial needed bits} -rw-r--r-- 1 root root 102508544 Apr 22 08:42 FC-development-i386-rescuecd.iso -rw-r--r-- 1 root root 5780373 Apr 22 08:40 initrd.img -rw-r--r-- 1 root root 270 Apr 22 08:40 README -rw-r--r-- 1 root root 75 Apr 22 08:42 SHA1SUM -rw-r--r-- 1 root root 1919604 Apr 22 08:40 vmlinuz ./ iso boots - select ftp ./ installer uses local stage2.img ./ ide disk is detected, and install / upgrade (Fedora Core 6 [/dev/sda3] choice appears - select upgrade x Error: Error mounting device VolGroup00/LogVolhome: No such file or directory {note : missing fullstop after directory!} Devices in /etc/fstab should be specified by label, not by device name. Press OK to reboot your system. OK === since anaconda has changed a little, I am recapturing vt2 info as next attach.
Created attachment 153262 [details] various bits from the anaconda shell (dmesg, ls /dev ...) Note: when I ran vgdisplay -v, I see the volumes (see attach), but the >x.txt doesn't capture the following messages that appear on the screen: # vgdisplay -v Finding all volume groups Finding volume group "VolGroup00" Fixing up missing format1 size (13.57 GB) for PV /dev/sda6 --- Volume Group --- etc I have never used the tools before, so I don't know if that is ~normal. However, the same command on a fc6 updated machine with lv's suggests this is a furphy: # vgdisplay -v Finding all volume groups Finding volume group "VolGroup00" Fixing up missing format1 size (103.74 GB) for PV /dev/hda3 Fixing up missing format1 size (25.59 GB) for PV /dev/hdb2 Fixing up missing format1 size (103.74 GB) for PV /dev/hda3 Fixing up missing format1 size (25.59 GB) for PV /dev/hdb2 --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 2
With F7t4, the installer has the same problem with being unable to use the pre-existing logical volume for /home partition. Comment 8 shows the symptom has changed from the original: "This most likely means this partition has not been formatted" To a warning: "Devices in /etc/fstab should be specified by label, not by device name. Press OK to reboot your system." Which is better than suggesting to the upgrading user that they should format the machine! Given that FC5/6 installs using logical volumes by default, I would imagine this issue will be widespread for upgrading users.
Argh, more LVM activate/deactivate weirdness. This should be fixed in the next build of anaconda.
*** Bug 237565 has been marked as a duplicate of this bug. ***
Retested with: 552905763371fee09fb6bdfa5b1f2015693b93f6 FC-development-i386-rescuecd.iso 2007-05-02 The installer now mounts the lvm /home and /infrastructure volumes OK, and once selected proceeds to upgrading the machine. The machine only has 384M memory as well, so it is a bit of a test.
With that amount of memory, the install is probably not going to work (see bug 238266).