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/[EMAIL PROTECTED]: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.
