[TESTING]"puppy pfix=recycle" Boot Parameter

[rcrsn51]

Perhaps there is time to get them included in Woof?

This is the wrong strategy. It is unreasonable to expect that a newcomer could take an old computer, get a Puppy CD from somewhere and do a one-click install without having some kind of training.

A more realistic scenario is one where the newcomer gets assistance from an experienced Puppy user, like you. That person would have the Live CD and installer script that matches the hardware.

[ecomoney]

It is unreasonable to expect that a newcomer could take an old computer, get a Puppy CD from somewhere and do a one-click install without having some kind of training.

Thats exactly what my partner did with an Ubuntu CD I gave her when we had just met! I gave her the CD to take home for "safe keeping" the first time we met, and said I would install it next time I visited...by this time she had already got her p.c. up, working and on the internet! There is no reason to believe this is un-achievable with Puppy (though its certainly is the case now that a lot of training is required).

Achieving this would just be a matter of designing the right user interface, in the right place for your script, and using the correct, non-technical, language.

There are two IRL scenarios here....

The computer recycler
Needs to take old computers, wipe and recycle/"get working" as quickly as possible. For this a "pfix=recycle" command that would invoke your script (before pup_xxx.sfs was loaded) would be ideal. Crash?

The home user
This would be someone with a spare/old computer to try puppy on. They would require a desktop icon/menu entry on a livebooted puppy, which would (perhaps) offer a choice between the existing "advanced" installer, and the 2 "just works" scripts you have produced. It would need a gtk or similar front end.

In either case, the amount of "training" or "expert help" required would be directly inversely proportional to how many computers that could be recycled/waste reduced. Complexity should then be kept to an absolute minimum.

I suggest, in terms of how quickly that we can get this facility developed and recycling as many waste computers as possible, we should concentrate on the "puppy pfix=recycle" option first, and then get the GUI side (calling the same routines) after that.

[Crash]

rcrsn51-

Thanks for the help in generating this code. I estimate that you saved me about 40 hours of redundant effort. At the rate that I am currently able to devote to Puppy Linux, that equates to about three calendar months!

I think this is possible to do using just the Kernel - well, almost just the Kernel. The trick would be to mount the .sfs file, then use the needed programs like Grub and stage 1, 2 from the mount point. I need to tinker around a bit to see the feasability of using that approach.

Anyway, this is great fun, and as always an excellent learning experience. I'll give you progress reports as I find out things.

[ecomoney]

Crash, Im by no means an expert, but I was thinking/hoping it would be possible to implement the script from the "busybox" level, i.e. when the init is loaded but before the pup_xxx.sfs is loaded into memory. This would make the recycling process much faster.

For the frugal install, the pup_xxx.sfs would be copied from the cd onto the hard drive, and for the full, it could be mounted directly from the cd and the files copies/decompressed on the fly to the hard disk.

This may mean a busybox recompile to make to appropriate utilities available at this stage in the puppy boot process.

[rcrsn51]

A couple of comments:

Any missing programs like mke2fs would have to be statically compiled in order to be included in the initrd.gz.

There is a huge advantage to letting a recyclable machine boot to the desktop because you get the opportunity to make the initial hardware configuration. Then after doing the frugal install, you can create a pup_save file for that machine during shutdown. When the new owner boots up, the machine will go directly to the desktop and be ready to run.

[ecomoney]

Hmmm....I am coming round to your way of thinking, if it means that the final machine is "ready to ship", and it means that the programming is easier.

Just a quick question while you are on, I notice in the readme script for the latest version of the installers, it says it is compatible with puppies back up to 2.17. What changes would need to be made for 2.15ce/2.14? Ttuxxx is working on an updated 2.14 series puppy aimed at older end kit....and it would be nice to have this in my Ecopup (2.15ce based!).

[rcrsn51]

I notice in the readme script for the latest version of the installers, it says it is compatible with puppies back up to 2.17. What changes would need to be made for 2.15ce/2.14?

Probably nothing. I only tested as far back as 2.17.1. The significant differences in versions show up with full installs. That is why the installer scripts use the PUI to do the heavy lifting.

[ecomoney]

I tested with puppy 2.15ce and the scripts on a pendrive, test rig cyrix 150mhz, 4.3gb HD, 192mb RAM.

In earlier kernels I had heard that the mount points are called different things

dev/sda1 = dev/hda1
dev/sr0 = dev/cdrom

