Re: RFC: [powerpc] fixing quik-installer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 28 May 2006 20:55:09 -0400
Joey Hess <joeyh@debian.org> wrote:
>
> Daniel Dickinson wrote:
> > I plan on fixing quik-installer so that it actually works
> > (apparently it currently never works).
>
> IIRC Colin wrote it but may have never actually been able to test it
> himself, so I'm not really suprised if it's never really worked.
>
> Is the problem just that you need a serial console to see the system
> boot up though? That doesn't sound like a total "never works", just
> annoying if you don't have one..
Well, not quite. The quik-install always fails with an error message
(I suspect it's using mkofboot which is for yaboot, and because we're
not using yaboot it becomes unhappy). I think quik actually gets
installed to the master boot record just fine, but the failure is the
OpenFirmware update step. When I modify the firmware by hand the boot
works, but I have always also run quik again to make sure it was
installed[1].
The problem for quik is that the Apple ROM's don't read the master boot
record, they look for the first partition with the correct attributes
(this is according to the yaboot and bootstrap(8) documentation. Yaboot
makes itself look like such a partition (which is why it is important
that it be the first os partition on the disk), but quik installs
itself in the boot sector and needs the OF boot-device to point to the
device and partition containing the boot blocks[1]. For my scsi drive
that's /bandit/ohare/mesh/sd@0:0 (mesh is scsi controller, and sd@0 is
the first scsi hard drive, while :0 is the mbr (partition #0), :1 would
be the partition table).
So, on my system, I need to manually do a 'setenv
boot-device /bandit/ohare/mesh/sd@0:0' (or on the ide system 'setenv
boot-device /bandit/ohare/ata@20000/ata-disk@0:0'). This step is what I
want to make happen, but could render the system unbootable if I get it
wrong.
If I don't do this the system just boots with a flashing question mark,
indicating the mac didn't find any recognizable boot partitions, or, if
there is a MacOS partition, boot into the MacOS.
Also, not having a console means you're SOL if something going wrong
during the boot process (i.e. anytime you'd be asked for input before
multi-user (and therefore virtual terminals), such as being dropped
to root due to failed fsck).
> > This would involve modifying the
> > openfirmware variables for the boot device, as well as the of
> > variables for console. The reason I'm requesting comments, is that
> > it would mean using d-i could result in a system that won't boot
> > *anything* until you open the case and reset the nvram. =20
> =20
> > Maybe it'd be okay with a big scary warning and a pointer the manual
> > section that I'd add with how to recover (basically the above not on
> > resetting nvram, only prettier and more verbose, and with pointers
> > to other web pages with cuda/nvram info)
>
> IMHO you need both the big scary warning and the recovery
> instructions.
I'll see if I can come up with reasonable instructions, and a pointer to
the manual, for a debconf screen.
[1] I'll test just setting boot-device (which will tell me if
quik-installer is installing quik okay)
- --
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEgD3+hvWBpdQuHxwRAleOAJ43652SLEYyb0E7yjNcmTvzXm539gCfRFqr
ZqimodwjyT54l3fewrg9AkU=
=bo/V
-----END PGP SIGNATURE-----
Reply to: