l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2001 Dec 30 16:43

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox] Re: Shwaine's custom Boot Disks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox] Re: Shwaine's custom Boot Disks



On Sat, 23 Jun 2001, Shwaine wrote:
> I'm following the Linux Bootdisk HOWTO. The HOWTO gives a couple
> of options at some points, so here's what I did at those points. 
> I chose 
> the LILO option in it to install the kernel. 

Have not played with LILO for the EBD/Root disk creation, but have used
LOADLIN.EXE.

> I used a ramdisk in 
> order to 
> build the root file system.

 (I prefer using dd to write out a 2.0Mb file with 512 byte blocks and
then use losetup to connect it up to a loopN device, and then mkfs -t
minix /dev/loopN and then mount it for direct access to the image. Once
done, I can sync and umount the mounted image and losetup delete the
loopback setup. The resulting file can be compied and then compressed.)

> I also custom-built the kernel and fine-
> tuned 
> the root file system so both can fit on a 1600k formatted floppy 
> (fdformat 
> /dev/fd0u1600). The problem is not with the booting. It boots just 
> fine. It 
> just always says "RAMDISK: Couldn't find valid ramdisk image at 397" 
> (397 is the KERNEL_BLOCKS variable mentioned in the HOWTO) once 
> it gets to the point of trying to load the root system.

Perhaps I am being bone-headed here, but if booting works just fine - with
only an error reported, then why not use the tool as-is? If I am
misunderstanding this as stated, and it is just booting fine until it gets
to the mounting of rht root disk, then that would make more sense.

When you have the present root image on a second disk, you say it works
great, but when the same image is on the same disk as the kernel , you get
problems. If it just stops at that point, you may try testing lilo (if
that is what you are using) and specify the addition arguement of
"root=root.bin" (or whatever name you save that root image as on your
kernel booting floppy.) (Would also like to make sure you are using the
same kernel boot disk and root image for both examples where a single disk
system does not work, but a dual disk system works great.)

> I'm wondering 
> if the 
> problem is using 1600k formatting instead of 1440k. I haven't yet tried 
> specifying the disk geometry in LILO to check that. I really don't have
> many other files I can pare down to get it to fit into 1440k. Oh,
> and this
> is a Slackware -current (downloaded June 18th) system using the 
> 2.2.19 kernel. I have scripts to create the disk that I could post, but 
> they are rather long.

Debian's EBD and root disks in the past used minix filesystems, when
uncompressed were larger than 1.44 Mb. I have not tried to use the 1.6Mb
format of floppies with the root disks. Your thought on changing to a
1.44Mb image or perhaps creating a 2Mb minix filesystem for your root, and
then comrpessing it will manage to allow it to fit on a 1.44Mb floppy
seem like good ideas and ones that I would try if I were you..

When I made mine, I also used gzip compressed Minix Filesystems written
directly to /dev/fd0 for the separate root disk or save as root.bin on the
same disk as the kernel.

I'd like to hear how the 1.44Mb tests work out. Could you keep us
informed?

Thanks,
-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html
     Systems Department Operating Systems Analyst for the SSU Library


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.