[TESTING]"puppy pfix=recycle" Boot Parameter

[ecomoney]

Current Testing ISO

http://ecomoney.eu/puppy/recycle/

Simply burn the CD, and invoke the installer with "puppy pfix=ram" to start the installer.

Origional Post

Puppy Linux Mission Statement:

* Puppy will easily install to.........hard drive media
....
* Puppy will be extremely friendly for Linux newbies
....
* Puppy will just work, no hassles
.......
* Puppy will breathe new life into old PCs

Computer waste is a big problem, old computers contain dangerous chemicals such as lead, mercury, arsenic, PCB's etc. This can cause Cancer, miscarriage, loss of land for agriculture, amongst many other nasties in the primarily third world countries which western e-waste ends up. Puppy Linux, technically, allows a computer to remain useful for 2/3 times as long as a Windoze computer...whos "business model" encourages early obsolescence in order to increase their profit margins.

Having recently helped a friend start an ebay laptop recycling operation, I realized just how difficult puppy is to install to the "Linux Newbie". Having advanced cd/usb/zip install options is all very well, but if it means that new users cannot do a basic install on an ancient dedicated computer to try it out, how will they ever gain the linux skills to progress to becoming a more advanced linux user?

Recently, I read Catdudes excellent, but necessarily long, tutorial on installing Puppy linux on a dedicated computer...

http://www.murga-linux.com/puppy/viewtopic.php?t=29653

"Doesnt work properly" and "cant be worked easily" amounts to the same thing IRL....could puppy do better on this score? I think so



Proposed Solution

Code: Select all

puppy pfix=recycle

This routine would be very simple, allowing unskilled non-linux initiates to recycle computer waste into a useable, workable puppy linux pc that can be used for education, entertainment, and other useful purposes.

Recycling operations for charity or to avoid landfill (which many people on here use puppy for) need a way to recycle their old computer donations with a minimum of training. For them TIME is their most valuable resource, and EXPERTISE is a shortage. The VAST majority of computers just have a single hard drive, and on older ones the data already on them is expendable....in fact its often very welcome to be able to wipe this off easily before giving the computer to a new owner. Gparted/grub config/Puppy universal installer is "overkill" for this.

Puppy linux also has a "lockout" problem which makes it extremely difficult to recycle very old computers with it. To boot puppy in liveCD mode you need at least 48mb of ram, to be able start the (very complicated) installer. Puppy has been reported to work on just 24mb or RAM. 32mb is a very common figure.

An install routine in "init", triggered by "pfix=recycle", which runs before the pup_4xx is loaded into RAM would make recycling a computer very fast (and worthwhile), and bypass the minimum ram requirement on very old hardware.

The script might have these steps...

1. Explain to the user/recycler what was about to happen (all data wiped), and confirm
2. Format 2 partitions - a 250mb swap, and the reminder to ext2
3. set the partition "bootable", or write to the MBR
4. Install GRUB to the hard disk
5. Copy the initrd.gz, vmlinuz, files to the hard disk from the CD
6. Ask the user to choose between a (well explained) choice of FULL or FRUGAL install, and perhaps even check the available RAM to give a recommendation.
7. If FRUGAL, copy the pup_4xx.sfs from the CD to the ext2 partition, if FULL, extract it to it.
8. Create a grub menu.lst files *with the file locations in the right place*
9. Eject the CD (this would be "nice") and ask the user to reboot

Much of the code for this already exists in the existing rc.shutdown scripts/universal installer.

My own Bash coding skills are very limited, but I do have access to many unskilled "test pilots" and a lot of older kit for testing this routine. I could also provide testing, by asking for it to be included it in the HanSamBen (which would supply top quality educational software to this older kit) where it would be very beneficial, and also including it in the puppy 2.14ce "Phoenix" project I am returning to co-ordinating.

Thanks in advance for your help.

[sikpuppy]

What's with the pictures? Are you trying to make a statement or trying to crumble your credibility into dust?

For goodness sake man stop before you really offend people.

[hillside]