I changed these in the scripts, and hey presto it formatted the drive and copied the files! No grub install though, the reboot just hung at "Booting from IDE 0". I rebooted with "puppy pfix=ram" parameter and installed grub manually using the grubinstaller, and things were perfect.

Any Ideas rcrsn51

I think I may be able to adapt this script to have a gui confirm (GTK?) by borrowing some from the network wizard/ecopup shutdown dialogue...but how would I install Grub?

[rcrsn51]

I just installed 2.15CE using the most recent posted version of the scripts and it worked fine without modification.

[ecomoney]

Perhaps it was down to the clearly ancient hardware...I will do a more thorough test to identify the problem.

[ecomoney]

Theres been some more movement on the install script on the HanSamBen education suite thread. Technosaurus came up with this great "just works" snippet.

Code: Select all

#!/bin/sh
RAMSIZE=`free | grep 'Mem:' | tr -s ' ' | cut -f 3 -d ' '` #total physical ram (less shared video).
if [ $RAMSIZE -gt 220000 ]
then
frugal-install
else
full-install
fi

from here

http://www.murga-linux.com/puppy/viewto ... 304#312304

Now we have the "guts" of this installer, the best way to proceed would be to produce a easy frontend (probably just a single form with a warning and one button...probably big and red lol). If the whole thing were packaged as a .pet marked "Alpha" then we could get a lot more feedback about what needs to be changed/updated. By the look of things this would be VERY popular...so I will need to figure some way of getting it up the "install puppy linux" google search rankings. I will also post he .pet on the first post of this thread.

[sidders]

I have been playing with your scripts and added a couple to kick it all off. see:
http://www.murga-linux.com/puppy/viewto ... 4&start=99

I tried it and had to go and sort out:
A: Hannah jumping on Sams head
B: Sam biting Hannah
C: Ben kicking off because he's hungry

The script had finished, but i wasnt sure what was what, so i went ahead and rebooted anyway. The install was perfect. I've put ant Xmessage at the end to say reboot.
Am testing and will come back with the code providing it works.

[sidders]

Tested and it works:

i scrubbed the echo's at the end of the script and inserted for the frugal:

#use xmessage for reboot
asnswer=$(xmessage -bg "#FFFF00" -center -fn "10x50" -title "IMPORTANT" "reboot the PC, at prompt select Save To File accept the defaults:SDA1 and 512mb" -buttons restart -print)
if [ "answer" = "restart" ]
then
wmreboot
fi


The same is for the full install except saying do not save. There is a warning message about 10x50 font something or other.

I will change it to say poweroff and eject the cd then power back on again.

[ecomoney]

I tried it and had to go and sort out:
A: Hannah jumping on Sams head
B: Sam biting Hannah
C: Ben kicking off because he's hungry

This is exactly the problem HanSamBen (the Puppy Linux derivitive) is intended to solve, Sidders has put a huge amount of time and effort into developing it to solve this problem for himself and others. The reason it solves these problems so elegantly is undoubtedly due to the fact surrounded himself with his intended audience (however difficult that may make learning BASH scripting) - as well as taking on board the advice of teachers, childcarers, parents, testers, and of course actually physically testing this in pre-schools.

Its a dual purpose, educational derivative of Puppy Linux, which lowers the hardware limits to which a large amount of mainstream linux childrens educational software can be delivered. This essentially allows computers that are several years older than linux's previous technological limits to be used as tools for childrens education, rather than harm them as industrial waste.

Its dual purpose because its intended to be used both as a liveCD, so that parents from underprivileged backgrounds can leave their children on their computers without fear of them "breaking" it and it needing an expensive specialist repair (it has no windows filesystem drivers) or internet access (network drivers have been removed).

It is also aimed at schools, nurseries, playgroups (or parents with second older computer) to them to be able to re-use the computer simply as a dedicated kids computer. These groups of people (specialists in children not technology) have a need to recycle a computer as simply and easily as possible, as they just dont have the time (or the length of attention needed) to learn about bootloaders and linux drive notation. You could say its a "OLPC project for old computers" rather than laptops.

Because of its intended user base, it has a strong requirement therefore to have a graphical, easy to use frontend for this installation script, that will run from a livecd.

Is anyone with the skills reading prepared to step up to the challenge?

[rcrsn51]

If I understand correctly, you envision HanSamBen being used by children as a Live CD on a working Windows machine.

At the same time, you want a "graphical, easy to use frontend for this installation script, that will run from a livecd."

Can anyone else see a potential problem with this scenario, seeing how the installation script is designed to erase the hard drive?

