Bug 498408 - findExistingRootDevices teardown(recursive=True) fails with lvm over mdraid
findExistingRootDevices teardown(recursive=True) fails with lvm over mdraid
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity high
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
: 498479 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-30 07:15 EDT by Nick P G Smith
Modified: 2011-02-24 09:40 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-24 09:40:06 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 dump (114.03 KB, text/plain)
2009-04-30 07:15 EDT, Nick P G Smith
no flags Details
F12Beta x86_64 anaconda traceback (159.75 KB, text/plain)
2009-10-21 22:23 EDT, James Twyford
no flags Details

  None (edit)
Description Nick P G Smith 2009-04-30 07:15:29 EDT
Created attachment 341906 [details]
Anaconda dump

Description of problem:
Anaconda crashed at the end of partitioning. After a reboot, the installer crashes even before it gets to the partioning UI.

How reproducible:
Every time

Steps to Reproduce:
1. Partioned:
- /boot as ext3 on an md RAID using partitions on sda and sdb
- swap using partitions on sda and sdb
- LVM volume on an md RAID using partitions on sda and sdb
- / LV as ext4 on the LVM volume group
- /var/www LV as ext4 on the LVM volume group

2. Anaconda crashes compaining about /var/www (something about nested volumes, sorry I didn't make a note)

3. Reboot - now fails (see attachment) before the partitioning UI
  
Expected results:
To install and use Fedora :-)
Comment 1 Chris Lumens 2009-04-30 13:12:03 EDT
*** Bug 498479 has been marked as a duplicate of this bug. ***
Comment 2 Ray Todd Stevens 2009-04-30 13:17:46 EDT
This is probably the same bug as 495078


However, there are a few differences, and since the trace back created a new
bug report I thought that I would leave it the same.

It is a different machine, but the same general configuration.

This is with a fc11 beta install and a fc11 preview as the disk being used to
run the new install.  That is I had tried to install with fc11 beta and failed,
I will be trying go back to a fc9 disk and erasing everything to try a new
install.

The configuration I am trying to get to is boot and swap on disk sba   The a
software raid partition on sba and sdb with a raid 1 volume as root.    The
beta software says it loaded that way.    I can now do a rescue boot with the
preview.   The beta will not even do a rescue boot.    When I do a rescue boot
the configuration I find has no relationship to what I entered.
Comment 3 Bug Zapper 2009-06-09 10:52:20 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Paolo Penzo 2009-06-18 09:35:29 EDT
I got the same issue with this kickstart:
clearpart --all --drives=sda,sdb --initlabel

zerombr yes
clearpart --all --initlabel --drives=sda,sdb
part swap --size 512 --ondisk sda --grow --maxsize 1024
part swap --size 512 --ondisk sdb --grow --maxsize 1024

part raid.01 --size 100 --ondisk sda --asprimary
part raid.02 --size 100 --ondisk sdb --asprimary

raid /boot --level 1 --device md0 raid.01 raid.02 --fstype ext3

part raid.11 --size 1 --grow --ondisk sda
part raid.12 --size 1 --grow --ondisk sdb

raid pv.1 --level=1 --device md1 raid.11 raid.12
volgroup sysvg pv.1 --pesize=32768
logvol / --vgname=sysvg --size=10240 --name=lvrootfs --grow --maxsize=40960 --fstype=ext4
logvol /var/log --vgname=sysvg --size=4096 --name=lvlog --fstype=ext4

Anaconda complains about the free space on the vg(last message is: DEBUG vg sysvg has 0 MB free). It looks like it's not possible to create VGs on top of MD devices via kickstart, however it is possible to do it using the interactive installation. No trobles arises when VGs are created onto disk partitions.
Comment 5 Ray Todd Stevens 2009-07-06 16:58:22 EDT
OK I got this error with preupgrade and was able to file a bug report through the automated system.   Then that bug was reported as being a duplicate of this one.   

I decided to try the latest production fc11 disk and do a upgrade.  I get more or less the same thing.  The error status on all of the ctrl alt screens is the same BUT!!!!!

Now when I try and file a report it will not let me.   As soon as I click on filing a report (save) it puts up the data entry screen for in your bugzilla login information, BUT THEN it pops up a screen that says "finding storage devices"   Now I can still switch to the other screens.   But the mouse cursor is the dreaded watch.   The watch will move,, but you can't do anything.

Is there anything we can get doing to allow for this bug to be fixed quicker?
Comment 6 Ray Todd Stevens 2009-07-06 17:00:49 EDT
This bug seems to effect all machines which are using the /dev/md0 driver as a RAID 1.   One would think this would be a high priority not a low one.
Comment 7 Ray Todd Stevens 2009-07-09 17:17:14 EDT
This time apparently preupgrade is letting me upgrade.   The cdroms still will not.
Comment 8 Joel Andres Granados 2009-09-02 08:17:38 EDT
Does this still happen with current anaconda (12-18).  pls test with rawhide.
Comment 9 Ray Todd Stevens 2009-09-02 09:14:10 EDT
Everything right now at all eight offices has been upgraded or the data stored off and then reformated and loaded fresh.   Even that doesn't work very well.   I have several active bug reports on that where RAID 1 and RAID 5 don't seem to work right and I am left with an unbootable system.   I have gotten so I can then manally make it bootable through.