From puppylinux.com we find "Puppy's Goals". This is pretty much the same list that is being thrown around as the Puppy Mission Statement. Is there a difference between a set of goals and a mission statement? I think maybe so.

Puppy was designed first and foremost as a live cd system. It works extremely well in this manner. It actually does install quite easily to usb drives and hard drives. (I haven't tried a zip drive.) The goals are about 99% accomplished.

Asking Puppy to automatically evaluate a specific set of hardware, out of all possible sets of hardware, repartition the hard drive (drives?), and install itself with no user interaction is asking a lot.

Perhaps you need to get a group together to develop Caveman Linux - a Linux for those who have never seen a computer.

[nic2109]

What's with the pictures? Are you trying to make a statement or trying to crumble your credibility into dust?

For goodness sake man stop before you really offend people.

C'mon; It's about landfill, which is a useful point to make. A couple of months ago Micro$oft announced (with fanfares, naturally) that they would be enabling millions in the 3rd world to use our old computers. How? By letting them buy XP Home for peanuts (can't remember the figure, perhaps it was $20). How that was supposed to prevent tons of old kit going to landfill 'cos it's not up to XP wasn't explained. Which is where Puppy could (should?) come in.

What might be a good idea is to follow the Ubuntu model and have options when booting from a live CD. Ubuntu offers 1) Try out Ubuntu without changing anything on the PC; 2) Install to the hard drive. Ecomoney's wishes could be met by a menu that went like this:- 1) Try out Puppy without changing anything (you will have a chance to save your settings and stuff when you finish if you want to); (2) Load Puppy and use your saved setting and stuff; (3) Install Puppy alongside whatever is on the PC already - if possible; (4) Wipe out whatever is on the PC and install Puppy.

Options 3 and 4 are very similar but because the aims of each are different the programs could be simpler.

I think that these boot options (from CD only, they would be ignored from Disk or USB) would be a useful development to the base Puppy. At least the Ubuntu flavour of Puppy 5 might benefit from something along these lines.

[Crash]

Actually, this thread is an extension of some ideas that were generated in a previous thread:

http://www.murga-linux.com/puppy/viewto ... 236#302236

I'm experimenting with ways to implement what ecomoney suggests. I'll make a post in this thread when I have something worthwhile. Then we can maybe iterate it after some test driving.

As usual, don't hold your breath. I'm not real fast at doing this stuff.

Again, thanks everyone for your comments and support. The Puppy Linux Forum is a wonderful environment for the exchange of ideas.

[droope]

Hey, eco, I think it's a great idea. I mean, I can install it, but not many people can. Puppy is really not an easy to use distribution... I think any efforts on this area will be welcome by many, many people.

