[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]



Previously, I proposed a patch to allow auto-detection of an installation on
a hard drive if no device was specified, e.g.

Command line: method=hd::/path/to/install/files
Kickstart: harddrive --dir=/path/to/install/files

Regarding this patch, Jeremy asked:
> Is the problem you're trying to solve the fact that device naming
> isn't all that reproducible from one machine to another? If so, is
> there anything about the device that you're having people install from 
> that could be used instead as the device key (much like the
> biosdisk/part stuff)

After some more research, it appears the biosdisk/part mechanism may well be the solution we are looking for. With the bioses we have tested, when the system is booted from the usb storage, and the edd kernel module is inserted, the usb device appears as bios disk 80. We understand that this is bios dependent, and thus it is possible that the bios may number a device as 81, 82, etc. and still boot from it. In practice though, it seems 80 is a safe bet, at least for the hardware configurations we are considering.

However, we have found a few minor issues with the current biosdisk/part implementation in anaconda.

The first is a timing issue. Some USB devices take a long time to "stabilize" and by that time, the disk map table (mbrSigToName: which maps the BIOS disk number to the device name) is already created; once this table is created it ie never recreated. So even if new devices are ready to be added to the this table, they never do.

The second is that method=bd is not available from the command line, but is available from the kickstart.

To address these issues we have created the attached patch.

The patch gets around the timing issue by adding a function findBiosDevice()
that first looks for a device name identified by a  BIOS device. If the device is not found, the loader sleeps for 5  seconds after which the disk map table is recreated (by calling the probeBiosDisks() function). After recreating the mapping, the device is searched for again; this process is repeated (at most) 24 times.

The amount of "sleeping time" is directly proportional to the time the device takes to stabilize. In the best case scenario, the device is ready before the findBiosDevice() function is called and there is no sleeping. In the worst case scenario, the user types in a BIOS device in the method string that doesn't exist, in which it takes ~2 minutes to raise an exception.  This approach follows a model set by Niels de Vos in a patch mentioned in a previous thread -


The patch addresses the second issue by exposing method=bd on the command line:


For example, if you want to install from the boot device (the BIOS disk number of which is 80 in all the cases we have tested) and the installation iso is on the device's first partition and the name of the directory is "/isos", the following command line argument would work:


Let me know what you guys think.  We are holding off on additional patch submissions for now.  One step at a time?


Attachment: methodbd.patch
Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]