Page 3 of 4

How to clarification please - delete initrd.gz, replace, edi

Posted: Mon 11 Jan 2010, 20:31
by Mitchellray
Hello jemimah,
I was unsuccessful at my attempt to try ramboot option.
I booted Puppeee 4.31 beta_3* on my 1005HA.
I inserted another USB stick with the same and mounted it.
I deleted initrd.gz on this second stick.
I downloaded the 'new' initrd.gz to the mounted stick.
I opened syslinux.cfg and added to the end of the only line "ramboot=1" , the number one that is.
Then I downloaded the shutdown file and place it on the USB stick. I am not sure what to do with it.
The netbook would not boot off of this stick with an error saying it could not find .sfs file (something to that extent, although I could give exact if that is needed in order to re-direct my efforts)
I have started over by copying my working Puppeee on to the test USB Flash D stick and am actually on it inputting this message.
I will try the modifications again once better informed.
Mitchellray

Posted: Mon 11 Jan 2010, 23:01
by jemimah
Puppeee already has the Ramboot modifications in it's initrd, so don't try to replace it. Just adding Ramboot=1 to should do the trick.

Ramboot worked; what about shutdown script?

Posted: Tue 12 Jan 2010, 02:13
by Mitchellray
Hello,
The ramboot=1 edit to syslinux.cfg worked and the os is loaded and the USB Flash D remains unmounted.
If I understood the first post, the shutdown script would allow for a save back to the stick as long as it has not changed its location.
If so, where and how do I add that?