So, I wish you luck on this path you have chosen (as long as you don't expect anyone else to do it for you.)

[ecomoney]

From puppylinux.com we find "Puppy's Goals". This is pretty much the same list that is being thrown around as the Puppy Mission Statement. Is there a difference between a set of goals and a mission statement? I think maybe so.

I know I added it to that page about a week ago Perhaps I will clarify that its the "Mission Statement"

Regards current ease of installation....here are some (IMO very well written) instructions Catdude wrote on doing a full hard drive install of Puppy Linux......friendly?

While the current installer (now I have my head around it which took me a LONG time) is very flexible and great for computer technicians to use regularly to set up complicated multi-boot setups...its overkill for the very common real world situation of simply having a computer too old to run windoze that needs recycling...puppy is very capable of running on ancient machines, its just extremely difficult atm to actually get it to by a linux "newbie"...which from your posts you are definitely *not* Hillside

Asking Puppy to automatically evaluate a specific set of hardware, out of all possible sets of hardware, repartition the hard drive (drives?), and install itself with no user interaction is asking a lot.

Most computers, at least in their "virgin" state only have one hard drive. It really would just be a matter of this routine seeking out that hard drive, partitioning it, and copying the correct files to it...the keyboard layout/display/etc would be handled by the xorgwizard on first boot.

@nic2109

Re Micro$oft...I hadnt heard about their scheme, I think this is the one..

Microsoft aims to double user base with $3 Windows and Office

Its a scheme that will allow *governments* to purchase Windoze/office at $3 a shot for schools there (taking into account that over half the worlds population live on less than $2 a day), but it would not be open to individuals at this price. Its probably a reaction to what happened to them when Nigeria tried to use Mandriva Linux in their school system...which caused a bit of a "stir", as from what I understand they bribed a few government officials to drop the Mandriva option.

@ nic2109

Yes the "Try Puppy Linux without changing anything on your computer" phrase is extremely powerful. Windows users are always extremely cautious about "changing anything" for fear of an expensive repair bill/a massive slowdown, and this phrase would do a lot to alleviate those fears.

The Ubuntu installer is extremely easy and well designed (even if it does not produce an entirely configured system at the endo of it). We would do well to model Puppies installer on it. The ability to use their packages (in woof) is an goo advancement for Puppy, using their OS installer would in my experience do a lot more to win us new users.

Nic, would you have the time to write such a routine for the CD bootup sequence? If not perhaps you could help "spec" it up?

@Droope

[/quote="droope"]as long as you don't expect anyone else to do it for you.

Many heads are better than one...and most heads are better than mine! I can contribute "newbie testing", and quite a few old computers to test this with. I am as always extremely grateful for the programmers (free) time, and as an ex-programmer myself I can appreciate the skill thats required to produce something like this. In this case, its a facility thats not already been created and just not included/uploaded

I agree it will be welcome by a great many (non-technical) people, and will do anything within my limited technical ability to help bring it into existence.

@ Crash

Im glad youve joined us Welcome! Thank you for agreeing to work on this much-needed feature. The thread you posted above IMHO proves you are currently the most experienced init-script developer available, which I why I asked you to look at this.

Even thoughts and ideas are "worthwhile" (not just code), please keep us updated of everything via this thread so you can "sound us out" about them. If you have any "technical hurdles" others may well have faced them before and offer suggestions, this will save you time finding solutions yourself and speed up the whole process. Such is the way of "open source".

I look forward to hearing more from you.

[rcrsn51]

Your "pfix=recycle" option is an interesting concept. But in reality, I don't think that it can work. At the init stage where pfix options are processed, Puppy does not yet have access to all the commands needed to do a complete hard drive install.

However, I can see another scenario. Some scripts could be added to Puppy that would do an automated install AFTER Puppy has booted off the Live CD. I have included two as examples.

[Edit] Go here for the most recent version.

These scripts erase the hard drive, build a new bootable partition, make a swap file, set up GRUB and do a frugal (or full) install of Puppy. The user just needs to create a pup_save file and Puppy is ready to go on the next reboot.

These scripts have had limited testing but they demonstrate the basic idea. Clearly, they would inflict major damage on a machine if used incorrectly.

Regarding low-memory computers: We all like the idea of running Puppy on just 32 MB. But the fact is that your average user would be completely dissatisfied with Puppy's performance on such a machine. As a minimum requirement, a machine should be able to boot off the Live CD to the desktop. This gives you the opportunity to test all the machine's hardware components before committing to an install. If it passes those tests, then it should be capable of running Puppy off its hard drive.

BTW, I really wish you would stop referring to ZIP drives. I think we have established by now that if someone still had a working ZIP drive, they probably couldn't boot off it anyway.

[ecomoney]

rcrsn51 - Fantastic! Thank you

Ive downloaded the scripts (very carefully!). I will have an enjoyable night in tonight with some of the many xp computers Ive collected wiping hard drives.

Just to confirm, I would need to add these scripts to a livecd, in the /usr/bin folder inside the pup_xxx.sfs file?

As I understand it (and after doing the netboot HOWTO I think I understand it quite well), the initrd.gz file contains the bottom "layer" of the puppy filesystem (before the pup_xxx.sfs "layer" is loaded/added). You are saying that many of the commands used in this script arnt available in the initrd.gz layer? Would it then just be a matter of moving the relevent command from the pup_xxx.sfs layer to the initrd.gz layer?

I understand where your coming from with the "too old to livecd boot/too old to run puppy at all" statement (I havnt actually tried a 32/24mb puppy!), I am just thinking for speed of recycling (where time is the biggest overhead), then a "pfix" command to initialize this script would be much quicker on known hardware. It would also allow for some of the larger puplets, with pup_xxx.sfs files that are much larger than the standard <100mb puppy one.

Im also thinking that it might be better to place the files (initrd.gz, vmlinuz, pup_xxx.sfs, boot.ini) inside a [sda1]/boot folder to keep things neat. Otherwise Im afraid newbies might delete them causing an unbootable computer (most know not to touch anything called "boot"...I think ).

Many thanks again rcrsn51

P.S. Yes...zip drives....but its in the mission statement!

[rcrsn51]

I tested the script by putting in on a flash drive (or you could use a diskette). After booting off the standard Live CD, I mounted the flash drive and ran the script from there.

You must leave the CD in the drive, otherwise the script won't run.

Eventually, you could remaster Puppy and put the script in /usr/bin.

[Crash]

rcrsn51,

I see ecomoney already posted a reply, so some of this is redundant, but here goes:

Boy, did you save me some time! I knew this had to have been done before. Now to figure out the easiest/best way to incorporate the capability into the distro.

About RAM: I've never used less than 128 MB for Puppy, but I feel there is merit in trying to get Puppy to run acceptably on computers with 64 MB. At the time when 64MB RAM was a popular configuration, the computers were getting to be quite powerful, like in the 500 MHz class. So I would think there are a lot of computers out there with 64 MB that are perfectly capable of running Puppy with acceptable performance. Also, those computers probably used at least PC100 class RAM, which is still available today if one wanted to do an upgrade. Less than 64 MB, and we're probably talking computers slower than a 233 MHz MMX, which I personally feel is the minimum performance acceptable. RAM for those computers is harder to find, and maybe not upgradeable. This is all open to debate, of course, and indeed there are several posts that have discussed this previously. The key is what computer you happen to have available, what your financial resources are, and whether you are willing to live with the performance issues with the less capable computers. Many in the United States will simply find one of those $300 boxes at the discount store, and they will work great for Puppy. But if $300 is your annual salary, it is a different story.

About Kernel utilities to support an install: That's exactly what I was trying to determine until you made this post. The Kernel has fdisk, dd, mkswap, etc. so I thought I'd give it a try. But yours should work out of the box with just a Live CD, so it looks like a cleaner solution.

Anyway, this is wonderful progress for a thread that is only a few days old. Good things have already come from it.

P.S. ecomoney, I'm no expert on INIT, just someone who likes to poke into things. I figure I am familiar with about 10% of it. The rest is still open to me for exploration. And this is just one of potentially thousands of files of open source code that is in Puppy Linux! So much interesting stuff, too little time...

[ecomoney]

BusyBox! Thats what I was trying to remember!

From this page in the Puppy Linux Wiki...

BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded systems. To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.

So this would mean that it would be possible to add the commands to busybox that are used in the install script. Busybox is loaded into the initrd.gz.

This would cut the time taken to run the install by about 1/3 if pup_xxx/xwindows didnt need to be loaded? Thats an awful lot of extra computers that can be recycled by one person in one day

If so who is the Puppy Linux authority on Busybox?

Am coffee'd out and about to hack a path through these xp computers Some days/nights...I love my job.

[ecomoney]

Im afraid my "pendrive of redmond doom" didnt quite do the trick

Here are the results of "full-install"

Code: Select all

# ./frugal-install
You are about to COMPLETELY erase this hard drive!
Do you want to continue installing Puppy?
Answer YES or NO in upper case:yes
# ./frugal-install
You are about to COMPLETELY erase this hard drive!
Do you want to continue installing Puppy?
Answer YES or NO in upper case:YES
mount: block device /dev/sr0 is write-protected, mounting read-only

The number of cylinders for this disk is set to 2491.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 2491.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): Command action
   e   extended
   p   primary partition (1-4)