[ecomoney]

Yes...that is why the key combination required to launch the installer was made to wide for little hands to reach! HSB does not have a taskbar enabled by default, it is simply a desktop with icons. The "launch key combination" will be documented in the manual.

[sidders]

After poncing about with it, i have added this to the end of your script:

Code: Select all

#Finish up
sync
umount /mnt/sda1
umount /mnt/cdrom
#xmessage to finish installation.
answer=$(xmessage -bg "#FFFF00" -center -title "Thats It Shutdown and eject the CD" "
All Done. Please Click on the ShutDown button and eject the CD to finish the installation. 
When shutting down you will be prompted to 'Save To File', Select Do Not Save and press enter.
" -buttons ShutDown -print)
if [ "$answer" = "ShutDown" ]
then
wmpoweroff
fi

With the Frugal install, i dont save anything after the initial install, i'll have to check again as the seed of doubt is a big one.

I've one this on the Full fat version, i suppose that its designed to put on old machines. The Lite version i will build in another check on the script along the lines of "Are you sure!"

[ecomoney]

There is a file called "PUPSTATE" in /etc/rc.d, this basically is a numeric code that tells puppy whether it is livebooted, installed to hard drive, running in RAM or such like.

to avoid being asked to create a save file on shutdown...simply change this to tell it that puppy is *already* running from a save file...and the routine to create one will not be invoked at shutdown.

It may also be a good idea to have the script check the pupmode, to ensure that puppy is definetely running in livecd mode before the script is ran. This way, there is no chance someone will use it and inadvertantly wipe everything off their computer.

The reading material for this is here

http://www.puppylinux.com/development/h ... works.html

[Crash]

This is an intermediate report on progress... I'll bet you thought I'd be done by now! Nope, but this is a very good learning experience for me. What I have posted here "almost" works, and maybe shows proof of concept, or maybe not...

First, I found that simply adding the "recycle" code to init is probably not a good thing, since it adds a lot of code that really is unrelated to the boot process. Instead, the final architectural approach was to do minimal changes to init, and add another program to initrd.gz that I called fruscr_init. Fruscr_init is an adaptation of fruscr for use by initrd.gz. Thus there are two files attached. You need to replace init with the attached one, then add fruscr_init to initrd.gz. Also attached is the entire initrd.gz with all the files in it, in case you don't want to do the process manually.

One of the issues I came upon early was how to test intermediate versions. I found quickly that it wasn't too environmentally friendly to keep burning live CDs, only to throw them away when they didn't work. So I added some other options to allow the source and destination devices to be chosen by the user. These options are hidden to the casual user, and shouldn't interfere with anything. Essentially, the first "YES/NO" question can also be answered with three more levels of debug capability:

"VERBOSE" : Prints out a lot more internal information. Useful to figure out which devices are which, etc.

"DEBUG": Includes the VERBOSE listing, and adds options to re-define the source and destination devices. I did a lot of testing with this option, using two USB thumb drives as the source and destination devices.

"STEP": Really painful debug option that does the VERBOSE and DEBUG stuff, but also stops at each major intermediate step and jumps to the shell. This allows you to observe the success or failure of each step, then return to the program by typing "exit".

Also, I added a second "YES/NO" step just before the point where you will really trash a hard drive. Is is kind of like saying "Are you really, really sure?"

What doesn't work:

"mke2fs" doesn't work. I'm still chasing down its dependencies.

"grub setup" doesn't work. I'm still chasing down its dependencies too.

So the way I know the rest works is that I can go up to the point where those commands are attempted, then execute those two commands from a GUI, then proceed. Everything else is OK.

This version doesn't do a full install, only a frugal one. I want to get the frugal install to work fully before I tackle the full install. This version was last edited June28. It has taken me this long to verify its functionality.

One other note: I am having worse and worse luck editing the Puppy .iso file with ISO Master - keep getting checksum errors. Makes for lots of Frisbees. An alternative, UltraISO, works fine, although it is a Windows product. I finally just made a shell script to save the edited iso directory:

Code: Select all

mkisofs -o /mnt/home/p421_recycle.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -J -R -V "recycle" /root/Crash/iso

This creates the file "p421_recycle.iso" in the home directory from the files that I put in the "/root/Crash/iso" directory. (This is a frugal install).

[ecomoney]

Great stuff seeker!

Would you upload it as a full iso, that way I know I am not doing anything wrong when I am testing.

Cheers