Bug 6481

Summary: updates-RHEA-1999:045 upgrade crash
Product: [Retired] Red Hat Linux Reporter: adrian.lawrence
Component: installerAssignee: Jay Turner <jturner>
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 6.1CC: srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-12-03 20:46: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 adrian.lawrence 1999-10-28 21:35:46 UTC
Attempt to upgrade in expert mode using hard disc image;
booted from boot-RHEA-1999:044.img with options "expert
updates". anaconda upates from updates-RHEA-1999:045.img
floppy were successfully read.
The hard disc image is known to be good: it has been used to
upgrade two other systems by nfs.

While "Reading Package information" is still
displayed:-Python traceback:-

File "/usr/bin/anaconda/real", line 225, in ?
  intf.run(todo, test=test)
File "/tmp/updates/text.py", line 1009, in run
  rc = apply(step[1](), step[2])
File "/tmp/updates/text.py", line 251, in __call__
  todo.upgradeFindPackages (root)
File "/tmp/updates/text.py", line 1177, in
upgradeFindPackages
  self.getCompsList ()
File "/tmp/updates/text.py", line 972, in getCompsList
  self.getHeaderList()
File "/tmp/updates/text.py", line 960, in getHeaderList
  self.hdList = self.method.readHeaders()
File "/tmp/lib/python1.5/site-packages/harddrive.py", line
45, in readHeaders
  isys.umount("/tmp/hdimage")
File "/tmp/lib/python1.5/site-packages/isys.py", line 8,
umount
  return _isys.umount(what)
SystemError: (16,'Device or resource busy')

(Pdb) list gives

3
4  def mount(device, location, fstype = "ext2"):
5      return _isys.mount(fstype, device, location)
6
7  def umount(what)
8  ->  return _isys.umount(what)
9
.......

mount on VC #2 shows:-

/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/pts /dev/pts devpts rw 0 0
/tmp/ram3 /mnt/runtime ext2 rw 0 0
/tmp/hda3 /tmp/hdimage ext2 rw 0 0

VC#4: last two messages record the addition  two swap
partitions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here is /etc/fstab from the target machine:-
/dev/hda1   /     ext2 defaults 1 1
/dev/hda2   none    swap   sw
/dev/sdb3   none    swap   sw
none        /proc   proc   defaults
/dev/sdb4   /usr    ext2   defaults 1 2
/dev/sda2   /home   ext2   defaults 1 2
/dev/hda3   /fs0    ext2    defaults 1 2
/dev/hdb1   /fs1    ext2    defaults 1 2
/dev/sda1   /dos    msdos  rw 0 0
/dev/sdb1   /doze95 vfat   rw 0 0
#/dev/hdc   /cdrom  iso9660 ro,user 0 0
/dev/fd0    /mnt/floppy ext2   noauto,user 0 0

#/dev/sdb2  none  hpfs   defaults 0 0
#none /dev/pts devpts gid=5,mode=620       0 0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That may make more sense in the light of /etc/lilo.conf:-
boot=/dev/hda
map=/boot/map
delay =100
install=/boot/boot.b
prompt
timeout=100
image=/boot/zImage
        label=linux
        root=/dev/hda1
        append="mem=128M"
        read-only
image=/boot/zImage-2.2.12
        label=linux-2.2.12
        root=/dev/hda1
        append="mem=128M"
        read-only
image=/boot/zImage-2.2.10
        label=linux-2.2.10
        root=/dev/hda1
        append="mem=128M"
        read-only
image=/boot/zImage-2.2.9
        label=linux-2.2.9
        root=/dev/hda1
        append="mem=128M"
        read-only
other=/dev/sda1
        label=dos
        table=/dev/sda
#       loader=/boot/any_d.b    #old way
        map-drive=0x80
      to=0x82
        map-drive=0x82
          to=0x80
other=/dev/sdb1
        label=win95
#       table=/dev/sdb
#       loader=/boot/any_e.b
# 80 --> hda, 81 --> hdb, 82 --> sda (dos), 83 --> sdb (w95
boot)
        map-drive=0x80
          to=0x83
        map-drive=0x83
          to=0x80
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 6.1 files were on /fs0 = /dev/hda3.

I *think* that the problem was associated with /dev/sd3
which has restriced permissions:-
brw-rw----   1 root     disk       8,  17 May  5  1998
/dev/sdb1
brw-rw----   1 root     disk       8,  18 May  5  1998
/dev/sdb2
brw-------   1 root     disk       8,  19 May  5  1998
/dev/sdb3
brw-rw----   1 root     disk       8,  20 May  5  1998
/dev/sdb4
brw-rw----   1 root     disk       8,  21 May  5  1998
/dev/sdb5

Perhaps some connection with bug #6287?

Hope this is useful.

Comment 1 adrian.lawrence 1999-10-29 18:19:59 UTC
The comment about permissions on /dev/sdb3 above were incorrect.
Changing those have no effect. /dev/sdb3 prompted an earlier bug when
boot-RHEA-1999:044.img was used without updates-RHEA-1999:045.img.

Sorry for that misleading information.

Comment 2 adrian.lawrence 1999-10-30 11:09:59 UTC
My reference to the same (?) bug in 44.img should have been #6278:
digits transposed :-(

Comment 3 adrian.lawrence 1999-10-30 11:19:59 UTC
As noted in #6278, bugs #5555 and #5944 seem to be similar.

------- Additional Comments From   11/01/99 15:50 -------
You might appreciate explicit fdisk dumps:-
   Device Boot    Start       End    Blocks   Id  System
/dev/hda1             1      1023    515560+  83  Linux
/dev/hda2          1024      1284    131544   82  Linux swap
/dev/hda3          1285      5824   2288160   83  Linux

   Device Boot    Start       End    Blocks   Id  System
/dev/hdb1             1      2055  16506756   83  Linux

   Device Boot    Start       End    Blocks   Id  System
/dev/sda1             1        50    207669    6  FAT16
/dev/sda2            51      1019   4025226   83  Linux

   Device Boot    Start       End    Blocks   Id  System
/dev/sdb1   *         1       140    582088+   b  Win95 FAT32
/dev/sdb2           141       400   1081080    7  HPFS/NTFS
/dev/sdb3           401       432    133056   82  Linux swap
/dev/sdb4           433      1018   2436588   83  Linux

Hope this helps. I have tried to be comprehensive.


------- Additional Comments From   11/07/99 17:30 -------
FYI, I am receiving the same error on an FTP install.  It seems the
previous 'Anaconda fix' still needs work.

Comment 4 Jay Turner 1999-11-30 18:45:59 UTC
There is reason to believe this bug is error message is a result of having
corrupt or incomplete RPM files in the source directory.  See details in bug
#6438

*** This bug has been marked as a duplicate of 6438 ***

Comment 5 adrian.lawrence 1999-12-03 20:46:59 UTC
This is to confirm that there was a corrupt rpm file. Probably an accident when
downloading an update which should have gone to another directory after two
successful installs onto oter machines :-(

Sorry to have missed that. Glad to confirm diagnosis.