On Sat, 6 Aug 2005, Axel Thimm wrote: > This is more an RHEL4 question to be honest, but since there are > anaconda experts around, I hope to be lucky :) I'm no anaconda expert, but recently had the opposite problem of making an unknown device (new flavour of intel gigabit NIC) known to anaconda. It turned out an appropriate entry in modules/modules.pcimap on the initrd is needed, otherwise anaconda would ignore the chip. So I figure removing all traces of your HBAs from this file would do. Stephan > I'm setting up automatic install systems for a variety of different > EL4 type systems including among other SAN cluster nodes. The > automatic install is a hook on anaconda emulationg (or replicating) > what some Debian folks know as FAI. > > My concern is that configuring servers and cluster nodes is "too easy" > now, and staf members might with a typo in the config file install on > the wrong device as a system disk. E.g. wipe the SAN device insetad of > the system disk (for example: Some nodes have and sda system disc, > others an cciss/c0d0 and sda is the SAN device) > > Knowing that I will never install a system on a SAN device, is there > an easy way to remove qla2xxx support in anaconda's bootstraping? That > would be the safest way to allow any staff member to wildly > (re)install nodes attached to the storage, as I will know that during > installation the SAN will be invisible. > > Disabling the port on the switch does not help, as this safety > precaution will soon be skipped by staff members, until someone really > makes that typo ... > > Ideally I would only need to modify the initrd or similar, and not > have to rebuild anaconda :/ > > Thanks! > -- ---------------------------------------------------- | Stephan Wiesand | | | | | | DESY - DV - | phone +49 33762 7 7370 | | Platanenallee 6 | fax +49 33762 7 7216 | | 15738 Zeuthen | | | Germany | | ----------------------------------------------------