Description of problem: While doing a netinstall trying to install rawhide from today on a shared hd together with F11 by using a custom layout, but seems Anaconda both fails to activate the new LVM settings and uses wrong LVM partitions. Version-Release number of selected component (if applicable): anaconda-12.32-1.fc12.x86_64.rpm (i think.. what's found on the installation repository) How reproducible: Always Steps to Reproduce: 0. On an existing F11 install, make sure there is some free space in your LVM and a suitable free main partition to be used as /boot 1. Start a net install (probably the same by other install methods as well) 2. Select custom partition layout 3. Select the right boot partition and assign it to /boot 4. Add a new LVM volume for / in the existing LVM set 4. Next to try to start the installation Actual results: Ends up not writing the new LVM volume for / to the volumeset, and mounts another existing volume as /mnt/sysimage and then tries to fsck yet another volume which was not set to be mounted. Expected results: Should create the new logical volume, format it and start install.. Should NOT touch other volumes in the LVM volumeset. Additional info: Has worked fine for me in many earlier installs of F10 and F11 (alha, beta, release). I rebooted immediately when seeing this strangeness. Would be rather bad if it overwrote those other existing LVM volumes..
Note: To add aa new LVM volume one has to select one of the existing LVM volumes and click on edit. This opens the LVM volume window.
Same result if I first create the new LVM volume from F11, reboots to a netboot install and then selects that empty & unformatted volume to be formatted as ext4 and mounted on / This time I let it continue and seems it MAY eventually get things right, just doing other crap first which is not expected. Seems it tries to resize the other LVM partition I mentioned even if has not been resized in the partition layout (and installation logs says eventually "xxxx is already NNNN blocks large"). That volume has earlier been resized a number of times both up and down. It still has some other lvm volume mounted as /mnt/sysimage when coming to the grub configuration screen. But will let it continue anyway as the data found there is not important to me. Klicking next on the grub configuraiton screen fails with a backtrace, ending with "NameError: global name 'sys' is not defined".
Can you replicate the failure? If so, please attach the install logs and the full text of the traceback to this bug report. The logs of interest are: /tmp/anaconda.log /tmp/storage.log /tmp/program.log /tmp/syslog Thanks. It would be even better if you could try to replicate using a more recent tree/repository instead, like the F12 beta that was just released.
Have tried the Alpha installer and that behaved a bit strange with the volumes as well during the early phases of the install, but eventually everything ended up where it should- Will try the beta shortly.
Running the beta installer now, and it still messes with other LVM volumes not selecte as part of the install, and during that time it has yet another LVM volume mounted as /mnt/sysroot.. WIll let the install continue. The volume mounted as /mnt/sysroot is not important to me. And it failed with the same 'sys' error as before..
Created attachment 365588 [details] anaconda.log
Created attachment 365589 [details] anaconda traceback
Created attachment 365590 [details] anaconda-yum.conf
Created attachment 365591 [details] program.log
Created attachment 365592 [details] storage.log
Created attachment 365593 [details] syslog
Details on the install: Already installed F11 + Windows dual boot system, with a somewhat messy LVM setup due to a Windows recovery partition later included in the LVM physical volume set and another Windows partition resized to make more room for linux data.. In the LMV set there is a number of logical volumes for various kinds of data, plus some for root filesystems. In this install I deleted the already existing f12 logical volume and created a new one of 15GB in size, but don't think that matters given th results earlier.
*** Bug 530174 has been marked as a duplicate of this bug. ***
Oh, there is at least one difference with the beta installer compared to the rawhide installed used some weeks ago, it did manage to write the LVM volume configuration this time.
So, aside from the yum traceback in bug 530174, the problem is that anaconda is scheduling bogus no-op resize operations for some lvs. Otherwise things are behaving as expected. Is this correct?
Bogus resize of a non-selected LVM volume, plus that another non-selected LVM volume is mounted as /mnt/sysimage at the time of the traceback, not the selected system root. Can't say if thinkgs otherwise are behaving as expected as anaconda crashes with the indicated traceback at the grub configuration screen.
Some more data points The filesystem it tries to make a bogus resize of is ext2 while all other are ext3. The installer is still crashing with a traceback using rawhide dated yesterday (file date of the pxeboot images on the selected mirror 23 hours from now). yum-3.2.25-1.fc12.noarch.rpm anaconda-12.38-1.fc12.x86_64.rpm This traceback is different, now saying "YumBaseError: Error: rpmdb open failed".
New traceback in Bug #530293
Getting further.. actually installing now after giving anaconda a bit of a helping hand.. manually umounted /mnt/sysimage as early as possible when seeing it wrongly mounted. iirc this was even before the custom partitioning screen. then getting to the the grub configuration screen and I manually remounted things so that the right root fs is mounted as /mnt/sysimage. The fs was freshly formatted by anaconda, just not mounted.. To summarise there seems to be two issues: 1. Mounts my debian etch-amd64 filesystem as /mnt/sysimage instead of the selected f12 filesystem. This filesystem gets mounted there quite early in the process while scanning for existing linux installs (findrootparts) 2. For some reason it thinks my ext2 formatted "DVD" filesystem needs a resize, even when not touching that filesystem as part of the partitioning. When exiting to the shell in step 2 I did not have any filesystem mounted on /mnt/sysimage, just the dev, proc etc stuff mounted below it. The only two filesystems selected in the partition layout was f12 format as ext4, mountpoint / sda3 keep, mountpoint /boot and the swap lvm volume which gets automatically activated.
Anaconda will mount lots of things at /mnt/sysimage while scanning the existing storage configuration -- we are looking for existing installations that may be upgradable. We simply mount the filesystem read-only, check for an upgradable root filesystem, then unmount it. Based on the log from comment 7 it looks as though we never unmount the debian volume after checking to see if it contains a fedora installation. If you are on tty2 mounting and/or unmounting things during this process, please stop (and let me know). I have never seen this happen before. I'm looking now for possibly causes.
Yes, it for some reason forgets to umount the debian-etch filesystem while scanning the system. Looking at the log it also seems it then fails to scan any filesystems after this (there is 4 more to scan, including a Fedora 11 root). And as already commented, if I manually fix up the /mnt/sysimage mounts from tty2 before continuing at the grub configuration screen then the install succeeds fine. Relevant snippet from the last rawhide anaconda trace in Bug #530293: 10:15:55 DEBUG : LVMLogicalVolumeDevice.setup: HenrikLaptop-data ; status: False ; 10:15:55 DEBUG : LVMVolumeGroupDevice.setup: HenrikLaptop ; status: True ; 10:15:56 DEBUG : isys.py:mount()- going to mount /dev/mapper/HenrikLaptop-data on /mnt/sysimage as ext3 with options ro 10:15:56 DEBUG : LVMLogicalVolumeDevice.teardown: HenrikLaptop-data ; status: True ; 10:15:56 DEBUG : isys.py:umount()- going to unmount /mnt/sysimage, removeDir = False 10:15:56 DEBUG : LVMVolumeGroupDevice.teardown: HenrikLaptop ; status: True ; [some other stuff] 10:15:56 DEBUG : LVMLogicalVolumeDevice.setup: HenrikLaptop-etch-amd64 ; status: False ; 10:15:56 DEBUG : LVMVolumeGroupDevice.setup: HenrikLaptop ; status: True ; 10:15:56 DEBUG : isys.py:mount()- going to mount /dev/mapper/HenrikLaptop-etch--amd64 on /mnt/sysimage as ext3 with options ro 10:15:56 DEBUG : LVMLogicalVolumeDevice.teardown: HenrikLaptop-etch-amd64 ; status: False ; 10:15:56 DEBUG : LVMVolumeGroupDevice.teardown: HenrikLaptop ; status: True ; [note: no umount, and VolumeDevice teardown status False] 10:15:56 DEBUG : LVMLogicalVolumeDevice.setup: HenrikLaptop-fc11 ; status: False ; 10:15:56 DEBUG : LVMVolumeGroupDevice.setup: HenrikLaptop ; status: True ; 10:15:57 DEBUG : LVMLogicalVolumeDevice.teardown: HenrikLaptop-fc11 ; status: True ; [note: no mount or umount] [followed by similar for the other logical volumes after fc11, ] Just tell me what you want me to do to get more info on what is going wrong and I'll rerun the installation. Takes only a minute or two. It's my travel notebook and is available for tests whenever I am at my main stationary computer.
using the noupgrade command line option works around the problem, at least unless one actually wants to upgrade. as already mentioned it never figures out I have an upgradeable F11 installation on the same system, due to the etch-amd64 volume blocking /mnt/sysimage
Been debugging anaconda a bit to find the LVM mounting issue, and it's related to the use of - in the lvm volume name "etch-amd64". device.name == "HenrikLaptop-etch-amd64" map.name = "HenrikLaptop-etch--amd64" note the double -- in map.name. This makes device.status evaluate to false, causing umount to be skipped. storage/devices.py line 1343 if map.name == self.name: Note: The /dev/mapper name is also with double -- This error is from storage/devices.py line 2054 return "%s-%s" % (self.vg.name, self._name) both vg name & device name needs to be - escaped for this to work, replacing any - with --. return "%s-%s" % (self.vg.name.replace("-","--"), self._name.replace("-","--")) Related to this, shouldn't the umount condition be device.format.status, not device.status? Not that this really mattes, more of a coding style question.. if self.format.status: self.format.teardown() instead of if self.status and self.format.exists: self.format.teardown()
Created attachment 365995 [details] Propoased patch for LVM device name fixup
With this patch the install works like expected.
Note that on affected systems the only way to correctly install F12 (short of hand-patching the mounts) is to use the noupgrade boot option. There may also be a risk that the F12 install gets done into the wrong volume as /mnt/sysimage at time of install is the first encountered troublesome LVM volume instead of selected root. In my installs anaconda crashes with a backtrace (Bug #520044), but I do not think it's guaranteed that anaconda will crash like this, may depend on filesystem type or other state of that filesystem..
The other bogus ext2 partition resize has been split to Bug #530782 as it is an unrelated issue of low priority.
Any progress on getting this patch reviewed? (Comment #24) It's a blocker for upgrading to F-12 on affected systems.
Thanks for the patch. I have taken a slightly different approach with my own patch. If I give you either a patch/diff or an updates.img, will you be able to verify that things work as expected?
Sure. Just send what you want me to test. A diff is fine. Already know how to make an update image to test things quickly.
Created attachment 367210 [details] patch to handle dashes in vg/lv names This patch is against anaconda-12.41, but it will probably apply fine to anaconda-12.3x as well.
Seems to work fine. Tested with 12.41 (what's in the rawhide mirror nearby). Without the patch the behaviour was as before, etch-amd64 gets mounted on /mnt/sysimage, and installer does not figure out that there is Fedora already installed. With the patch /mnt/sysimage is properly umounted, and the installer does find that Fedora is already installed and may be upgraded. As a twist I selected to upgrade my existing F12 installation instead of a new install this time (already started using my F12 install done earlier), and seems to run fine. Not finished yet, but hasn't crashed either.
this has been tagged as an F12Blocker. we really need all blockers fixed by Wednesday, which means we need a build with this fixed to be submitted and tagged today or tomorrow really. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Fix will be in anaconda-12.43.
henrik: 12.43 has been tagged for tomorrow's Rawhide; if you could please test with that when it lands that'd be great. or, if you can test this from a live CD, you can test it right away - boot any live CD, update to anaconda 12.43 from Koji http://koji.fedoraproject.org/koji/buildinfo?buildID=139634 , then run the install and test it. thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I tested it both on anaconda 12.42 and 12.43 today, the steps are the same as followed: First, I created a f11 existing machine with free spaces in LVM volume. Then, I installed f12, adding new volume in existing LVM for / and ext4 outside LVM for /boot. The whole installation ran normally and nothing wrong happened. I'm not sure if I did exactly like the reporter so it's better Henrik can retest it.
I will retest as soon as I have an install.img with 12.43 in it. 12.42 should not work I think. 12.41 definitely does not work. The key item to trigger this problem is to have a lvm volume with - in it's name. Maybe also needs to be sorted before your Fedora root volumes but probably not.
I created several logical volumes with a '-' character in the name using F-11. sh-4.0# lvm lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert lv_root vg_test81 -wi--- 12.86G lv_swap vg_test81 -wi--- 1.94G test-logical vg_test81 -wi-ao 2.00G test-logical-2-- vg_test81 -wi-a- 1.00G I have booted into an earlier rawhide image that used anaconda-12.42. When selecting "Upgrade" I observed the failure. "An error occured mounting device //dev as /dev:mount failed: (30, 'Read-only file system'). This is a fatal error and the install cannot continue." Testing with anaconda-12.43, I'm not able to reproduce the problem. I'm currently performing an upgrade on from F-11 -> F-12 (anaconda-12.43) on the system with logical volume names containing a '-'.
just trying to think of the obvious things that could still go wrong in such a situation...dave, what if the LVM had *two* (mor more) - in its name? my--cool--lvm or something like that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #39) > just trying to think of the obvious things that could still go wrong in such a > situation...dave, what if the LVM had *two* (mor more) - in its name? > my--cool--lvm or something like that. Shouldn't matter. We replace each instance of '-' with '--' in the vg name and the lv name separately, then join the two with a single '-'.
(In reply to comment #40) > (In reply to comment #39) > > just trying to think of the obvious things that could still go wrong in such a > > situation...dave, what if the LVM had *two* (mor more) - in its name? > > my--cool--lvm or something like that. > > Shouldn't matter. We replace each instance of '-' with '--' in the vg name and > the lv name separately, then join the two with a single '-'. I tested that scenario above, see comment#38. Didn't observe any failures. test-logical-2-- vg_test81 -wi-a- 1.00G
ah, missed that bit. given that henrik tested the patch that was eventually applied, and james has tested the actual anaconda build, shall we just close this now? it seems a pretty sure thing that it's fixed. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #42) > ah, missed that bit. No worries, I think that should be sufficient, but feel free to send out more test ideas. > given that henrik tested the patch that was eventually applied, and james has > tested the actual anaconda build, shall we just close this now? it seems a > pretty sure thing that it's fixed. Yeah I feel good about this one. However, I'm happy to leave this open one more day awaiting feedback from Henrik.
12.43 has now hit the local rawhide mirror and confirmed working fine for me as well, as expected.
excellent! thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers