Red Hat Bugzilla – Bug 66893
unable to re-read partition table
Last modified: 2007-04-18 12:43:15 EDT
Description of problem:
during install of 7.3.91:
The kernel was unable to re-read the partition table on /dev/
hda (Device or resource busy). This means Linux knows
nothing about any modifications you made. You should
reboot your computer before doing anything with /dev/hda.
| Ignore |
Steps to Reproduce:
boot system over network and issue command "dd if=/dev/zero of=/dev/hda bs=4k
pxe boot using Milan/beta2/i386/images/pxeboot/vmlinuz and
english, us keyboard, nfs image, dhcp, nfs server and directory as appropriate
3button ps2 mouse
have the installer automatically partition for you
* error dialog appears here, press "ignore" to continue
* error dialog appears five more times!
remove all partitions on this system
* error dialog appears here
* error dialog appears a second time
review - hda1 is 102MB /boot, hda2 is 58,032MB /, hda3 is 510MB swap
default boot loader config
dhcp network setup
utc-08 us pacific, dst, system uses utc
md5 and shadow
* now error dialog appears, press "ignore"
* error dialog appears a second time, press "ignore"
An error occurred trying to initialize swap on device hda3. This
problem is serious, and the install cannot continue.
Press Enter to reboot your system.
go to alt-f2, type "mknod /tmp/hda" and "fdisk -l /tmp/hda" results show all
the partitions are present.
If I repeat all the above except omitting the "dd" to blank the disk, (i.e.
leave the drive partitioned) then I get the final two "ignore" dialogs but
I have seen similar swap related problem on 20G hd where 512 swap start at
around 15G mark. I tried to install/upgrade 7.2 system to 7.3.90.
First 15G partition is for another OS.
The message says something about unable to format swap partition. I can repeat
the test and provide exact partition layout if needed.
upon booting the system, I got errors when the boot process tried to enable
swap. printed out a usage message for swapon, and then reported [FAILED].
however, when I log in and look at /proc/swaps all seems well. also, /etc/fstab
is as I expect and the disk is partitioned as I expect.
rebooted again and still get error when "Activating swap partitions"
Assigning to an engineer.
The swapon messages are unrelated... I'll try to reproduce later today and
track down what's going on
I can't reproduce this here -- I just get the "unable to read partition table,
would you like to reinitialize" dialog. Is this reproducible in Limbo?
this box has a removable ide carrier, and I'm pretty sure I swapped the drive
since I entered the previous stuff above. before I think it was a maxtor 60gb
drive. now it is an ibm 75gb drive. that may or may not be critical.
however, with limbo I retraced the steps above and the suspect messages did not
appear. I might be able to remember what the previous drive was, find it and
reinstall it if you would like to try that test.
Since I can't reproduce it at all, it might be useful. Also, note that we've
switched IDE layers in the kernel since beta2, so that may have fixed the
problem as well.
Created attachment 67308 [details]
lsof report when installer at "welcome" screen
Created attachment 67309 [details]
lsof output at "disk partitioning setup" screen
Created attachment 67310 [details]
lsof output at "automatic partitioning" screen
not sure it is exactly the same drive as before, but likely is. here is a go at
it using a maxtor 60gb drive
* boot diskless, "dd if=/dev/zero of=/dev/hda bs=4k count=100"
* boot nfs install of 7.0.92 (beta3)
get installer running. also, nfs mount a disk from the server where I can write
scratch files. there will be several attachments to go along with this dialog.
* welcome screen - see lsof attachment
* proceed... at "disk partitioning setup" get warning about unable to reread
partition table. see lsof attachment
* six instances of the unable to reread partition table warning dialog. then
the "automatic partitioning" screen comes up. see attachment
so the result of this is that it looks like anaconda itself has the drive open,
which prevents the kernel routine ide_revalidate_disk() from completing.
we are seeing similar behavior with RH7.3 as well as the beta. slight
differences in the timing of when /tmp/hda gets opened, then marked as
(deleted), then /dev/hda is opened.
and finally, I popped the ibm 75gb drive back in, dd'd zeros to it, and ran the
installer exactly in the fashion that I did for the maxtor 60gb. at the welcome
screen, lsof shows that /tmp/hda is not an open file for anaconda. in fact, the
device node for the drive is not opened until I reach the "automatic
partitioning" screen. then lsof shows the following
anaconda 89 root 23u BLK 3,0 156 /dev/hda
installation with the ibm drive worked. installation with the maxtor drive
failed when anaconda eventually reported that it could not create a swap
partition and this was bad and I had to reboot.
reviewing what I just submitted, I may have not been clear. to be concise:
with the maxtor drive, at the "welcome" screen:
anaconda 89 root 12r BLK 3,0 155 /tmp/hda
then at the "disk partitioning setup" screen:
anaconda 89 root 12r BLK 3,0 155 /tmp/hda
then at the "automatic partitioning" screen:
anaconda 89 root 12r BLK 3,0 155 /tmp/hda (deleted)
anaconda 89 root 24u BLK 3,0 156 /dev/hda
so because anaconda has the drive open, re-partitioning fails.
I can't begin to guess why this happens with the maxtor and not the ibm.
Further information/data points with regard to the 7.3 release CD installer.
Motherboard using VIA 82c686B IDE controller.
Maxtor: 2B020H1 20GByte FAILS
Western Digital: WD800BB-00BSA0 80GByte FAILS
IBM: IC35L040AVER07 40GByte WORKS
With the 7.3 installer, the '/tmp/hda (deleted)' entry shows up in the anaconda
process after selecting a partition method (automatic, manual fdisk, etc.) and
the next screen.
Therefore, it would appear to be related to the code to enumerate the available
Arjan -- this is really weird. Do you have any ideas on what's going on here?
Have you seen this with GinGin?
Closing due to inactivity. If you have any further information to add to this
bug, please feel free to reopen it.