Partition number (1-4): First cylinder (1-2491, default 1): Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-2491, default 2491): Using default value 2491

Command (m for help): Partition number (1-4): 
Command (m for help): The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
mke2fs 1.40.2 (12-Jul-2007)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2501856 inodes, 5002231 blocks
250111 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
153 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000

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

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 4.16822 s, 32.2 MB/s
Setting up swapspace version 1, size = 134213633 bytes
./frugal-install: line 47: grub-install: command not found
./frugal-install: line 48: /mnt/sda1/boot/grub/menu.lst: No such file or directory

Copying Puppy files ... Please wait ...

`/mnt/cdrom/vmlinuz' -> `/mnt/sda1/vmlinuz'
`/mnt/cdrom/initrd.gz' -> `/mnt/sda1/initrd.gz'
`/mnt/cdrom/pup_421.sfs' -> `/mnt/sda1/pup_421.sfs'


Done!
Shut down and make a pup_save file ...

The problem lines here ar towards the end

Code: Select all

.
/frugal-install: line 47: grub-install: command not found
./frugal-install: line 48: /mnt/sda1/boot/grub/menu.lst: No such file or directory

Line 47-48 of "frugal-install" reads

Code: Select all

grub-install --no-floppy --root-directory=/mnt/sda1 /dev/sda
cat > /mnt/sda1/boot/grub/menu.lst << EOF2

