Bug 670368 - Fedora 14 upgrade fails if other Fedora systems are on other hard drives
Summary: Fedora 14 upgrade fails if other Fedora systems are on other hard drives
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 14
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-18 03:15 UTC by Paul Baio
Modified: 2011-01-19 17:02 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-19 14:11:20 UTC
Type: ---


Attachments (Terms of Use)

Description Paul Baio 2011-01-18 03:15:57 UTC
Description of problem:
Cannot upgrade Fedora 13 to 14 when hard drives on system contain LVM drives with swap partitions on them.


Version-Release number of selected component (if applicable):
Redhat Linux Fedora 14 (Laughlin)

How reproducible:
Always

Steps to Reproduce:
1. Have more than one hard drive on system with some version of Fedora installed on it. Any previous version, as long as it uses an LVM drive with swap partition.
2. Attempt to upgrade existing Fedora Core 13 either by DVD or use preupgrade command from terminal.
3. Will segfault on DVD install after "Examining storage devices" and you pick a drive to install to, OR will segfault when the same thing occurs during the reboot necessary when doing a preupgrade from term window.
  
Actual results:
Segfault or crash. Original working OS is not disturbed.

Expected results:
OS upgrades as it is expected to do.

Additional info:
After disc install fails, it gives the opportunity to save debug info report. Since there is no running OS at this point, you are allowed to configure a quick "network" and report this if you have an existing bugzilla account (I did not at the time) or save to hard drive somewhere. This I did but I have no idea where it went, if it saved at all. I did take very clear pictures of the errors and got some screencaps, as well as a df and mount report prior to the event posted to my personal web space. Also posted was the solution to the problem and how to get around it for anyone else having this problem. This information should allow the developers of the installer to anticipate this sort of situation and provide a method of dealing with it. My answer was to use "swapoff /dev/sdc2", etc., then delete the unused swap partitions from the unused drives. After which, the upgrade performed flawlessly. See info page:

http://home.comcast.net/~theohmster/Linux/

Comment 1 David Lehman 2011-01-18 14:26:59 UTC
There is not enough information here to work with. Many users, including myself, have upgraded and/or installed Fedora 14 on systems with other, older, linux/fedora installation present. There is more to the problem than that.

If you cannot provide the logs I will have to close this bug for lack of data.

Comment 2 Paul Baio 2011-01-18 21:50:44 UTC
Dave,

I agree, I had another fellow tell me several active swap files are common. What I do know is that the installation failed every time until I removed the two LVM drives or made them inactive, used swapoff, then deleted all partitions and just left them as single partition ext4. After that, the install went smooth as silk. During the crash, I was offered the opportunity to save a bug report. Either up it to bugzilla or save it to disk. I had no bugzilla account so I tried to save it to disk. Where it went I have no idea. It would be a new file somewhere, what it is called I do not know. My fstab, pictures of the error, and df reports are online at my personal web space.
http://home.comcast.net/~theohmster/Linux/

If you know where to look for the bug report or how to find it, I am all ears. I can send you my /var/log/messages file or anything you want, just let me know what will help. I am an end user, not a programmer so I have no idea of what material you need for this.

Comment 3 Paul Baio 2011-01-19 00:33:26 UTC
You can probably dismiss this bug. My machine always had a problem in that if I ever plugged in a USB device such as an external hard drive, it would not boot. Ever since putting in that PCI SATA controller, I had this issue. I could never backup my Linux because the only drive that matched my 500Gb drive was USB. Besides removing the LVM volumes, I also went into the system BIOS and removed USB as a boot option and guess what, the machine now boots right up with a USB drive in it, no problem at all.

It does not automount but I am able to mount it as root, piece of cake and everything works really, really good now. I am now leaning to dismissal of the bug report as just being a flaky install machine. I do not believe it is a Fedora bug any longer, just flaky hardware. All fixed, running quite well. Thank you for your time. (Although I really wish I had a copy of that crash report, but, I guess that is the fish that got away.)

Paul

Comment 4 David Lehman 2011-01-19 14:11:20 UTC
If you didn't copy the crash dump/log to another machine or to one of your permanent filesystems it is probably gone for good. If there is a next time you'll be able to save it directly to bugzilla. Thanks for the report.

Comment 5 Paul Baio 2011-01-19 16:50:50 UTC
Hello Dave,

Yes, I tried to copy the crash dump. I kept attempting to sent it to bugzilla but could not log in, later I found out my bugzilla account was with mozilla for firefox. When a crash occurs like that during installation, I could really do nothing, unless I configured a network device, that was my only choice. So I did my best at setting up eth0, which is my real NIC, but without a valid login, I was sunk. When trying to save to disk, I forgot that Linux uses the /dev/sdxx scheme of writing a file so I just tried to write to /tmp/crash and apparently, nothing was saved.

Just for future information, what would be the correct procedure to save a bug report in such a situation, other than attempting an upload to bugzilla? Would an attempted write to /dev/sda1 have worked? Hmmm, I am looking at my disk layout here:
http://home.comcast.net/~theohmster/Linux/Fedora_13_Disk_Setup.txt

/dev/sda1 is my boot partition, a half gig ext4 partition with almost 400Mg of available space. That probably would have worked as a crash dump, unless these dumps are very large. I wish I would have thought of this at the time but I didn't. Would that have worked? How would I copy it to another machine? The only machine on the same network is a Windows 7 machine, I have sharing setup and Windows 7 allows read/write to public shares and I have them setup. Perhaps saving to 192.168.15.3/Public might have worked. Will never know now unless I try it somehow in a term window. Maybe attempt to save a text file in vim to 192.168.15.3/Public/test.txt. I will play with it.

By all means, close the report. Not enough info. I am pretty sure it was hardware not setup properly. Now that I have removed USB drive from my boot options, I can plug in any USB drive, it shows up on lsusb, and mounts easily. Reboots are no problem anymore. Prior do doing this, reboots were impossible and the machine would hang and not regognize USB hardware. My idea was to use the 500Gb WD USB drive as a backup. Now that I can use it, I need a good backup scheme. I would like to save a disk image to make it possible to restore the hard disk intact, but know of no Linux program that will offer this feature. I think that dd might work, tar might work, but I need answers and will start to google for them and go to Usenet for answers now that I have the ability to do so.

Thanks for looking at this Dave. Take care,
Paul

Comment 6 David Lehman 2011-01-19 17:02:34 UTC
If you can't save to bugzilla you have to save it somewhere that will still exist after you reboot. You could mount one of your local filesystems and copy it there or you could copy it to a different machine over the network using scp. It's just a text file. The size depends on the amount of information that gets logged during installation. In most cases the file is less than 1MB.

Good luck with the backup solution.


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