[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: