Description of Problem: In our install, we install the OS to sda, and we have a section in %post that will automatically partition and mke2fs on any remaining disks. This does not work when you have an uninitialized partition table (eg. 'dd if=/dev/zero of=/dev/sdb bs=512 count=100' ). Fdisk returns with the error: Calling ioctl() to re-read partition table. Re-read table failed with error 16: Device or resource busy. Reboot your system to ensure the partition table is updated. And, in the system 'dmesg' output, I see this error: Device busy for revalidation (usage=2) When our 'mke2fs' runs, we get this error: /sbin/mke2fs: No such device or address while trying to determine filesystem size I believe that these errors are due to this (lsof output): sh 720 root 14u BLK 8,0 148 /tmp/sda (deleted) sh 720 root 15u BLK 8,16 149 /tmp/sdb (deleted) which corresponds to this 'ps aux' output: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 1.4 0.0 0 0 ? SW 06:11 0:03 [swapper] root 2 0.0 0.0 0 0 ? SW 06:11 0:00 [keventd] root 3 0.0 0.0 0 0 ? SWN 06:11 0:00 [ksoftirqd_CPU0] root 4 0.1 0.0 0 0 ? SW 06:11 0:00 [kswapd] root 5 0.0 0.0 0 0 ? SW 06:11 0:00 [kreclaimd] root 6 0.1 0.0 0 0 ? SW 06:11 0:00 [bdflush] root 7 0.1 0.0 0 0 ? SW 06:11 0:00 [kupdated] root 8 0.0 0.0 0 0 ? SW< 06:11 0:00 [mdrecoveryd] root 9 0.0 0.0 20 20 tty1 S 06:11 0:00 linuxrc root 10 0.0 0.0 20 20 tty1 S 06:11 0:00 linuxrc root 11 0.9 2.1 8072 5372 tty1 S 06:11 0:02 /usr/bin/python / root 24 0.0 0.0 0 0 tty1 SW 06:11 0:00 [khubd] root 46 0.0 0.0 0 0 tty1 SW< 06:11 0:00 [loop0] root 47 0.0 0.4 2020 1084 tty2 S 06:11 0:00 -/bin/sh root 75 6.6 0.8 15440 2088 tty1 S 06:11 0:15 /usr/X11R6/bin/XF root 77 31.3 17.1 48552 43908 tty1 S 06:11 1:09 /usr/bin/python / root 106 0.0 0.7 3480 2000 tty1 S 06:12 0:00 /usr/bin/python / root 720 0.0 0.4 2420 1156 tty1 S 06:15 0:00 /bin/sh /tmp/ks-s root 736 0.0 0.2 2632 720 tty1 R 06:15 0:00 ps aux Note that process ID 720 is the '/bin/sh' process running %post. I am attaching our kickstart %post section, as well as the lsof, and ps listing. Please note that this process works perfectly on any disk, except one that has zeros in the partition table. Version-Release number of selected component (if applicable): Red Hat Linux 7.2 (gold) How Reproducible: Use the attached kickstart file on a two-disk scsi system. write zeros to the partition table of the second disk.
Created attachment 33378 [details] kickstart %post section
Created attachment 33379 [details] dmesg output (after first 'fdisk' attempt). Note the last line.
Created attachment 33380 [details] lsof output, from before any partitioning (fdisk) takes place. Note "/tmp/sdb (deleted)" entry.
Created attachment 33381 [details] ps aux output
Created attachment 33382 [details] stderr output from kickstart file.
Created attachment 33383 [details] stdout output from kickstart file.
In addition, anaconda gives the following error on VT3 during partitioning (from memory, may be slightly off): zeroMBA specified but invalid partition table specified on sdb I would like to postulate that anaconda is missing a "close" in the error-path, and all of it's children are inheriting this open file descriptor.
Jeremy please look at this report.
Yes, the diskset is not getting closed prior to the end of the installation... testing a small update to fix this now
katzj, any progress with this?
Working on this and a few other things at once. Original patch still leaves something with a dangling reference to the disk.
Is the patch working now?
Nope, and still not sure what's holding the reference
Any update on this?
Nope, still looking off and on when I'm not being pulled in ten other directions though
We're currently hitting other areas where partition tables aren't being reread properly in Hampton, so hopefully cleaning some of those up will help with this one too. If not, it should at least be easier to figure out at least where it's leaking with some of the other cleanups.
Still doesn't seem to get it. Matt -- when there's a parted exception, are the disk references being closed properly?
Deferring to future release.
I am hitting this in RH 8.0 -Final-.
Created attachment 77065 [details] script that fails in %post
just created a workaround for this issue. It doesn't address the underlying bug, but it does work around it nicely. Instead of using /dev/sdb1 as the PV for the VG, I am just using /dev/sdb directly. New script will be attached. Please let me know if you know of anything that will break because of this.
Created attachment 77067 [details] updated script to work around bug.
There have been no guarantees made about what commands can be run in the %post, other than the installed system will be available as /mnt/sysimage. Your only option is to change the way you create your partitions so that you decide which drives will be used for what filesystems in the %pre, then write out the appropriate kickstart partitioning commands to a temporary file, and finally include that temporary file using the kickstart %include mechanism we added in 7.3 to address this exact type of on-the-fly dynamic kickstart situations. This way you don't have to worry about catching this kind of side-effect as you are now experiencing during the beta cycle when we could do something about it. Anyhow, to do this in a %pre you would just have something very similar to your %post script that would run and detect the available block devices. You then can write out ks 'part' rules for swap, '/', '/boot', etc as well as rules for the remaining devices to go into the '/data' LVM mount.
This issue report has been quiet for some time and I wanted to check if there was any further comments before I close it.
Assuming based on the lack of response to msf's comment that this isn't a problem any more. Please reopen if it is.