(I tried to mount the USB Flash D and then save to it during a session, but the change I made, which was to add a bookmark, did not remain when I booted back up again. I don't know why I thought that would work.)
Mitchellray

Posted: Tue 12 Jan 2010, 03:57
by sunburnt
jemimah; Puppy already has code to mirror the Save file for USB booting (I believe).
You just need to find it and make use of it for your setup...
I`m sure Barry thought of having the Save file in ram, but I see no advantage in it.
It must persist to be a Save file as you pointed out, so having it on a drive is best.

prehistoric; ### I have been suggesting a " no-union " OS for years now...

Basically the union is complex, unneeded, and requires OS resources,
but having apps. in no-union Squash files is required for my setup.
This eliminates the " loose files " of standard app. package installs.
It`s almost impossible for apps. to get viruses if they`re Squash files,
and stray file deletion is near impossible as there are few loose files.
Squash files are never installed, they`re mounted, used, and unmounted.
If Squash apps. are static compiled then there`s no dependency problems.

Posted: Tue 12 Jan 2010, 07:42
by panzerpuppy
[deleted] Double post. See the next message.

Posted: Tue 12 Jan 2010, 07:44
by panzerpuppy
@jemimah: can you do the same hack to the initrd.gz used in Turbopup Xtreme (based on Puppy 4.20) and post the file here for download?

I'd love to RAMboot with the 'fastest dog on Earth' :)

Posted: Tue 12 Jan 2010, 08:50
by gyro
jemimah,

I like the concept of 'ramboot' especially in conjunction with Browserlinux, and not saving the pupsave.2fs. This should be a pretty safe environment for surfing the web.

I started looking at your code, because when I am using it I don't get a "filesystem check..." message during boot as I would expect from "pfix=fsck" as a boot param. I still haven't found out why yet, any ideas?
But I did notice that on 2 occasions when you detect an error with trying to copy the files to ram, after displaying an error message you "exit". I'm not sure it's a good idea to exit the "init" script at this point just because 'ramboot' won't work, surely it would be better to fall back to the normal "init" functioning.

gyro

rc.shutdown.gz write protected - can not alter nor remove

Posted: Tue 12 Jan 2010, 18:13
by Mitchellray
Hello jemimah,
I downloaded the rc.shutdown.gz zip.
Then I un-zipped it.
Then I mounted my USB Flash D while running in ram ala ramboot=1.
I tried to first delete the contents of /etc/rc.d/rc.shutdown.gz in order to replace with new script. Error message says write protected. I also tried deleting file with same result.
I tried changing permissions and was denied.
How do I replace this?
Mitchellray

Posted: Wed 13 Jan 2010, 04:40
by jemimah
MitchellRay, I just tested and had no problem deleting the rc.shutdown file so that's kinda strange. Try from the command line.

Code: Select all

mv /etc/rc.d/rc.shutdown /etc/rc.d/rc.shutdown.bak
---

gyro, fsck worked for me when I tested, but that was the Puppeee version. I'll have to check the standard script when I get a chance.

I prefer the script to fail catastrophically rather than continuing in normal mode without telling me. There's probably a way to make it ask what to do, but I'm too busy/lazy to bother. If you want to fix it, I'll post the new version.

----


Panzerpuppy, I'll add it to my todo list.

---

Sunburnt, can you elaborate on "Puppy already has code to mirror the Save file for USB booting." I'm not sure what you mean or how to search for it.

My goal here is not to re-architect Puppy, just to provide a simple and flexible solution for running diskless. The only other ways to to it are multisession dvd, or remaster and run in pupmode 5.

rc.shutdown 'write protected' unable to delete/move solved

Posted: Wed 13 Jan 2010, 07:58
by Mitchellray
Hello jemimah,
I got the same error message when trying command line move rc.shutdown to rc.shutdown.bak.

I removed 'ramboot=1' from syslinux.cfg, rebooted and tried again. The file was then able to be removed without issue, although I did not keep it as a backup. I'll have to get a fresh copy if I need it or want to go back.
I guess the change could not be made when running completely in RAM.
Then I re-entered ramboot=1 in syslinux.cfg.
The shutdown process of copying back to [disk] USB Flash D went smooth.
Is each save creating a new file or is the pup-save file modified at shutdown with these parameters?
Thanks again.
Mitchellray

Posted: Wed 13 Jan 2010, 16:02
by jemimah
I've replaced it many times before while running in RAM. I guess you're just lucky. ;)

The script works like this:
1. copy save file from disk to ram
2. you modify the ram version
3. rename save file on disk
4. copy save file from ram to disk

You've given me an idea though. I could probably reuse the code to create a new save file each time. That might be more reliable than just copying the ram version back to disk.

Posted: Thu 14 Jan 2010, 21:32
by seaside
jemimah,

I've noticed that if a pup-save file has an sfs file that is designated for loading at boot time in "/etc/rc.d/BOOTCONFIG", the Ramboot initrd does not load the sfs file.

Perhaps this is a loading sequence problem and I wasn't sure, so I was wondering if you had any ideas?

Thanks again for Ramboot!

Regards,
s

Posted: Thu 14 Jan 2010, 21:36
by jemimah
It's supposed to load any file that ends in *fs. They need to be in the same location as the main sfs. It works fine for me. I've used it with the devx, kernel source, and zdrive before. What sfs are you trying to use?

Posted: Thu 14 Jan 2010, 22:24
by seaside
jemimah,

Thanks for your reply. I double-checked and loading it with the pup-save file normally without the "ramboot=1" option, the devx_431.sfs file loaded and unioned on /initrd/pup_ro4.

In loading with "ramboot=1" option the messages noted that devx_431.sfs was being loaded into ram, but devx_431.sfs did not show up as mounted later

I did some checking of the error files and saw this -


in file /initrd/tmp/bootinit.log

"s: /mnt/dev_save/*.sfs: No such file or directory"

and

in /initrd/tmp/EXTRASFSS

"/mnt/dev_save/devx_431.sfs"

I'm a bit puzzled.. :D

Thanks for your help,
s

Posted: Thu 14 Jan 2010, 23:33
by Anniekin
I was just wondering if there is a way to selectively load puppy components and apps to run in RAM on a full install boot.
Then I stumbled across this thread.
Is there a way to do this?

Posted: Thu 14 Jan 2010, 23:56
by jemimah
Seaside, I'll check it out.

Anniekin, you need to use frugal if you want to put things in RAM. Even then, it's difficult to be selective unless you want to remaster or move stuff around to different sfs files.

Posted: Fri 15 Jan 2010, 22:07
by seaside
jemimah wrote:Seaside, I'll check it out.
jemimah,

Tried out a few other items -

Symlinked the devx_431.sfs file outside of the psub dir - no luck- was hoping that might be it.

Also, converted the "pup-save.2sf" save file to an .sfs file and renamed it "zp431000.sfs" and that didn't load (maybe the "zdriv" filename convention isn't right-not sure)

Forum seems to have been down.....

Posted: Fri 15 Jan 2010, 22:26
by jemimah
I had problems today using psubdir with the devx without ramboot. Moving it to /mnt/home fixed it, maybe a symlink is not good enough. Not sure what the deal is yet.

Posted: Fri 15 Jan 2010, 22:53
by seaside
jemimah wrote:I had problems today using psubdir with the devx without ramboot. Moving it to /mnt/home fixed it, maybe a symlink is not good enough. Not sure what the deal is yet.
Yes, the devx sfs has to be either in the /mnt/home or symlinked to work for my "non-ramboot" loading from a psubdir.

(I'm wondering how many reboots my machine can take before it starts complaining that it's being abused :D ) ....

Posted: Sat 16 Jan 2010, 03:47
by seaside
jemimah,

Some more observations.....

The "zp431000.sfs" file needed to be renamed "zp431305.sfs". It loads fine with "ramboot=1" and without - in the psubdir.

The devx sfs file still doesn't load in "ramboot=1" mode, however, no matter if it's in /mnt/home or psub.

A puzzle.

Thanks for your help,
s