It seems line 47 to install grub failed, and that caused the next line (copying the boot section to grubs menu.lst) to fail also as the file is not there (grub having failed to install as planned).



and the full install....

Code: Select all

# ./full-install
You are about to COMPLETELY erase this hard drive!
Do you want to continue installing Puppy?
Answer YES or NO in upper case:YES
mount: block device /dev/sr0 is write-protected, mounting read-only

The number of cylinders for this disk is set to 2491.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 2491.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): Command action
   e   extended
   p   primary partition (1-4)
Partition number (1-4): First cylinder (1-2491, default 1): Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-2491, default 2491): Using default value 2491

Command (m for help): Partition number (1-4): 
Command (m for help): The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
mke2fs 1.40.2 (12-Jul-2007)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2501856 inodes, 5002231 blocks
250111 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
153 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000

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

This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 3.72582 s, 36.0 MB/s
Setting up swapspace version 1, size = 134213633 bytes
./full-install: line 47: grub-install: command not found
./full-install: line 48: /mnt/sda1/boot/grub/menu.lst: No such file or directory
/mnt/cdrom/pup_412.sfs: No such file or directory

Copying Puppy files ... Please wait ...

`/mnt/cdrom/vmlinuz' -> `/mnt/sda1/boot'
cp: cannot stat `/mnt/data/*': No such file or directory
umount: cannot umount /mnt/data: Invalid argument


Done!
Shut down but do NOT make a pup_save file ...
# 

The problem lines here are

Code: Select all

`/mnt/cdrom/vmlinuz' -> `/mnt/sda1/boot'
./full-install: line 47: grub-install: command not found
./full-install: line 48: /mnt/sda1/boot/grub/menu.lst: No such file or directory
/mnt/cdrom/pup_412.sfs: No such file or directory

Copying Puppy files ... Please wait ...

