However, if I boot from that CD, the boot loader reads in the kernel
and then asks me to insert disk 2 ;-) Needless to say that there is no
such thing as a disk 2 for the 2.88M image.
Since the main purpose of the 2.88M is to work as a boot image for
CDs, I believe that the size of the created image should always be 5760
sectors, regardless of the actual kernel and ramdisk size. And the boot
loader should definitely *not* ask for a second disk. I'm more than
happy to fix this, if anybody could give me some pointers on these
issues.
Cheers
,
Rene
> However, if I boot from that CD, the boot loader reads in the kernel
> and then asks me to insert disk 2 ;-) Needless to say that there is no
> such thing as a disk 2 for the 2.88M image.
There, I just pulled up to netbsd-1-5 the fix I committed to the trunk
for this problem.
It will work after your next update.
--
-- Jason R. Thorpe <tho...@zembu.com>
Actually, that revision didn't work for me.. ustarfs needs a magik file
to see that it has a size other than the default 1.44M. So I added
that one in the next revision. I forgot to send a pullup request so far.
I also added padding to the boot-big floppy, so that mkisofs likes it.
- Frank
Thanks a lot, Jason and Frank, for fixing this so quickly! I will try
out the new image in the next minutes. However, I believe, that there
may be a
mv ${IMAGE}.tmp ${IMAGE}
missing at the end of the ${PAD} specific part in
"basesrc/distrib/i386/floppies/bootfloppy-common/Makefile.inc" (at least
in the 1.5 release branch, I haven't checked the trunk). Otherwise the
unpadded image will be used for 'make release' even if PAD=yes.
Cheers
,
Rene
> mv ${IMAGE}.tmp ${IMAGE}
There is more to it than that. It seems like a pullup of
"basesrc/distrib/i386/floppies/bootfloppy-common/Makefile.inc" 1.27 is
required to fix this properly and make ${IMAGE}.tmp work.
Cheers
,
Rene