|Summary:||Cannot upgrade from hard drive|
|Product:||[Retired] Red Hat Linux||Reporter:||hchcheng|
|Component:||installer||Assignee:||Jay Turner <jturner>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||6.1||CC:||ceby, charette, ed_hume, mono, pascual_alonso, samik, srevivo|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-11-09 17:35:14 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description hchcheng 1999-10-09 03:11:52 UTC
I have downloaded all of RedHat directory from an ftp site to my local harddrive, which is on /dev/hdb1, a Win98 partition. I am upgrading from RH 6.0. After the "Reading package information" dialog, it gives an "Exception Occurred" dialog (made more concise here): Traceback (innermost last) /usr/bin/anacond.real Line 225 /tmp/lib/python1.5/site-packages/text.py Line 1000 .. 251 .. /todo.py 1147 .. 942 .. 930 .. /harddrive.py 45 .. /isys.py 8 System Error: (16, 'Device or resource busy') The dialog gives two choices "OK" and "Debug". I chose OK and everything is umounted and the system is halted.
Comment 1 hchcheng 1999-10-11 19:59:59 UTC
I have just tried putting everything into an ext2 directory (/dev/hdb3) and install it from there, but the result is exactly the same. By the way, hitting "Enter" at the boot: prompt is supposed to start graphical install, but I get text install instead. I can't figure out why. I think it may have tried to read my CD-ROM drive (from what I gather in other virtual consoles) and failed. Does GUI install require CD-ROM?
Comment 2 pascual_alonso 1999-10-13 17:32:59 UTC
Updating or Installing I'm getting the same error! ------- Additional Comments From 10/14/99 00:48 ------- Yes, I have a brand new P-III dual processor system. I downloaded the entire 6.1 onto a clean ext2 HD. I am going for a brand new install, not an upgrade. Everything goes great until "reading package unformation" is up for a few minutes --- After which, I get the exact same error! I have tried various different setup parameters, all lead to this exact same error message. ------- Additional Comments From 10/14/99 14:58 ------- This is the same as a bug I previously entered. Check out #5672. ------- Additional Comments From 10/15/99 14:20 ------- I was getting a similar error, with the debug I found that a rpm was incompleted, I got it again and the instalation worked. The line 45 in harddrive.py returns the list of rpm files as objects, so if a rpm file has 0 bytes or is incompleted it is included in the list anyway causing problems later. Pascual.
Comment 3 Anonymous 1999-10-15 20:27:59 UTC
I have downloaded the entire dist onto ext2 partitions twice now, from two different mirrors (about 15 hours each!). I get the same crash each time. Running the python debugger, the file isys.py at line 8 it trys to unmount the disk storing the source distribution with: return _isys.unmount(what) the debugger says the value for 'what' is:'/tmp/hdimage' From VT #2 I ran the 'mount' command. I have /dev/hdc1 (my source tree) mounted on /tmp/hdimage I attempted to unmount the drive manually, with a 'umount /tmp/hdimage'. I got the same error, Device or Resource Busy. My questions are: 1) why is setup trying to unmount the source partition. It's going to need those files!!!! 2) Where can I find the source to the boot.img so I can try to figure out what it's trying to do and debug this myself. 3) If I were to burn my own CDROM with the source image, would it work? I still have not experienced V6.1 and that sucks! Lets get this fixed!!!!
Comment 4 Jay Turner 1999-10-21 12:13:59 UTC
Can someone confirm whether this is indeed because of the GTK.py and gtk.py files being put on an msdos system (which will see them as the same thing!) In other words, is this bug a duplicate of #5672? Please reopen is it is not a duplicate and see the details in #5672 if it is a duplicate.
Comment 5 hchcheng 1999-10-21 12:56:59 UTC
This is the same bug as 5672, but it is not a problem with GTK.py vs. gtk.py (I don't believe 5672 is about that either!). I have downloaded everything to an ext2 file system and the result is exactly the same. ------- Additional Comments From 10/21/99 09:15 ------- 5672 had the same symptoms, but was discussing MSDOS file systems. The problem we note here is upgrading from hard disk. The problem manifests itself when python attempts to unmount the current hard disk image while going through mounting/unmounting partitions un the upgrage package checks. The current hdimage cannot be unmounted (obviously :^) and the upgrade fails. The python code should be skipping over the unmounting of the current hdimage.
Comment 6 Jay Turner 1999-10-22 18:58:59 UTC
*** Bug 5828 has been marked as a duplicate of this bug. *** when I boot from the boot.img (local boot diskette image) at the scaning for the available packages phase during the installation, there is an error (exception message), and it refuses continuing the installation. Is something wrong in the installable files or there is an error in the installation process. Please send me an answer .... ------- Additional Comments From email@example.com 10/11/99 11:19 ------- Please send the text of the error message to help with this debugging effort. ------- Additional Comments From firstname.lastname@example.org 10/21/99 14:49 ------- *** Bug 6186 has been marked as a duplicate of this bug. *** I have previuosly sent a bug report on error on installation of RedHat 6.1 bug # 5828, and no one has answered me so far, please I need an answer, as I have tried everything I can. Waiting for your feedback .....
Comment 7 opie.simons 1999-10-22 23:50:59 UTC
From email@example.com: Glad I found everyone here. I thought our bug was forgotten. :-P The full text for the Python error message can be found in my descritpion at the top of Bug #5672. Also to clarify, 5672 was an install from hard disk and I removed the GTK vs gtk problem by trying to reinstall from ext2. I see others have also run the test and found a reproducible problem as well. jturner- If there is something you'd like me or your dedicated testers :-) to test or try out, please let me/us know.
Comment 8 hchcheng 1999-10-23 01:21:59 UTC
Just want to add that the newest update image (1999:045) gives the same result, with slightly a different error message: I think the file comes from /tmp/updates (or something like that) instead. The error is still the same: Device or resource busy. Let me know if there is anything you want me to try.
Comment 9 wakeup2 1999-11-03 16:36:59 UTC
I was having the same problem (System Error: (16, 'Device or resource busy') and resolved it by comparing the RPMS directory and found that one of the RPMS wasnt completed. I resumed the file and it got past that point fine. If you're using windows, get cuteftp and it has a compare directory feature. I saw that someone else used this to fix their problem as well. ------- Additional Comments From 11/05/99 16:45 ------- From firstname.lastname@example.org: I had some time a few minutes ago to check on email@example.com's comments and though I couldn't use cuteFTP, I downloaded the ls-lr file from the RPMs dir. on the mirror and compared it to my local install RPM directory. I found that the how-to-chinese... file size didn't match. I downloaded it again, verified the size, and then made it successfully through the upgrade without changing any other parameters that I have previously discussed. I did NOT have this RPM previously installed nor did I upgrade it. If others have this same problem, the error we are receiving is definitely misleading since it doesn't point to the real error.
Comment 10 Jay Turner 1999-11-09 17:35:59 UTC
The message is really not that misleading, just pointing at the wrong place. What is happening is that the installer was not able to find the file you were missing and therefore it was falling out. Well, since the install source was mounted, the installer was not able to unmount it and therefore the message about the device being busy. There is really no way that we can get around this seeing at this is a python traceback and all it is telling us is what was on the stack at the time that there were problems. I am closing this bug, as the problem is solved.