Hi all,

I'm trying to create a root disk with a compressed file system.
I've already created a small linux kernel (2.6.8.521) on my Fedora 2 system
with a minimal configuration. I included support for ext2, floppy disk,
CD-ROM and ramdisk support.

I did a 'make bzdisk' to create this which does a syslinux on the boot disk.
I then added a kernel append option to the syslinux.cfg file:
append root=/dev/fd0

Then I followed the steps to create a separate root disk from the HOWTO.

I keep getting the error:
KERNEL PANIC : Unable to mount root fs on unknown block (2,0) which
corresponds to the floppy drive which is correct.

So the script I'm running to create the root disk has been pruned to the
following:
****
umount /mnt/ram
rm -rf /mnt/ram
dd if=/dev/zero of=/dev/ram0 bs=1k count=4096
/sbin/mke2fs -m 0 -N 2000 /dev/ram0
mkdir /mnt/ram
mount -t ext2 /dev/ram0 /mnt/ram
....
.... <here is where i make directories in /mnt/ram and copy various files
into them>
....
cd /mnt
umount /mnt/ram
dd if=/dev/ram0 bs=1k | gzip -v9 > rootfs.gz
dd if=rootfs.gz of=/dev/fd0 bs=1k
***
Well, turns out that there's no space on the floppy for the compressed file
system. The last dd command complains that it ran out of space on /dev/fd0.
When I do:
ls -l on rootfs.gz, I get:
-rw-r--r-- 1 root root 2913799 Oct 29 19:41 /mnt/rootfs.gz

This is too big. It's not going to fit on my floppy disk. I've even resorted
to commenting out all the lines in my script that copies the files for the
filesystem and it's still too big!

How do I get around this? Even with no files in the directory structure,
just doing the mke2fs gives me too big a rootfs.gz file. Does anyone see
anything I'm doing wrong? Is there something else I can do?
or with newer linux systems, can you not do this kind of thing anymore?

