Bug 133342
Summary: | installs into wrong partition! | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Neal Becker <ndbecker2> |
Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED NOTABUG | QA Contact: | Mike McLean <mikem> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | nobody+pnasrat |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-24 17:00:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Neal Becker
2004-09-23 10:59:45 UTC
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. |