> Uwe Dippel wrote: > > >But the kernels I have used until now (mainly Linux > and BSD) would load the drivers for the disk > >controllers, keyboard, even mouse, NIC and so forth > if I moved the single drive of a system >physically > as a single drive into a new box. The only item to be > moved eventually was a 'wd' to 'sd' >or similar. > > Yes, A Generic BSD kernel would discover devices > that it has internal Drivers for at boot up. > Solaris does not have a monolithic kernel so it only > loads drivers as requested. > > The process here is that the Utility devfsadm(1m) > ( which can be run manually for an inflight > reconfiguration ) is used in concert with the > contents of /etc/driver_aliases, to discover what > ardware exists on a given system . A software/driver > package for a particular bit of hardware is > supposed to update /etc/driver_aliases with the > relevant information. > > When devfsadm(1m) runs it updates > /etc/path_to_inst and the /devices directory > tree > ith the links to the driver it found form > /etc/driver_aliases . this then causes relevant > modload(1m) or modunload(1M) to be run. > > to touch the file /reconfigure means that the > system will run a background devfsadm(1M) run at > he next boot up. > > A Few years ago most workstation/desktop class PC's > all used a more or less standard > A/E-IDE disk interface. ( the list of supported > devices on any IDE driver for > linux/BSD/Solaris is long and booreing :-) ) > With the Introduction of SAS and SATA the picture > is fragmenting and you cant be > eaonably sure anymore that SATA driver for one > hardware works with another brand SATA > controller. > > //Lars
Under sparc, as long as you load the SUNWXCall cluster (Server plus OEM), with a touch reconfigure and if the system was copied over with ufs restore or dd, you needed to run the installboot, bot for i86pc the new command is installbgrub, when you use lucreate, the to create the new bootable partition, in moving a hard drive from old motherboard to a new mother board as was in my case, or from a old hard drive to a new one, you needs to check the /boot/solaris/bootenv.rc if it needs to be checked or updated for the correct value, which is maintained by the eeprom command like on sparc, also the luactivate if you used lucreate to copy over to the new hard drive, note this only maintains one copy of the /boot/grub/menu.lst per system file so that also needs make cure it is copied over to the new disk. Once Grub gets to be on par as the sparc OBP, the steps should be the same as sparc or any architecture, but it does not seem to be the case. This message posted from opensolaris.org
