Bug 160622

Created attachment 115522 [details]
My /etc/fstab file

I'm not sure how useful it is, but here's my fstab file...

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).

Your RAID device shouldn't be labeled.  If you use tune2fs or e2label, you
should be able to remove the label.

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>.

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.

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)

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!

 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.

(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.

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.

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).

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

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 ~]#

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 ~]#

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.

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.

 

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.

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 :(

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).

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

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.

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. 

Fedora Core 6 is no longer maintained.

Can anybody reproduce this bug on Fedora 8?

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.

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

>   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

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.

While I no longer have this setup, it appears that Charlie is still experiencing
this issue. Reopening on his behalf.

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.

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.

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.

BTW: should I file a separate bug for Fedora 10 not upgrading F9 running on encrypted disks?

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.

Early dismissal (anaconda) doesn't help when all info lands in /etc/fstab.
No anaconda, hard manual labour.

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.