Bug#263178: update(install does not modify boot_dev and boot_osflags)
On Wed, Aug 04, 2004 at 01:42:00PM +0200, Steffen Grunewald wrote:
> > If you wish to submit further information on your problem, please send
> > it to 263178@bugs.debian.org (and *not* to
> > submit@bugs.debian.org).
>
> According to my somewhat limited research, an interface to the SRM would
> be available if CONFIG_SRM_ENV was set to "y" during kernel build.
> Unfortunately, this is not the default :-(
OK, this seems to be fixed now (= boot.img as of Aug 4, 5423316 bytes),
I can see /proc/srm_environment while the base installation is going on.
> If such a kernel was used during system install, one might set
> bootdef_dev to the SRM name of the disk the aboot loader has been
> installed to, and boot_osflags to "0" indicating that the default
> setup is to be used.
Unfortunately, there's no modification visible yet.
(The most likely explanation would be that work is still in progress, so
I at least can confirm that CONFIG_SRM_ENV did work.)
OK, let me do the whole thing from scratch.
First, I look at the settings in SRM:
>>>show boot*
boot_dev ewa0.0.0.3.1
boot_file ""
boot_osflags ""
bootdef_dev dka0.0.0.6.1 (set manually days before)
>>>show auto*
auto_action RESTART
>>>set auto_action halt
Now, I boot from network (image Aug 4) and do the initial install stuff,
this time I want to use the second disk (so I don't destroy what I
already built on sda). This disk, according to "show dev" in SRM speak
is called "dka100.1.0.6.1", we might need this later.
OK, while the installation is going on, we can look at
/proc/srm_environment/named_variables:
auto_action HALT
boot_dev MOP 1 3 0 0 0 3 0
booted_dev BOOTP 1 3 0 0 0 3 0 <MAC> 1
bootdef_dev SCSI 1 6 0 0 0 0 0
Both disks are connected to the (internal) QLogic ISP1020 adapter
which is recognized as scsi1 because a ncr53c895 PCI card was detected
first (no problem here), ID 0 and 1.
OK, meanwhile I got the Installation complete dialog window, so I
suppose swriteboot has been done (virtual package bootable-system),
so I look into /proc/srm_* again: no changes visible.
Anyway, getting close. Thanks!
Now if the OpenOffice problem could be solved quickly...
Steffen
--
Steffen Grunewald * * * Merlin cluster admin (http://pandora.aei.mpg.de)
Albert-Einstein-Institut (MPI Gravitationsphysik, http://www.aei.mpg.de)
Science Park Golm, Am Mühlenberg 1, 14476 Potsdam, Germany
e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
Reply to: