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): don't know How reproducible: Always Steps to Reproduce: 1.install or update on machine with lvm 2. 3. Additional info:
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. 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.
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.
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: 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.
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.