`/mnt/cdrom/vmlinuz' -> `/mnt/sda1/boot'
cp: cannot stat `/mnt/data/*': No such file or directory
umount: cannot umount /mnt/data: Invalid argument

These errors are caused by this piece of the "install-full" script

Code: Select all

#Install GRUB
grub-install --no-floppy --root-directory=/mnt/sda1 /dev/sda
cat > /mnt/sda1/boot/grub/menu.lst << EOF2
timeout 0
default 0
title Puppy Linux Full
root (hd0,0)
kernel /boot/vmlinuz root=/dev/sda1 ro vga=normal
EOF2

#Install Puppy
mount -o loop /mnt/cdrom/pup_412.sfs /mnt/data
echo
echo Copying Puppy files ... Please wait ...
echo
cp -v /mnt/cdrom/vmlinuz /mnt/sda1/boot
cp -a -v /mnt/data/* /mnt/sda1
umount /mnt/data
echo

I think the problem is again that the command "grub-install" isnt found, compounded by the fact that pup_412.sfs isnt found. This last part is due to me using pup_421.sfs from a puppy 4.2.1 liveCD. Previously the "wildcard" notation was "pup_???.sfs" but I doubt that would work this time because we are "mounting" the pup_???.sfs and extracting it (full install) rather than copying it whole as in the frugal install.

Just to prove to Droope I "dont expect anyone else to do this for me", Im actually going to have a go at debugging this

[ecomoney]

Well I tried.....

And I failed! I am really tired ATM

The existing grub install script is located at /usr/sbin/grubconfig , but I cant make head nor tail of it, but it might hold some clues

[rcrsn51]

I have uploaded new versions of the scripts.

I did all my testing in 4.1.2 and it turns out that the GRUB package is different in 4.2.1. In particular, the grub-install program does not exist there. So I used a different technique to get GRUB installed.

I have also updated the full-install script to copy the pup_421.sfs file.

BTW, the full-install script uses a very simple method to copy the sfs file from the CD to the hard drive, and it seems to work. But I notice that BarryK's Universal Installer is doing something more complicated. So I can't vouch for the reliability of my version.

[Edit] I have modified the full install scripts to run the Puppy Universal Installer. That should guarantee that the procedure is done correctly.

When the PUI gets to the step for installing GRUB, just cancel.

[ecomoney]

SUCCESS, they both work fine on the testing rig I have here with 4.2.1!!!

The origional scripts for 4.1.2 (which luckily I kept a copy of) Ive submitted to the HanSamBen project...which is a kids educational distro like EduPup. I had to tweak the the originals (which Ive attached my copy of below), as HSB uses "pup_412hsb.sfs" as its squash file.

The FRUGAL install should work with 4.x.x series before 4.2..perhaps 3.x series also....the FULL install just for 4.1.2 From what I understand the earlier kernels assign differently named mount points...I gave the scripts a quick try using 2.14r (2.6.18.1 kernel) and the scripts failed through not being able to find files. Some clarification of how this works would be useful, as I know quite a few people are still using 2.xx series on really old computers as they need the earlier kernel.

[rcrsn51]

Glad to hear that the scripts worked. Here are a few points:

The 4.2.1 version should work on 4.1.2 with one change. On line 48, the GRUB stage files are copied from the folder /usr/lib/grub/i386-pc. But in 4.1.2, they are located in /usr/lib/grub/i386-t2.

For Puppies in the 2 and 3 series, things get more complicated. In the current versions, the hard drive is identified as /dev/sda and the optical drive as /dev/sr0.

In older versions, the hard drive will be /dev/hda and the optical drive could be hdb, hdc or hdd, depending on how the drive is cabled. So you would need to modify the script to search all the drives for the Live CD. Also, old versions may use a zdrv file that must be installed.

[rcrsn51]

I had a look at the download in the HSB thread and the full-install script does not yet have the patch for the .sfs file.

It would be worthwhile to start adding an identifier to the names of any modified scripts, like "frugal-install-hsb"

[Edit] I have updated the attachment on Page 1. It now contains scripts (both frugal and full) that will install Puppy 2.17.1, 3.01, 4.1.2 and 4.2.1. These should act as reasonable templates for creating additional installers.

The full installers now use the PUI to do the actual copying. When it gets to the step for installing GRUB, just cancel.

@ecomoney: Could you please delete the versions that you posted directly above? They may confuse the issue.

[rcrsn51]

[deleted]

[ecomoney]

Have deleted the attachments as requested

Thanks for updating the scripts for previous version. The issue now is how to make them available for "newbies". Perhaps a .pet? Crash, would it be possible to include the routines in the init script?

Perhaps there is time to get them included in Woof?