***********
Another approach: Since this looks like a space issue, can I just burn the
root filesystem onto a CD? and then do:
append root=/dev/hdb (where /dev/hdb is my CDROM)
[although this also gave me a kernel panic: couldn't find fs on (0,0) ]

If this does work, how will the kernel know where on the CD to find the
filesystem?

any help would be appreciated!

thanks,

Madhu
madhu_lists@yahoo.com

B. Madhusudan <madhu_lists@yahoo.com> wrote:
> Well, turns out that there's no space on the floppy for the compressed file
> system. The last dd command complains that it ran out of space on /dev/fd0.
> When I do:
> ls -l on rootfs.gz, I get:
> -rw-r--r-- 1 root root 2913799 Oct 29 19:41 /mnt/rootfs.gz
>
> This is too big. It's not going to fit on my floppy disk. I've even resorted
> to commenting out all the lines in my script that copies the files for the
> filesystem and it's still too big!

Better make it smaller. See tomsroot/boot disk for an example.

> How do I get around this? Even with no files in the directory structure,
> just doing the mke2fs gives me too big a rootfs.gz file. Does anyone see

It's the same size! Your data is still there! You just erased the
connections from the file system.

Next time start with a zeroed device, and do a mke2fs on it.

> anything I'm doing wrong? Is there something else I can do?

Yes. Putting too much stuff on. Yes. Put less on.

> or with newer linux systems, can you not do this kind of thing anymore?

No. Yes you can.

> ***********
> Another approach: Since this looks like a space issue, can I just burn the
> root filesystem onto a CD? and then do:
> append root=/dev/hdb (where /dev/hdb is my CDROM)

Sure. Just like the distros do. You can even have it on disk, or
available by tftp, or nfs ...

Peter

"Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
newsbfb52-ip5.ln1@triangulo.it.uc3m.es...
> B. Madhusudan <madhu_lists@yahoo.com> wrote:
>> Well, turns out that there's no space on the floppy for the compressed
>> file
>> system. The last dd command complains that it ran out of space on
>> /dev/fd0.
>> When I do:
>> ls -l on rootfs.gz, I get:
>> -rw-r--r-- 1 root root 2913799 Oct 29 19:41 /mnt/rootfs.gz
>>
>> This is too big. It's not going to fit on my floppy disk. I've even
>> resorted
>> to commenting out all the lines in my script that copies the files for
>> the
>> filesystem and it's still too big!
>
> Better make it smaller. See tomsroot/boot disk for an example.

ok, will look at this. thanks for the tip.

>> How do I get around this? Even with no files in the directory structure,
>> just doing the mke2fs gives me too big a rootfs.gz file. Does anyone see
>
> It's the same size! Your data is still there! You just erased the
> connections from the file system.
> Next time start with a zeroed device, and do a mke2fs on it.
>
>> anything I'm doing wrong? Is there something else I can do?
>
> Yes. Putting too much stuff on. Yes. Put less on.

i don't understand this... what do you mean my data is still there? if all i
do is a mke2fs but never do any of the mkdir(s) or cp(s) of the system files
necessary for the root fs, then how is my data still there?

i am starting with a zeroed device and doing a mke2fs on it.
as seen here:

dd if=/dev/zero of=/dev/ram0 bs=1k count=4096
/sbin/mke2fs -m 0 -N 2000 /dev/ram0
mkdir /mnt/ram
mount -t ext2 /dev/ram0 /mnt/ram

(unless this is wrong... i also played with the size of the inodes but it
didn't seem to help very much in terms of reducing the size of the final
rootfs.gz)

madhu

B. Madhusudan wrote:

>> Yes. Putting too much stuff on. Yes. Put less on.
>
> i don't understand this... what do you mean my data is still there? if all i
> do is a mke2fs but never do any of the mkdir(s) or cp(s) of the system files
> necessary for the root fs, then how is my data still there?

.... if you dont zero out the partition, or write data
to a partition that has data on it, then the data that
was previously on that area of the partition is still
there.

you can actually blast away a partition, split it up
into two three four partitions and create filesystems;
the underlying data that previously existed will still
be there, provided nothing gets written.
--
<< http://michaeljtobler.homelinux.com/ >>
Egotism is the anesthetic given by a kindly nature to
relieve the pain of being a damned fool. - Bellamy Brooks

B. Madhusudan <bmp4153@hotmail.com> wrote:
> "Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
> newsbfb52-ip5.ln1@triangulo.it.uc3m.es...
> > B. Madhusudan <madhu_lists@yahoo.com> wrote:
> >> How do I get around this? Even with no files in the directory structure,
> >> just doing the mke2fs gives me too big a rootfs.gz file. Does anyone see
> >
> > Yes. Putting too much stuff on. Yes. Put less on.
>
> i don't understand this... what do you mean my data is still there? if all i

What I said. Removing stuff only nulls metadata, not data. This is a
basic fact about unix (and other o/s's too!), no?

> do is a mke2fs but never do any of the mkdir(s) or cp(s) of the system files
> necessary for the root fs, then how is my data still there?

Because it never went anywhere.

> i am starting with a zeroed device and doing a mke2fs on it.

If you start with a zeroed device and mkfs it then it compresses to
virtually nothing.

betty:/tmp% dd if=/dev/zero of=/tmp/ram0 bs=1k count=4096
4096+0 records in
4096+0 records out
4194304 bytes transferred in 0.059897 seconds (70025225 bytes/sec)
betty:/tmp% /sbin/mke2fs /tmp/ram0
mke2fs 1.35 (28-Feb-2004)
/tmp/ram0 is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1024 inodes, 4096 blocks
204 blocks (4.98%) reserved for the super user
First data block=1
1 block group
8192 blocks per group, 8192 fragments per group
1024 inodes per group

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
betty:/tmp% gzip /tmp/ram0
betty:/tmp% ls -l /tmp/ram0.gz
-rw-r--r-- 1 ptb ptb 4438 Nov 1 00:29 /tmp/ram0.gz
betty:/tmp%

See? 4MB device compresses to 4K bytes, after a mke2fs from a zeroed
state. Compression of 1000:1.

Therefore you did not do that.


Peter

"Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
news:q69g52-qv1.ln1@triangulo.it.uc3m.es...
> B. Madhusudan <bmp4153@hotmail.com> wrote:
>> "Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
>> newsbfb52-ip5.ln1@triangulo.it.uc3m.es...
>> > B. Madhusudan <madhu_lists@yahoo.com> wrote:
>> >> How do I get around this? Even with no files in the directory
>> >> structure,
>> >> just doing the mke2fs gives me too big a rootfs.gz file. Does anyone
>> >> see
>> >
>> > Yes. Putting too much stuff on. Yes. Put less on.
>>
>> i don't understand this... what do you mean my data is still there? if
>> all i
>
> What I said. Removing stuff only nulls metadata, not data. This is a
> basic fact about unix (and other o/s's too!), no?

OK, I realize zeroing out the underlying data is important. After playing
around with my script and commenting out everything except for zeroing out
the device and making the file system and doing the gzip, I actually got it
down to 4KB. But then if i run exactly the same script again, the size of
the zip file keeps increasing. Shouldn't it stay the same??

I observed this behavior: I got down to a small 4 KB file, then kept adding
stuff to my root fs. So far, so good. Then when the zip file got too big,
thought I could comment out some lines so I'd get just under 1.4 MB. But
now, it refuses to go down. In fact every time I run the script, the file
size keeps increasing!

In fact, I used different /dev/ramX devices (thinking this might be the
problem). I did mknod on /dev/ram55, ram56, etc. and observed this behavior.
At the beginning of my script, I zero out these devices but the same thing
eventually happens... Is there a way to 'reset' the device to 0 or
something?

I'm not sure what's going on here...

***********
My script is as follows:

rm /mnt/rootfs.gz
umount /mnt/ram
rm -rf /mnt/ram
dd if=/dev/zero of=/dev/ram2 bs=1k count=4096
/sbin/mke2fs -m 0 -N 1000 /dev/ram2
mkdir /mnt/ram
mount -t ext2 /dev/ram2 /mnt/ram
cd /mnt
umount /mnt/ram
dd if=/dev/ram2 bs=1k | gzip -v9 > rootfs.gz
*************

The first time I run this script, I get a small rootfs.gz file. Then if i
run the script again, the size of the file keeps going up!?!?

B. Madhusudan <bmp4153@hotmail.com> wrote:
> OK, I realize zeroing out the underlying data is important. After playing
> around with my script and commenting out everything except for zeroing out
> the device and making the file system and doing the gzip, I actually got it
> down to 4KB. But then if i run exactly the same script again, the size of
> the zip file keeps increasing. Shouldn't it stay the same??

Not if you don't zero the device, no.

> I observed this behavior: I got down to a small 4 KB file, then kept adding
> stuff to my root fs. So far, so good. Then when the zip file got too big,
> thought I could comment out some lines so I'd get just under 1.4 MB. But
> now, it refuses to go down. In fact every time I run the script, the file
> size keeps increasing!
>
> In fact, I used different /dev/ramX devices (thinking this might be the
> problem). I did mknod on /dev/ram55, ram56, etc. and observed this behavior.
> At the beginning of my script, I zero out these devices but the same thing

Well, apparently you don't!

> eventually happens... Is there a way to 'reset' the device to 0 or
> something?

Sure. Write zeros all over it.

> I'm not sure what's going on here...
>
> ***********
> My script is as follows:
>
> rm /mnt/rootfs.gz
> umount /mnt/ram
> rm -rf /mnt/ram

???? What? Why?


> dd if=/dev/zero of=/dev/ram2 bs=1k count=4096

Well, this has zeroed only 4M of the device. Why don't you zero the
whole thing? Why do this on a ram device anyway, instead of in a file,
if your intention is merely to create a "rootfs.gz"?

> /sbin/mke2fs -m 0 -N 1000 /dev/ram2

Fine. Except of course that you have proably made a file system far
larger than 4M. Why didn't you add "-b 1024 4096" to the command?

How big does mke2fs say the result is?

> mkdir /mnt/ram

Well, there was no need to get rid of it first of all!

> mount -t ext2 /dev/ram2 /mnt/ram
> cd /mnt
> umount /mnt/ram
> dd if=/dev/ram2 bs=1k | gzip -v9 > rootfs.gz

There's your problem. You are copying the whole device, not just the 4M
you zeroed originally.

> The first time I run this script, I get a small rootfs.gz file. Then if i
> run the script again, the size of the file keeps going up!?!?

Peter

"Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
news:h9ah52-pdo.ln1@triangulo.it.uc3m.es...
> B. Madhusudan <bmp4153@hotmail.com> wrote:
>
> There's your problem. You are copying the whole device, not just the 4M
> you zeroed originally.
>

ok, point taken... I see what's happening now. i got rid of the 4096 limit
when i zeroed the device out and it fixed the problem. Now the entire device
gets zeroed out. I hadn't realized the device could be so much bigger. ok,
so now i got the rootfs.gz file to be much more manageable and I can vary it
in size depending on how many files I copy into the directory.

Now of course I thought this would magically work... I inserted the root
floppy after the kernel boots and asks for the floppy. It starts to load
(and it actually goes on longer than it had ever before, so that was
progress!) but again, I got this error:
Kernel panic: VFS: Unable to mount root fs on unknown-block(2,0)

I looked at the troubleshooting guide and made sure all the essential files
are there. I did ldd on init and it requires libc, selinux, and ld-linux,
which i've copied into my directories...

Is there a way to verify what's on the actual disk after dd'ing the
rootfs.gz file onto it? The only floppy command i know is mdir and that
doesn't work on this disk.

B. Madhusudan <madhu_lists@yahoo.com> wrote:
>
> "Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
> news:h9ah52-pdo.ln1@triangulo.it.uc3m.es...
> > B. Madhusudan <bmp4153@hotmail.com> wrote:
> >
> > There's your problem. You are copying the whole device, not just the 4M
> > you zeroed originally.
> >
>
> ok, point taken... I see what's happening now. i got rid of the 4096 limit
> when i zeroed the device out and it fixed the problem. Now the entire device
> gets zeroed out. I hadn't realized the device could be so much bigger. ok,
> so now i got the rootfs.gz file to be much more manageable and I can vary it
> in size depending on how many files I copy into the directory.
>
> Now of course I thought this would magically work... I inserted the root
> floppy after the kernel boots and asks for the floppy. It starts to load
> (and it actually goes on longer than it had ever before, so that was
> progress!) but again, I got this error:
> Kernel panic: VFS: Unable to mount root fs on unknown-block(2,0)

Well, you really are going to need support for the root medium in the
kernel! devices.txt says major 2 is the floppy device, so it appears you
have specified the root device wrong (and don't have support for it in
the kernel).

> I looked at the troubleshooting guide and made sure all the essential files

Well, look at the error message instead. When your nose itches do you
read the telephone directory?

> are there. I did ldd on init and it requires libc, selinux, and ld-linux,
> which i've copied into my directories...

> Is there a way to verify what's on the actual disk after dd'ing the
> rootfs.gz file onto it?

Sure. Read it back and uncompress it.

> The only floppy command i know is mdir and that
> doesn't work on this disk.

Then "know" some more "floppy commands".


Peter

"Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
news:6omi52-6n3.ln1@triangulo.it.uc3m.es...
> B. Madhusudan <madhu_lists@yahoo.com> wrote:
>>
>> "Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote in message
>> news:h9ah52-pdo.ln1@triangulo.it.uc3m.es...
>> > B. Madhusudan <bmp4153@hotmail.com> wrote:
>> >
>> > There's your problem. You are copying the whole device, not just the 4M
>> > you zeroed originally.
>> >
>>
>> ok, point taken... I see what's happening now. i got rid of the 4096
>> limit
>> when i zeroed the device out and it fixed the problem. Now the entire
>> device
>> gets zeroed out. I hadn't realized the device could be so much bigger.
>> ok,
>> so now i got the rootfs.gz file to be much more manageable and I can vary
>> it
>> in size depending on how many files I copy into the directory.
>>
>> Now of course I thought this would magically work... I inserted the root
>> floppy after the kernel boots and asks for the floppy. It starts to load
>> (and it actually goes on longer than it had ever before, so that was
>> progress!) but again, I got this error:
>> Kernel panic: VFS: Unable to mount root fs on unknown-block(2,0)
>
> Well, you really are going to need support for the root medium in the
> kernel! devices.txt says major 2 is the floppy device, so it appears you
> have specified the root device wrong (and don't have support for it in
> the kernel).

HALLELUJAH!! I did indeed have support built in. The whole problem it turns
out was that in my syslinux.cfg file, I only had:
default linux
append root=/dev/fd0

It turns out I needed to also have: load_ramdisk=1
!!

Is using rdev and a bootloader mutually exclusive? When I created the image
to go on the disk, the 'make bzdisk' also did a syslinux for me. I hadn't
realized it at the time (and I was reading the steps from an old book) and
so I also did an rdev on it: 49152, but that ruined the disk. Then I read
that rdev is obsolete and I should use either syslinux or lilo. (Syslinux
was already on the disk).
Another step I tried was removing the syslinux and then just dd'ing the
bootimage onto the disk and then doing rdev. But upon booting the system, I
got a message saying that this isn't supported anymore and that I need a
boot loader! So that was a dead-end.

So I'm just curious how I could have used rdev now...
I guess the next thing is to try a CD Rom.

Thanks for all your help! Now i know the dd command inside-out... whew. what
a workout!

madhu