Bug 664327 - Installation failure - Preupgrade fails after restart
Summary: Installation failure - Preupgrade fails after restart
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: preupgrade
Version: 14
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 664324 664325 664326 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-19 21:44 UTC by Gary Meerschaert
Modified: 2012-08-16 20:02 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 20:02:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Anaconda bug report (511.60 KB, application/octet-stream)
2010-12-19 21:44 UTC, Gary Meerschaert
no flags Details
sosreport -a results file (1.80 MB, application/x-gzip)
2010-12-19 22:54 UTC, Gary Meerschaert
no flags Details
sosreport -a results file md5 (33 bytes, application/octet-stream)
2010-12-19 22:55 UTC, Gary Meerschaert
no flags Details

Description Gary Meerschaert 2010-12-19 21:44:35 UTC
Created attachment 469637 [details]
Anaconda bug report

Description of problem:

Using preupgrade from Fedora 13, the installation fails after
the reboot as indicated in the attached bug report. The installation seems to
fail upon encountering my large RAID array, which works
properly in Fedora 13.

/etc/mdadm.conf contains
# mdadm.conf written out by anaconda
MAILADDR root@localhost
AUTO +imsm +1.x -all
ARRAY /dev/md/0_0 metadata=0.90 UUID=53654485:40f422c8:19f0a6b8:f896c017
ARRAY /dev/md0 metadata=1.2 name=:md1 UUID=07b8cb07:1dd824e4:1a20d1d0:f7cff60d

mdadm --detail /dev/md127 reports

/dev/md127:
        Version : 0.90
  Creation Time : Mon Feb 16 06:56:03 2009
     Raid Level : raid5
     Array Size : 1465127616 (1397.25 GiB 1500.29 GB)
  Used Dev Size : 488375872 (465.75 GiB 500.10 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 127
    Persistence : Superblock is persistent

    Update Time : Sun Dec 19 15:31:16 2010
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 4K

           UUID : 53654485:40f422c8:19f0a6b8:f896c017
         Events : 0.316754

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       49        1      active sync   /dev/sdd1
       2       8       65        2      active sync   /dev/sde1
       3       8       33        3      active sync   /dev/sdc1


dmesg (patrial) reports

raid6: sse2x1    3640 MB/s
raid6: sse2x2    4546 MB/s
raid6: using algorithm sse2x2 (4546 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: device sda2 operational as raid disk 0
raid5: device sdc1 operational as raid disk 3
raid5: device sdd1 operational as raid disk 1
raid5: device sde1 operational as raid disk 2
raid5: allocated 4222kB for md127
0: w=1 pa=0 pr=4 m=1 a=2 r=4 op1=0 op2=0
3: w=2 pa=0 pr=4 m=1 a=2 r=4 op1=0 op2=0
1: w=3 pa=0 pr=4 m=1 a=2 r=4 op1=0 op2=0
2: w=4 pa=0 pr=4 m=1 a=2 r=4 op1=0 op2=0
raid5: raid level 5 set md127 active with 4 out of 4 devices, algorithm 2
RAID5 conf printout:
 --- rd:4 wd:4
 disk 0, o:1, dev:sda2
 disk 1, o:1, dev:sdd1
 disk 2, o:1, dev:sde1
 disk 3, o:1, dev:sdc1
md127: detected capacity change from 0 to 1500290678784
md: bind<sda3>
 md127: unknown partition table
md: bind<sdb3>
md: raid1 personality registered for level 1
raid1: raid set md0 active with 2 out of 2 mirrors
md0: detected capacity change from 0 to 223315164160
 md0: unknown partition table
EXT4-fs (sda1): mounted filesystem with ordered data mode
EXT4-fs (dm-7): mounted filesystem with ordered data mode
EXT4-fs (dm-6): mounted filesystem with ordered data mode
EXT4-fs (dm-0): mounted filesystem with ordered data mode
EXT4-fs (dm-1): mounted filesystem with ordered data mode
EXT4-fs (dm-3): mounted filesystem with ordered data mode
EXT4-fs (dm-2): mounted filesystem with ordered data mode
EXT4-fs (dm-4): mounted filesystem with ordered data mode
EXT4-fs (dm-5): mounted filesystem with ordered data mode
EXT4-fs (md127): mounted filesystem with ordered data mode
Adding 16777212k swap on /dev/sdb2.  Priority:-1 extents:1 across:16777212k 

df -h reports

Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             238G  561M  236G   1% /
tmpfs                 1.6G  1.3M  1.6G   1% /dev/shm
/dev/sda1             485M  245M  215M  54% /boot
/dev/mapper/VG0-Logical_Volume_07
                       45G   24G   19G  57% /data
/dev/mapper/VG0-Logical_Volume_06
                       30G  3.8G   25G  14% /home
/dev/mapper/VG0-Logical_Volume_00
                      6.8G  234M  6.3G   4% /opt
/dev/mapper/VG0-Logical_Volume_01
                       30G  5.5G   23G  20% /usr
/dev/mapper/VG0-Logical_Volume_03
                      6.8G  4.3G  2.3G  66% /var
/dev/mapper/VG0-Logical_Volume_02
                       30G  2.6G   26G  10% /usr/local
/dev/mapper/VG0-Logical_Volume_04
                       30G  285M   28G   1% /var/log
/dev/mapper/VG0-Logical_Volume_05
                       30G  178M   28G   1% /var/spool
/dev/md127            1.4T  626G  680G  48% /backup

Version-Release number of selected component (if applicable):


How reproducible:

completely. Happens every time.

Steps to Reproduce:
1. run preupgrade
2. system reboots
3. error reported. Bug report saved
  
Actual results:

Installation failed

Expected results:

System upgraded to Fedora 14

Additional info:

Comment 1 Gary Meerschaert 2010-12-19 22:54:00 UTC
Created attachment 469643 [details]
sosreport -a results file

Comment 2 Gary Meerschaert 2010-12-19 22:55:23 UTC
Created attachment 469644 [details]
sosreport -a results file md5

Comment 3 Gary Meerschaert 2010-12-20 01:32:55 UTC
Workaround:

Comment out RAID (in this case, backup) in /etc/fstab and the system upgrades. Remove comment in fstab and issue mount -a after rebooting.

Comment 4 Gary Meerschaert 2010-12-20 01:33:44 UTC
*** Bug 664324 has been marked as a duplicate of this bug. ***

Comment 5 Gary Meerschaert 2010-12-20 01:34:14 UTC
*** Bug 664325 has been marked as a duplicate of this bug. ***

Comment 6 Gary Meerschaert 2010-12-20 01:34:36 UTC
*** Bug 664326 has been marked as a duplicate of this bug. ***

Comment 7 Fedora End Of Life 2012-08-16 20:02:58 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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