Puppy RamBoot - Everything (including save file) in RAM

[seaside]

jemimah,

I've being yearning to try out RamBoot and finally got around to it and here's what happened.

Booted up with the new initrd and saved a minimal pupsave of 32m to a usb hard drive. Rebooted with ramboot=1 option and got this error..

"superblock could not be read.....try alternate superblock e2fsck -b 8193 <device> " (I later tried that with no success)

It then failed to mount pup-rw, loaded pup-431.sfs, layered,and then went to kernel panic

When booting without the ramboot=1 option, all goes as expected and the new pupsave file loads without a problem.

Any ideas as to what might be happening?

Thanks,
s

[jemimah]

Wow no, that's never happened to me!

Did you get that error after it loaded all the files to RAM? What does the rest of your bootloader config look like? Are you using a regular ext2 save file?

[Mstar]

Jemimah,

I thought it was just me. I have exactly the same problem. Machine is a P4, 2 gig Ram, Intel D865GBF Mobo, ATI x1650 video card. Puppy 4.3.1 frugal.

I've made a save file by booting from the RamBoot Initrd.gz but started with Pfix=Ram and then saved. Get exactly the same result when I boot with Ramboot=1. Also chokes on 2fs file made before trying RamBoot. Both will boot from the "normal" Initrd.gz.

In both cases I'm booting from the same Grub Menu.lst file, the only difference is editing before booting to add Pfix=Ram and eliminate Ramboot=1 when I created the 2fs save file to see if the original was somehow corrupted.

[seaside]

Jemimah,

Since the pupsave file works when the "ramboot=1" isn't used, perhaps it has something to do with the actual filesystem that the pupsave is on. My pupsave file is on an "ext3" filesystem.

Is there any ramboot load coding that might get confused in this case?

Thanks for any insights you may have,
s
(Mstar, I'm also happy it's not just me )

[jemimah]

I tested exclusively with ext2 filesystems, so that's probably it. Let me see if I can figure out how to fix it for ext3.

Edit: Wait.. Mstar you said you're using a .2fs, so it's probably not ext3 or at least not exclusively.

[seaside]

I tested exclusively with ext2 filesystems, so that's probably it. Let me see if I can figure out how to fix it for ext3.

Edit: Wait.. Mstar you said you're using a .2fs, so it's probably not ext3 or at least not exclusively.

jemimah,

I wasn't sure whether Mstar was referring to the pupsave file itself as "ext2" or the filesystem that the pupsave was on.....

In my case the pupsave file itself is "ext2" and it resides on an "ext3" filesystem.

Thanks for checking this out,
s

[jemimah]

When in the boot process do you get the error? Before it says "Copying Files to Ram", or after?

Also, are you using ext3 and grub on a USB drive? Or Syslinux on ext3 (is that even possible?). Can you try it with a Syslinux VFAT usb drive?

[seaside]

When in the boot process do you get the error? Before it says "Copying Files to Ram", or after?

Also, are you using ext3 and grub on a USB drive? Or Syslinux on ext3 (is that even possible?). Can you try it with a Syslinux VFAT usb drive?

jemimah,

Just ran it again and it gets to "copying files to ram......kb ram will be used" and then the "superblock ......" error happens.

Using grub on ext3 USB harddrive.

Thanks,
s

[jemimah]

Do you get an actual number for how many KB of ram will be used? or just blank?

[seaside]

Do you get an actual number for how many KB of ram will be used? or just blank?

Just blank

[jemimah]

So it's failing in the part where it calculates file size, then allocating a 0kb ramdisk. I wonder why. My internal drive is ext3 and it works fine.

[seaside]

So it's failing in the part where it calculates file size, then allocating a 0kb ramdisk. I wonder why. My internal drive is ext3 and it works fine.

Interesting.... only difference seems to be USB harddrive vs internal hd. Does the order of the kernel line parameters make any difference - I have the "ramboot=1" as the last.

[jemimah]

I don't think so. Do you have anything for pmedia and pdev1? I'll post a new initrd with more debugging output when I get a chance to rebuild it.

[seaside]

I don't think so. Do you have anything for pmedia and pdev1? I'll post a new initrd with more debugging output when I get a chance to rebuild it.

pmedia=usbhd psubdir=pup-431

[jemimah]

Maybe it's psubdir. I don't think I considered that...

[seaside]

Maybe it's psubdir. I don't think I considered that...

That would make sense, since the pupsave file loads just fine without the "ramboot=1" option.

[Mstar]

Jemimah,

The frugal is on a FAT32 partition in its own subdirectory. The 2fs is the extension of the automatically generated pupsave file. I don't know if it's actually an ext2 file, but I presume it is. It's whatever Puppy creates.

Since I'm also using the psubdir command, that's a likely place to look for the problem. Here is the whole menu.lst entry:

#Rampup
title Rampup
rootnoverify (hd0,2)
kernel /Rampup/vmlinuz pemdia=satahd psubdir=Rampup ramboot=1
initrd /Rampup/initrd.gz
boot
#End Rampup

My installation quits in exactly the same way Seaside describes.

[jemimah]

Ok, I'll check out the psubdir thing and see if I can fix it.

[Lobster]

jemimah

(I have been eating red herrings again)
An OS started in ram
(do we have a networking booting Puppy)
would seem to be the most secure system
for instant shutdown.

Why might you want that?
Well let us say you have a Puppy droid
flying over a war zone dropping flower petals
(something I recently suggested to a former
defense minister)
Obviously you don't want your petal collection points
or flight path to fall into the hands of the militarily demented.

Droid down
No software.
The flowers are safe.

[jemimah]

I've uploaded a new version that hopefully fixes this problem. I haven't fixed the shutdown script yet though. I'll look that that later this weekend.

Lobster, I believe I read there's a way to retrieve data from RAM after the machine has shutdown. But my understanding is you have only mere seconds to do this before it's to garbled to recover. So this solution is probably secure enough for your flower bomber Puppy.