Rather than employ the usual and familiar (to me) method of forcing
100baseTX full-duplex mode on a qfe device (by editing /etc/system), I
decided to try the /kernel/drv/qfe.conf approach. Evidently, I supplied
the incorrect register values in that file, and I've reduced my machine to
a repeat panic-booting hunk of plastic and metal.

The specific error that flashes up the screen on successive reboots is:

Out of range register specification from device node <qfe>

(Followed by reams of incomprehensible data, presumably the contents of
various registers.)

The machine is an Enterprise 4000 running Solaris 8 and boasting OpenBOOT
version 3.2.7.

I've set the configuration-policy to 'board', and I thought I'd be able to
disable the board holding the qfe with 'setenv disabled-board-list 0', but
that has not been successful. Also failed: boot -s; and boot -r.

How can I nullify the contents of the /kernel/drv/qfe.conf file from the
OpenBOOT prompt?

Does anyone have any advice? I'm a bit lost.

Thanks,
Jonathan.

On Thursday 20 May 2004 2:50 pm in comp.sys.sun.admin Jonathan Kop wrote:


> How can I nullify the contents of the /kernel/drv/qfe.conf file from the
> OpenBOOT prompt?

Put cdrom software 1/2 in the drive
boot cdrom -s
mount your root partition on /a
fix the offending file
sync; reboot


--
My real address is crn (at) netunix (dot) com
WARNING all messages containing attachments or html will be silently
deleted. Send only plain text.

Yesterday, Chris Newport wrote:

CN> On Thursday 20 May 2004 2:50 pm in comp.sys.sun.admin Jonathan Kop wrote:
CN>
CN> > How can I nullify the contents of the /kernel/drv/qfe.conf file from
CN> > the OpenBOOT prompt?
CN>
CN> Put cdrom software 1/2 in the drive
CN> boot cdrom -s
CN> mount your root partition on /a
CN> fix the offending file
CN> sync; reboot

Quite right -- thanks, Chris. My situation was slightly complicated by my
root partition being a Solstice DiskSuite mirror, but I booted off the
CD-ROM, removed the rootdev directive from /etc/system, edited /etc/vfstab
accordingly, deleted the /kernel/drv/qfe.conf, and then rebooted, after
which I reconstructed the mirror.

Thanks for the advice.

- Jonathan.

In comp.sys.sun.hardware Jonathan Kop <jkop@za.uu.net> wrote:
> Yesterday, Chris Newport wrote:
> CN>
> CN> Put cdrom software 1/2 in the drive
> CN> boot cdrom -s
> CN> mount your root partition on /a
> CN> fix the offending file
> CN> sync; reboot

> Quite right -- thanks, Chris. My situation was slightly complicated by my
> root partition being a Solstice DiskSuite mirror, but I booted off the
> CD-ROM, removed the rootdev directive from /etc/system, edited /etc/vfstab
> accordingly, deleted the /kernel/drv/qfe.conf, and then rebooted, after
> which I reconstructed the mirror.

There's more than one way to solve this, but imagine if you were
working on a remote machine, this CD boot trick wouldn't work. The
easiest way to solve the problem that doesn't require booting off CD is:

boot -a

When it asks which file you want to use for the system file just
tell it to use /dev/null. You'll still have the solstice disksuite issue
to deal with, but that's easy enough.

P.S. If you can't remember this, just remember to 'boot -ass' when
you've been an ass and screwed up the system file, if you're British
and/or you need to reconfig while you're at it then a 'boot -arse' works
just as well. :-)

Boot cdrom -s then mount the disk and VI the file
If you need any Hardware call me 847-468-8900
"Jonathan Kop" <jkop@za.uu.net> wrote in message
news:20040520153532.L43958@wataru.so.cpt1.za.uu.ne t...
> Rather than employ the usual and familiar (to me) method of forcing
> 100baseTX full-duplex mode on a qfe device (by editing /etc/system), I
> decided to try the /kernel/drv/qfe.conf approach. Evidently, I supplied
> the incorrect register values in that file, and I've reduced my machine to
> a repeat panic-booting hunk of plastic and metal.
>
> The specific error that flashes up the screen on successive reboots is:
>
> Out of range register specification from device node <qfe>
>
> (Followed by reams of incomprehensible data, presumably the contents of
> various registers.)
>
> The machine is an Enterprise 4000 running Solaris 8 and boasting OpenBOOT
> version 3.2.7.
>
> I've set the configuration-policy to 'board', and I thought I'd be able to
> disable the board holding the qfe with 'setenv disabled-board-list 0', but
> that has not been successful. Also failed: boot -s; and boot -r.
>
> How can I nullify the contents of the /kernel/drv/qfe.conf file from the
> OpenBOOT prompt?
>
> Does anyone have any advice? I'm a bit lost.
>
> Thanks,
> Jonathan.

"B.M. Wright" <bmwright@deuce.xmission.com> writes:

> There's more than one way to solve this, but imagine if you were
> working on a remote machine, this CD boot trick wouldn't work. The
> easiest way to solve the problem that doesn't require booting off CD is:
>
> boot -a
>
> When it asks which file you want to use for the system file just
> tell it to use /dev/null. You'll still have the solstice disksuite issue
> to deal with, but that's easy enough.
>
> P.S. If you can't remember this, just remember to 'boot -ass' when
> you've been an ass and screwed up the system file, if you're British
> and/or you need to reconfig while you're at it then a 'boot -arse' works
> just as well. :-)

Hey wow, thanks, that's so simple even I can probably remember it!

Chris
--
Chris Morgan
"Post posting of policy changes by the boss will result in
real rule revisions that are irreversible"

- anonymous correspondent

> There's more than one way to solve this, but imagine if you were
> working on a remote machine, this CD boot trick wouldn't work. The
> easiest way to solve the problem that doesn't require booting off CD is:

and here's another one

i recently installed Sun SCTP packages on an incompatible version of S9 -
resulting in a similar panic
crash when the kernel was loading. i managed to recover by booting to single
user mode from a network
install server because the machine does not have an internal CDROM.

regards
AT