Red Hat Bugzilla – Bug 133342
installs into wrong partition!
Last modified: 2007-11-30 17:10:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)
Description of problem:
When install or update into machine containing lvm, install/update does the wrong partition!
I have done this on 2 machines so far, one athlon one x86_64. Both times, during the install I switched to console and running "mount" shows the wrong partition was being used for installation.
In one case I had 1 lvm + 1 normal partition, selected normal part for install and it used lvm instead. Other case had 2 lvm parts, it updated on the wrong one
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.install or update on machine with lvm
Doing an install or an upgrade? If you do an install, what do you
select as far as partitioning options?
I've tried this on 2 machines. The last one I selected update. The
other I selected install, and did manual partitioning.
Has lvm on sata + parallel ide. I told it to use the parallel ide.
I think I tried update first. I had duplicated the sata FC2 onto the
parallel drive before the update. It updated to the sata instead,
and then wouldn't boot. I know it updated to the sata, because I
shelled out and looked at mount - the lvm was mounted, the parallel
ide was not. Finally I did clean install to sata, using anaconda
manual partition to delete, recreate partitions and then do the
install. Now it's running.
Has 2 lvm on a pair of sata drives. I duped the 1st lvm to a second
(on different partitions of the same drives), then chose update.
Same thing - it mounted the 1st lvm and is now updating that one even
though I chose the 2nd.
Machine 2 is not finished updating - I plan to finish it tonight. If
you need some more info before the update completes, tell me before
When you say you're duping the LVM are you completely duping
(including things like filesystem labels and LVM metadata)? If so,
I'm not entirely surprised that it's breaking since those are supposed
to be "unique" per system and if they're not, strange things will happen.
I did tar -c -f - --one-file-system / | tar -C <root-of-new-fs> -x -f
Machine 2 finished update of wrong partition and would not boot. I
brought it up with rescue, ran grub-install --recheck <device>, and
now it's booted OK.
I believe it is likely that the defect in mkinitrd is what caused
this problem. It would be a good idea to come up with a respun
installation iso that fixes this.
"defect in mkinitrd"? I need more details here.
Also, it sounds like the problem really is in how you're setting up
your duplicates. If you're just copying things over, you're going to
then have to change things like the fstab, etc if you expect them to
work. Did you make all of those modifications?
I was referring to this:
But I'm not sure about that.
So you're saying that if I duplicate a fs A -> another fs B, using
ordinary tools such as tar (not copy raw device like dd), that unless
I then edit fstab, if I then update system you expect anaconda to
update the wrong partition??
IMHO, updating the wrong partition (under virtually any scenario) is
the most serious bug I've ever seen in any linux since 0.9
kernel/slackware. Worse even than destroying a file system.
If you don't edit the fstab, then your fstab is still referencing
entirely the wrong partitions. That *has* to be able to be counted on
to be correct or else I have nothing I can count on for an upgrade.