Bug 527302 - Installation fails if an existing LVM volume or group have - in their name
Installation fails if an existing LVM volume or group have - in their name
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F12AnacondaBlocker
  Show dependency treegraph
 
Reported: 2009-10-05 16:54 EDT by Henrik Nordström
Modified: 2009-11-04 15:53 EST (History)
4 users (show)

See Also:
Fixed In Version: anaconda-12.43
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 530782 (view as bug list)
Environment:
Last Closed: 2009-11-04 15:53:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log (109.67 KB, text/plain)
2009-10-21 15:47 EDT, Henrik Nordström
no flags Details
anaconda traceback (311.28 KB, text/plain)
2009-10-21 15:48 EDT, Henrik Nordström
no flags Details
anaconda-yum.conf (345 bytes, application/octet-stream)
2009-10-21 15:48 EDT, Henrik Nordström
no flags Details
program.log (46.50 KB, text/plain)
2009-10-21 15:48 EDT, Henrik Nordström
no flags Details
storage.log (89.77 KB, application/octet-stream)
2009-10-21 15:49 EDT, Henrik Nordström
no flags Details
syslog (51.19 KB, text/plain)
2009-10-21 15:49 EDT, Henrik Nordström
no flags Details
Propoased patch for LVM device name fixup (514 bytes, patch)
2009-10-24 20:37 EDT, Henrik Nordström
no flags Details | Diff
patch to handle dashes in vg/lv names (2.76 KB, patch)
2009-11-02 16:24 EST, David Lehman
no flags Details | Diff

  None (edit)
Description Henrik Nordström 2009-10-05 16:54:58 EDT
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..
Comment 1 Henrik Nordström 2009-10-05 17:09:34 EDT
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.
Comment 2 Henrik Nordström 2009-10-05 17:22:34 EDT
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".
Comment 3 David Lehman 2009-10-21 12:26:43 EDT
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.
Comment 4 Henrik Nordström 2009-10-21 14:48:49 EDT
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.
Comment 5 Henrik Nordström 2009-10-21 15:45:57 EDT
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..
Comment 6 Henrik Nordström 2009-10-21 15:47:14 EDT
Created attachment 365588 [details]
anaconda.log
Comment 7 Henrik Nordström 2009-10-21 15:48:05 EDT
Created attachment 365589 [details]
anaconda traceback
Comment 8 Henrik Nordström 2009-10-21 15:48:29 EDT
Created attachment 365590 [details]
anaconda-yum.conf
Comment 9 Henrik Nordström 2009-10-21 15:48:55 EDT
Created attachment 365591 [details]
program.log
Comment 10 Henrik Nordström 2009-10-21 15:49:17 EDT
Created attachment 365592 [details]
storage.log
Comment 11 Henrik Nordström 2009-10-21 15:49:40 EDT
Created attachment 365593 [details]
syslog
Comment 12 Henrik Nordström 2009-10-21 15:58:59 EDT
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.
Comment 13 Henrik Nordström 2009-10-21 16:03:59 EDT
*** Bug 530174 has been marked as a duplicate of this bug. ***
Comment 14 Henrik Nordström 2009-10-21 16:46:07 EDT
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.
Comment 15 David Lehman 2009-10-22 00:38:17 EDT
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?
Comment 16 Henrik Nordström 2009-10-22 03:51:56 EDT
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.
Comment 17 Henrik Nordström 2009-10-22 04:28:29 EDT
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".
Comment 18 Henrik Nordström 2009-10-22 04:30:24 EDT
New traceback in Bug #530293
Comment 19 Henrik Nordström 2009-10-22 05:12:43 EDT
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.
Comment 20 David Lehman 2009-10-22 09:17:03 EDT
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.
Comment 21 Henrik Nordström 2009-10-22 17:00:00 EDT
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.
Comment 22 Henrik Nordström 2009-10-24 16:36:05 EDT
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
Comment 23 Henrik Nordström 2009-10-24 20:26:11 EDT
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()
Comment 24 Henrik Nordström 2009-10-24 20:37:04 EDT
Created attachment 365995 [details]
Propoased patch for LVM device name fixup
Comment 25 Henrik Nordström 2009-10-24 20:37:28 EDT
With this patch the install works like expected.
Comment 26 Henrik Nordström 2009-10-24 20:53:06 EDT
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..
Comment 27 Henrik Nordström 2009-10-24 20:54:14 EDT
The other bogus ext2 partition resize has been split to Bug #530782 as it is an unrelated issue of low priority.
Comment 28 Henrik Nordström 2009-10-31 18:31:43 EDT
Any progress on getting this patch reviewed? (Comment #24) It's a blocker for upgrading to F-12 on affected systems.
Comment 29 David Lehman 2009-11-02 12:47:04 EST
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?
Comment 30 Henrik Nordström 2009-11-02 15:54:52 EST
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.
Comment 31 David Lehman 2009-11-02 16:24:57 EST
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.
Comment 32 Henrik Nordström 2009-11-02 17:13:53 EST
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.
Comment 33 Adam Williamson 2009-11-02 19:02:21 EST
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
Comment 34 David Lehman 2009-11-03 12:15:26 EST
Fix will be in anaconda-12.43.
Comment 35 Adam Williamson 2009-11-03 21:01:17 EST
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
Comment 36 He Rui 2009-11-04 05:12:37 EST
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.
Comment 37 Henrik Nordström 2009-11-04 06:33:50 EST
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.
Comment 38 James Laska 2009-11-04 10:20:06 EST
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 '-'.
Comment 39 Adam Williamson 2009-11-04 11:21:04 EST
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
Comment 40 David Lehman 2009-11-04 11:27:28 EST
(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 '-'.
Comment 41 James Laska 2009-11-04 11:29:27 EST
(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
Comment 42 Adam Williamson 2009-11-04 12:11:29 EST
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
Comment 43 James Laska 2009-11-04 15:28:19 EST
(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.
Comment 44 Henrik Nordström 2009-11-04 15:46:25 EST
12.43 has now hit the local rawhide mirror and confirmed working fine for me as well, as expected.
Comment 45 Adam Williamson 2009-11-04 15:53:49 EST
excellent! thanks.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Note You need to log in before you can comment on or make changes to this bug.