Re: New Quik available
Daniel Jacobowitz wrote:
> On Thu, Apr 06, 2000 at 03:31:07PM -0400, Adam C Powell IV wrote:
> > Okay, removed it, now I get:
> >
> > Second-stage QUIK loader
> >
> > Fatal error: Unable to open filesystem
> >
> > Unable to load /etc/quik.conf
> > boot:
> >
> > So, with -N it loads quik.conf, prints the "Booting..." message, tries to boot
> > from label "linux", but can't find the image. (I X-copied and pasted the
> > filename from quik.conf and listed, to make sure it was accurate; the file is
> > there.)
> >
> > Without -N it doesn't even load quik.conf. :-(
>
> Oh, I misunderstood you, I see. Hmm.
>
> You can specify partitions and filenames on the boot line (like
> 8/vmlinux). Does that work?
Ah, so that's how you use that! (I had tried sda4/vmlinu... and
scsi/sd@5:4/vmlinux... several other possibilities, the messages are not so
clear.) Yes, the zip partition is 4, and 4/boot/vmlinux-2.2.15pre17-atydbg
root=... does indeed boot successfully.
> Is the thing being pointed to a symbolic link? As I remember your comments about
> automounting a zip to boot from, I suspect it just doesn't know where your kernel
> is.
It isn't a symbolic link *from* the zip disk, but /boot in root (/dev/hdb6) is
symlinked *to* /zip/boot (/zip is symlinked to misc/zip, where the zip disk is
automounted). So when it's trying to boot, it should look at the zip disk and see
/boot/vmlinux-2.2.15pre... and boot just fine, right?
Could that be confusing quik? With my patch, it seems to find /etc/quik.conf
(which is symlinked to /zip/etc/quik.conf, etc.) just fine. But quik only calls
resolve_to_dev() for the configuration file, it seems to just trust stat and the
st_dev field for the boot stages, can't tell about the kernel image...
Thanks again,
-Adam P.
Reply to: