Bug 160622 - Installer does not upgrade from previous versions when there is more than one unlabled swap partition
Installer does not upgrade from previous versions when there is more than one...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
See Comment #18 for more info
: Regression, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-16 02:17 EDT by Jake
Modified: 2008-08-28 10:41 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-28 10:28:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
My /etc/fstab file (751 bytes, text/plain)
2005-06-16 02:22 EDT, Jake
no flags Details
My /etc/raidtab file (221 bytes, text/plain)
2005-06-25 02:08 EDT, Jake
no flags Details
Screenshot of the volumes on my system from the GUI. (105.71 KB, image/png)
2008-05-14 11:26 EDT, Charlie Farrow
no flags Details

  None (edit)
Description Jake 2005-06-16 02:17:08 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
When attempting to upgrade from fedora core 3 to fedore core 4, I am only able to get to the screen where it asks what installation I want to upgrade. There is a drop down box with only one option listed:

Fedora Core 3 (/dev/md0)

When I select that disk and click next, I get an error box that looks something like:

+-----------------------------------------------------+
|                   Duplicate Labels                  |
+-----------------------------------------------------+
|                                                     |
|  (*) Multiple devices on your system are labelled   |
|                                                     |
|                                       [ Reboot ]    |
+-----------------------------------------------------+

I'm assuming this is because I use software RAID (mirroring). I have previously upgraded this system from Red Hat 9 to Fedora Core 3 with the mirroring in place and do not recall having this issue. I have changed no hardware that I can remember since that upgrade.

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


How reproducible:
Always

Steps to Reproduce:
For me, every time I try to boot off the install CD and select upgrade, this is what I get. To me, this is a show stopper, but not everybody uses this type of setup.

Additional info:
Comment 1 Jake 2005-06-16 02:22:43 EDT
Created attachment 115522 [details]
My /etc/fstab file

I'm not sure how useful it is, but here's my fstab file...
Comment 2 Jake 2005-06-16 02:25:08 EDT
Forgot to mention, the (*) in comment 0 is what appears to be a critical error
icon (a red circle with a white bar in the middle of it).
Comment 3 Jeremy Katz 2005-06-16 16:25:48 EDT
Your RAID device shouldn't be labeled.  If you use tune2fs or e2label, you
should be able to remove the label.
Comment 4 Jake 2005-06-17 00:57:16 EDT
As far as I can tell, I don't have any labels:
[root@waldo ~]# e2label /dev/md0

[root@waldo ~]# e2label /dev/hdg1

[root@waldo ~]# e2label /dev/hde1

[root@waldo ~]#

(/dev/md0 is a mirror of partitions on hdg and hde, IIRC). Also, the error box
from the installer doesn't tell me what label is suposedly duplicated... unless
the duplicate is <NULL>.
Comment 5 Jake 2005-06-20 14:30:29 EDT
I still cannot determine where this mysterious duplicated label is coming from.
As far as I can tell, none of my disks are labeled. I know I previously upgraded
this machine from Red Hat 9 to Fedora Core 3 and do not recall making any
configuration changes to the disks since that time. What confuses me the most is
the fact that the error message does not specify what label is duplicated.
Attempts to find a solution that would imply that this is, in fact, not a bug in
anaconda have come up empty.
Comment 6 Jake 2005-06-25 02:08:40 EDT
Created attachment 115968 [details]
My /etc/raidtab file

I'm not sure if this file will help or not (probably not, but it can't hurt)
Comment 7 Jon Paterson 2005-06-25 10:09:40 EDT
I have exactly the same problem.  this is a FC3 system running software raid
across /dev/md1,2,5.

initially, it was right, my /boot mirrors were both mirrored.

I have now removed the labels with e2label, but it will still not let me
continue.  I have checked all of the physical partitions and RAID volumes, and
none have any labels.

Happy to help - just tell me what to look for as it does not report which name /
partition is at fault!
Comment 9 James Antill 2005-06-28 02:11:15 EDT
 It's worth pointing out that this box had all it's drives setup by anaconda
around RHL-7.2, and FC1/FC2 were fine with it ... so this should be easy to
reproduce.

 This is what I did (as I remember it) to get around this bug...

1. I initially had md0 and md1 over two drives hda and hdc. md0 was RAID1 /boot
and md1 was RAID1 /. I also had 3 swap partitions (two on the hda drive on one
on the hdc).

2. I eventaully ended up doing all of this (I tried bits of this and it only
worked after I'd done all of it, although I got different errors from anaconda
after doing some ... and I'd initially tried tune2fs -L '', but that didn't seem
to help at all ... so I just used different labels/UUIDs):

mdadm --fail /dev/md0 /dev/hdcX
mdadm --stop /dev/md0
mdadm --zero-superblock /dev/hdcY
mdadm --zero-superblock /dev/hdaX

mdadm --fail /dev/md1 /dev/hdcY
mdadm --stop /dev/md1
mdadm --zero-superblock /dev/hdcY
mdadm --zero-superblock /dev/hdaY

tune2fs -U time -L abcd0 -l /dev/hdcX
tune2fs -U time -L abcd1 -l /dev/hdcY

rm /etc/raidtab
fdisk /dev/hda -- change 'auto raid type' to 'linux'
               -- ALSO remove all swap partitions (it still gave the multiple
devices error)
fdisk /dev/hdc -- dito.

vi /etc/fstab -- remove any references to mdX and the swap partitions.

reboot into installer (it should now list hda and hdc as seperate upgrade
targets), and ask it to force upgrade the boot loader (as you don't have one,
given you were booting off of RAID1 before).