I will be on travel for a week, and will try and build up a test system and check it next week.

Are you aiming at the upgrade problem, the fresh install problem, or the error message and error handling problem having gone away?????
Comment 10 James Twyford 2009-10-21 22:23:33 EDT
Created attachment 365641 [details]
F12Beta x86_64 anaconda traceback

Getting this error trying to install f12b-x86_64.
Smolt profile: http://www.smolts.org/client/show/pub_aa591de8-132e-4232-8f45-42556d142513
Comment 11 Ray Todd Stevens 2009-12-09 09:46:35 EST
I have to second that this is still present in fedora 12.  Now I have gotten so good at getting around it as it happens so often that I kind of forgot about this bug report.   Or at least in the end this bug was dealt with by doing an install, which left/leaves you with a completely unbootable system about 50% of the time.   It hangs hangs right at the start of the boot process.   ALL you have to do then is rescue boot and do a reinstall of the grub system and you are off and going.

This is doable, but really annoying, and probably not in the skill set of some people using Fedora.
Comment 12 Ray Todd Stevens 2009-12-09 10:19:12 EST
PS  see in the new title "fails with lvm over mdraid".   If it helps the machines I am running this on that are giving me problems are in fact all using mdraid.   I experience this with both RAID1 and RAID5.   But I am not using lvm.

For me it seems to relate to systems that have undergone multiple upgrades through several consecutive versions of Fedora.
Comment 13 David Lehman 2009-12-09 13:18:02 EST
The failure in comment 10 is at least partly related to logical volumes with '-' in their names (bug 527302) which was fixed in anaconda-12.43-1 and is included in F12.

Ray, if you'd like to attach an F12 traceback I can try to track down what's happening for you.
Comment 14 Ray Todd Stevens 2009-12-09 14:43:06 EST
I am not sure exactly what it is that you want?

Right now I am not actually getting any crashes or dumps during the installation or in this case upgrades.   At this point it indeed may be a different bug.   It certainly presents differently.

What specifically is happening is to upgrade, or in a couple cases install fedora, with a mdraid configuration.   Usually something with both a mdraid md0 for /boot and a md1 for / both either raid1 or raid5.  This is also on machines for which I reported this bug earlier.  On the systems where I do an install instead of a upgrade it is still an upgrade as this is on a system with an existing installation, but where instead of the upgrade I select to do a complete scratch install.

Everything says that it has completed successfully  I get to the screen where you kick on a button to reboot after if applicable you have removed the cdrom.   Everything looks perfect, the bios screen comes up, and then at the point where you normally would see the the line that says that it is about to boot a specific kernel if you don't do anything, and where you could then press a key and edit to boot parameters, but instead of that you have a black screen with the cursor blinking in the top left of the screen.

At this point if you rescue boot it says everything is cool.   If you then reinstall the grub loaded using grub-install you are up and going.  Apparently the install system is not actually installing or properly installing the boot loader.   This interestingly enough is the case if even on the page about the boot loader you tell it to do nothing and not change this.
Comment 15 David Lehman 2009-12-09 15:04:36 EST
(In reply to comment #14)
> I am not sure exactly what it is that you want?
> 
> Right now I am not actually getting any crashes or dumps during the
> installation or in this case upgrades.   At this point it indeed may be a
> different bug.   It certainly presents differently.

If it's a different bug (it seems to be) it warrants a different report.

In any report, we'll want a description of the procedure to reproduce the bug, along with anaconda.log, anaconda.syslog, storage.log, program.log, install.log, and sometimes yum.log and/or anaconda.xlog from the installation. You could get them in rescue mode from the following locations:

/mnt/sysimage/var/log/anaconda.log
/mnt/sysimage/var/log/anaconda.syslog
/mnt/sysimage/var/log/storage.log
/mnt/sysimage/var/log/program.log
/mnt/sysimage/root/install.log (or upgrade.log if more appropriate)

The information you just gave in your last comment, in addition to the logs, would be a very good start.

Thanks for your patience.
Comment 16 Ray Todd Stevens 2010-01-18 11:51:47 EST
(In reply to comment #15)


Interesting.   Bugzilla just emailed me that you had posted this.
Comment 17 Ray Todd Stevens 2010-01-18 12:04:59 EST
As requested in 14 have now opened a new bug 556539
Comment 18 David Lehman 2010-01-18 12:31:59 EST
Ok, so does that mean we are in agreement that this bug can be closed?
Comment 19 Bug Zapper 2010-03-15 08:35:09 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 David Lehman 2011-02-24 09:40:06 EST
Feel free to reopen this bug if you are experiencing this issue with Fedora 14.

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