A little background... I work on a system that uses PXE booting for the majority of the nodes. Several of these nodes have local hard drives that are used for persistent storage of data needed for archival purposes. There are specific circumstances under which these nodes need to rebuild the hard disk array and reformat the partitions in order to clear out data that is no longer necessary / applicable (I don't write the software, I just have to make it work).

The problem I'm running into is that when the node needs to rebuild the drives, it stops the normally running application and starts a special "build" application which handles the drive rebuild and reformat. At some point in there, the drives become no longer visible to the OS (running fdisk -l shows no drives) and when the "build" application tries to run, it fails. The only solution is to reboot the box, at which time the drives are again recognized and the build application can do its job.

What I'm wondering is if there is a way to force the OS to re-inspect the system for drives after they go missing.

We're using Redhat 5.2 with the stock 2.6.18-92 kernel (with many unnecessary kernel modules pared out to keep the diskless image's size manageable). The hard drives are two 300GB SAS drives and the software uses mdadm to create a few RAID0 arrays and formats them as ext3.

  • 2
    Could you try if you see the disks after a partprobe? Is the "special build application" just a binary or another OS booted via PXE? – weeheavy Sep 17 '10 at 12:34
  • I'll give partprobe a try and let you know. The build application is "just a binary" (in reality it may just be a series of bash scripts, I'm not sure). It is definitely not another OS being booted though. The goal here is to not reboot the box in order to get this to work. – Justin Bennett Sep 17 '10 at 13:15
  • 1
    Well, partprobe didn't seem to help, but I did find what I believe is a fix. Running udevtrigger seems to prompt the system to recheck things and after about 20 seconds, the drives reappear and doing an fdisk -l produces the output I'm expecting. – Justin Bennett Sep 17 '10 at 15:03
  • @weeheavy Thanks for your suggestion. It got me thinking and led to trying udevtrigger. – Justin Bennett Sep 17 '10 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.