...I now have all the old data on the hdc disk, and it should be easy to
re-create the RAID1 paritions and tell them to re-sync ... but given the
bootloader got changed to grub (which I'm not sure how well it boots of RAID1)
and from the comments it's not obvious whatever is wrong with anaconda is going
to work for FC5, I'm probably not going to bother.
Comment 10 Jake 2005-06-30 01:14:32 EDT
(In reply to comment #9)
> ...I now have all the old data on the hdc disk, and it should be easy to
> re-create the RAID1 paritions and tell them to re-sync ... but given the
> bootloader got changed to grub (which I'm not sure how well it boots of RAID1)
> and from the comments it's not obvious whatever is wrong with anaconda is going
> to work for FC5, I'm probably not going to bother.
> 

I can tell you from personal expierience that Grub does fine with /boot being
part of a mirror. I have only one partition on my two disks so /dev/md0 is my
only hard drive device. Grub reads the available kernels and boots into the
chosen one just fine. FC5, however, is a valid concern... especially being that,
AFAICT, the only response from anybody who may know the code was that my "RAID
device shouldn't be labeled," which it isn't.
Comment 11 bylander 2005-06-30 12:32:29 EDT
I have the same problem.

I have two software RAID partitions.  Using e2label to change the labels of the
software RAID partitions and their parts had no effect (still happy to boot up
FC3 though).

I agree that this is a showstopper.
Comment 12 Jake 2005-07-06 00:59:12 EDT
Changing severity to 'regression' as it did work fine with Fedora Core 3 (I had
the same setup when I upgraded this box from RH 9 to Fedora Core 3).
Comment 13 Peter Jones 2005-07-06 19:01:13 EDT
Jake, please run this and show us the output:

for x in $(grep '^ ' /proc/partitions|awk '{ print $4 }') ; do
  echo $x: x$(e2label $x)x
done
Comment 14 Jake 2005-07-07 09:53:44 EDT
I'm thinking that I must have done something wrong....

[root@waldo ~]# for x in $(grep '^ ' /proc/partitions|awk '{ print $4 }') ; do
>   echo $x: x$(e2label $x)x
> done
e2label: No such file or directory while trying to open hde
Couldn't find valid filesystem superblock.
hde: xx
e2label: No such file or directory while trying to open hde1
Couldn't find valid filesystem superblock.
hde1: xx
e2label: No such file or directory while trying to open hde2
Couldn't find valid filesystem superblock.
hde2: xx
e2label: No such file or directory while trying to open hdg
Couldn't find valid filesystem superblock.
hdg: xx
e2label: No such file or directory while trying to open hdg1
Couldn't find valid filesystem superblock.
hdg1: xx
e2label: No such file or directory while trying to open hdg2
Couldn't find valid filesystem superblock.
hdg2: xx
e2label: No such file or directory while trying to open md0
Couldn't find valid filesystem superblock.
md0: xx
[root@waldo ~]#

Comment 15 Jake 2005-07-07 09:58:25 EDT
Unless the e2label command should have '/dev/' added to it... then the output is:
(Also, I didn't intend to change the severity or the status, though I'm going to
assume Bugzilla automatically changes from NEEDINFO when more info is submitted).

[root@waldo ~]# for x in $(grep '^ ' /proc/partitions|awk '{ print $4 }') ; do
echo $x: x$(e2label /dev/$x)x; done
e2label: Bad magic number in super-block while trying to open /dev/hde
Couldn't find valid filesystem superblock.
hde: xx
hde1: xx
e2label: Bad magic number in super-block while trying to open /dev/hde2
Couldn't find valid filesystem superblock.
hde2: xx
e2label: Bad magic number in super-block while trying to open /dev/hdg
Couldn't find valid filesystem superblock.
hdg: xx
hdg1: xx
e2label: Bad magic number in super-block while trying to open /dev/hdg2
Couldn't find valid filesystem superblock.
hdg2: xx
md0: xx
[root@waldo ~]#
Comment 16 Christopher Hicks 2005-07-24 21:19:50 EDT
I've been experiencing similar problems upgrading a desktop machine with no RAID
from FC2 to FC4.  Has anyone come up with any workarounds?  I tried relabeling
the two ext3 partitions but it didn't change anything.
Comment 17 George Fremin 2005-07-25 13:47:59 EDT
I also have this problem. I have two disks in RAID mirror.  I am trying to
upgrade the machine from RH 7.3 to FC 4.

 
Comment 18 Jake 2005-08-29 09:31:05 EDT
I was about to follow the full proceedure in comment #9 in order to finally
update to FC4 when I noticed the following line:

>  -- ALSO remove all swap partitions (it still gave the multiple devices error)

So I went out on a limb and just removed one of my swap partitions. I removed it
from both /etc/fstab and using fdisk (fwiw, I removed the one on /dev/hde). I
then tried the upgrade process again and sure enough, it worked. I also had a
comment in my blog (http://www.steenhagen.us/~jake/blog/?p=62#comment-566)
yesterday (the day after I updated) from somebody else who suceeded by labeling
their swap partitions. Given this new evidence, I think the problem is actually
related to having multiple swap partitions, not software RAID.
Comment 19 Graham Leggett 2005-10-20 18:25:45 EDT
I also struggled with this problem. Not only do you need to remove the swap
partition from /dev/fstab, but you need to relabel the partition AND format it
as something not swap (I used mke2fs) to get it to pass this point :(
Comment 20 Jake 2006-03-22 09:15:55 EST
Any idea if this has been fixed in FC5? I don't have the same setup anymore (I
had to reinstall for unrelated hardware issues and haven't renabled mirroring yet).
Comment 21 Don Himelrick 2006-03-26 12:59:58 EST
Yes, I experienced this in FC5 with 2 swap partitions.   The fix for me was as
someone previously posted on Jake's page.

From a running FC4, with swap partitions set up on hde9 and hdg9:

swapoff /dev/hde9
swapoff /dev/hdg9
mkswap -L "swap_a" /dev/hde9
mkswap -L "swap_b" /dev/hdg9
swapon /dev/hde9
swapon /dev/hdg9
Comment 22 Christian Iseli 2007-01-19 19:23:19 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 23 Steve Lacy 2007-03-07 16:48:32 EST
I just attempted an upgrade from FC4 to FC6, and this bug still exists.  The
solution to the problem was to do whats described in Comment #21 to add labels
to the swap partitions.  I believe this is a bug in the "pyparted" package,
which is incorrectly returning bogus labels for unlabeled swap partitions. 
Comment 24 petrosyan 2008-02-16 17:55:46 EST
Fedora Core 6 is no longer maintained.

Can anybody reproduce this bug on Fedora 8?
Comment 25 petrosyan 2008-03-26 15:43:10 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.
Comment 26 Charlie Farrow 2008-05-14 11:10:02 EDT
Still very much alive.

Upgrading to FC9 from FC6 and hit this bug. Not massivly experience in Linux, 
please let me know the commands you need to see the output of and I will reply 
with all you need.

TIA
Comment 27 Charlie Farrow 2008-05-14 11:19:22 EDT
>   echo $x: x$(e2label $x)x
> done
e2label: No such file or directory while trying to open sda
Couldn't find valid filesystem superblock.
sda: xx
e2label: No such file or directory while trying to open sda1
Couldn't find valid filesystem superblock.
sda1: xx
e2label: No such file or directory while trying to open sda2
Couldn't find valid filesystem superblock.
sda2: xx
e2label: No such file or directory while trying to open sda3
Couldn't find valid filesystem superblock.
sda3: xx
e2label: No such file or directory while trying to open sda4
Couldn't find valid filesystem superblock.
sda4: xx
e2label: No such file or directory while trying to open sda5
Couldn't find valid filesystem superblock.
sda5: xx
e2label: No such file or directory while trying to open dm-0
Couldn't find valid filesystem superblock.
dm-0: xx
e2label: No such file or directory while trying to open dm-1
Couldn't find valid filesystem superblock.
dm-1: xx
Comment 28 Charlie Farrow 2008-05-14 11:26:11 EDT
Created attachment 305371 [details]
Screenshot of the volumes on my system from the GUI.

Might help you to see what is what.

LogVol1 is /swap
LogVol0 is /

Need anything else please let me know.
Comment 29 Jake 2008-05-14 12:02:04 EDT
While I no longer have this setup, it appears that Charlie is still experiencing
this issue. Reopening on his behalf.
Comment 30 udo 2008-05-17 06:02:36 EDT
Upgrade (from F8 to F9) also fails when swap is encrypted.
Info on how the swap is configured is in /etc/crypttab.
So should not be an issue.
Comment 31 Andy Lindeberg 2008-08-07 15:00:55 EDT
I've been unable to reproduce this bug with an F8 to F9 upgrade. Anybody who can reliably produce this, please attach your kickstart file.

Re: Comment #30: F8 does not support encryption, so it is unsurprising that your upgrade failed.
Comment 32 udo 2008-08-07 22:47:06 EDT
F8 ran with encrypted swap. (yes custom kernel but I guess teh Fedora kernels also support DM-encryption)
The upgrade to F9 is the issue here. F9 should support encryption as you write.
Comment 33 udo 2008-08-16 02:19:11 EDT
BTW: should I file a separate bug for Fedora 10 not upgrading F9 running on encrypted disks?
Comment 34 Peter Jones 2008-08-27 12:57:02 EDT
If you didn't create the encrypted volume through anaconda, then there's really no way we're going to support upgrading a system installed on it.  If you did, then that should work.
Comment 35 udo 2008-08-27 22:54:29 EDT
Early dismissal (anaconda) doesn't help when all info lands in /etc/fstab.
No anaconda, hard manual labour.
Comment 36 udo 2008-08-28 10:41:23 EDT
Thanks for closing. I'll refer to this bug when we upgrade to F10.
F9 does support a fully encrypted system in the initscripts so then there's no holding back anymore.

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