Bug 133342 - installs into wrong partition!
installs into wrong partition!
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
3
All Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-23 06:59 EDT by Neal Becker
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-24 13:00:13 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)

  None (edit)
Description Neal Becker 2004-09-23 06:59:45 EDT
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):
don't know

How reproducible:
Always

Steps to Reproduce:
1.install or update on machine with lvm
2.
3.
    

Additional info:
Comment 1 Jeremy Katz 2004-09-23 11:42:00 EDT
Doing an install or an upgrade?  If you do an install, what do you
select as far as partitioning options?
Comment 2 Neal Becker 2004-09-23 12:07:00 EDT
I've tried this on 2 machines.  The last one I selected update.  The 
other I selected install, and did manual partitioning. 
 
Machine 1: 
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. 
 
Machine 2: 
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. 
Comment 3 Neal Becker 2004-09-23 12:42:52 EDT
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 
3pm EST. 
 
Comment 4 Jeremy Katz 2004-09-23 19:04:23 EDT
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.
Comment 5 Neal Becker 2004-09-23 19:22:25 EDT
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. 
Comment 6 Neal Becker 2004-09-24 07:03:17 EDT
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. 
Comment 7 Jeremy Katz 2004-09-24 12:13:12 EDT
"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?
Comment 8 Neal Becker 2004-09-24 12:31:16 EDT
I was referring to this: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133191 
 
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. 
Comment 9 Jeremy Katz 2004-09-24 13:00:13 EDT
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.

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