Type 1 HD install cannot find usr_cram.fs (Solved, sorta)

Using applications, configuring, problems
Post Reply
Message
Author
tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

Type 1 HD install cannot find usr_cram.fs (Solved, sorta)

#1 Post by tempestuous »

I have made a PuppyUnleashed version which I want to boot from HD, type 1 (compressed). I chose to put usr_cram.fs inside image.gz and this will bootup successfully using LILO, but I have to specify "ramdisk_size=63488" as a boot parameter ... and this takes a very long time to boot.

So I made PuppyUnleashed again, keeping usr_cram.fs separate. But now the boot sequence cannot find usr_cram.fs which is on the same partition as image.gz (hda2). I think that part of the problem is that I am not using a pupfile - my lilo.conf includes "PFILE=no". I think if I use a pupfile then usr_cram.fs can be found if it's in the same location.

... but I don't want to use a pupfile ... because I want to run Puppy completely in ram and spin down the hard drive.

Can I modify one of the boot scripts (rc.sysinit?) to clearly define the location of usr_cram.fs?

Craig S

Bruce B

#2 Post by Bruce B »

Naturally I don't know specifics about your unleashed setup.

In my experience, put usr_cram.fs in the same place as pupxxx file is supposed to be as the default behavior of Puppy.

It would be nice to be able to specify its location.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#3 Post by tempestuous »

Well I worked it out. I added this code at line 922 of rc.sysinit -

# mount partition with usr_cram.fs
mount -t ext3 -o rw /dev/hda2 /mnt/home
# copy usr_cram.fs to ramdisk, then unmount partition
cp /mnt/home/usr_cram.fs /usr_cram.fs
sync
losetup /dev/loop0 /usr_cram.fs
mount -r -t ${COMPRFS} /dev/loop0 /usr
umount /mnt/home
# OR, access usr_cram.fs from partition (uses less ram) but partition must remain mounted
## losetup /dev/loop0 /mnt/home/usr_cram.fs
## mount -r -t ${COMPRFS} -o noatime /dev/loop0 /usr

Not exactly an elegant solution, because I have "hard-coded" the system to work a particular way from a particular partition.
And ironically, I think I now prefer the original "large image.gz" approach.

Post Reply