Hacking Puppy's init script

Using applications, configuring, problems
Post Reply
Message
Author
Bruce B

Hacking Puppy's init script

#1 Post by Bruce B »

Hacking Puppy's init script

for gyro and . . .

. . . in the good spirit of FOSS for anyone and everyone :)


Purpose: to offer a few tips on modifying init which have been
helpful to me.

How modifying init started for me: I wanted to experiment with
pup_save as an ext3 file system. In order to do this init's mount options
needed to be modified. (also the pup_save file needed to be converted
to ext3)

I don't have all the notes put together at the time of this post. It may
take a few posts before the 'story' is complete. I'll just start with what I
have.

This post will show how to unpack and repack initrd.gz ( the Pizzasgood
way, I think )

Unpack

cd to directory containing initrd.gz
mkdir initrd-tree
cd initrd-tree/
zcat ../initrd.gz | cpio -i -d


Pack

cd again to initrd-tree
rm ../initrd.gz
find . | cpio -o -H newc | gzip -9 > ../initrd.gz

Not very hard

But I think writing a script with some options and some additional
functionality would be nice. I'll try and do that.

Request 1. IIRC packing initrd.gz this way started with 3.00 ? Can anyone
verify this or correct it if needed.

Request 2. For the sake of information, does anyone recall off hand how
earlier initrd.gz were packed and unpacked AND how about the Puppy
1.xx version of init?

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#2 Post by gyro »

Bruce,

Thanks.

OK, done that.
Now I have a directory that includes the "init" script along with a few directories. So I'm ready to start editing.

gyro

vg1
Posts: 142
Joined: Sun 02 Dec 2007, 18:56

#3 Post by vg1 »

Bruce,

I keep these two scripts handy & copy the approriate one to my working folder
for p2 'editinitrd':

Code: Select all

#!/bin/bash 
 
a=`getdir $0`
cd "$a"
a=`pwd`
cd "$a"

 gunzip initrd.gz 
 mkdir /root/minit 
 mount -o loop initrd /root/minit 
 leafpad /root/minit/sbin/init
 leafpad /root/minit/PUPPYVERSION 
 sync 
 umount /root/minit 
 sync 
 gzip initrd 

 sync 
# umount /mnt/hdd2 
for p3 & p4 'editinitrd-cpio':

Code: Select all

#!/bin/bash 

 mkdir initrd-tree
 cd initrd-tree
 zcat ../initrd.gz | cpio -i -d
 leafpad init
 leafpad PUPPYVERSION 
 find . | cpio -o -H newc | gzip -9 > ../initrd.gz

# umount /mnt/hdd2 
The scripts were originally Mark's and Pizzasgood's, I adapted them for my purpose.

As I drop the initrd.gz on the script leafpad opens with init, I edit, save & close. Leafpad then opens with puppyversion, I edit or not, and close, and the new initrd.gz is repacked & ready. The only thing to look out for is always work with the version which will use the initrd. Otherwise it may not work. I think it's a kernel thing.

I find this convenient & fast. Gyro this could speed up your work.

regards
vg

Bruce B

#4 Post by Bruce B »

gyro,

Putting the horses before the cart

We can mount an ext3 as an ext2

We cannot mount an ext2 as an ext3

Modifying the file system comes before or at the same time as
modifying init. We cannot modify init first then boot an ext2.

Changing ext2 to ext3

The tool to use is tune2fs, I've used it on partitions. But I've not used it
on pup_save enough to state the best way.

What I've done basically is simply format my pup_save files as ext3. This
is one place I'm moving a bit ahead of myself. I like to test things before
posting. So I won't say anything in this post about converting pup_save
until I've tested and am satisfied.

For starters, you could rename your pup_save files so Puppy won't find
them. xxx_save.2fs will be fine.

Then make a new .3fs file, in the proper pusbdir directory, like this:

dd if=/dev/zero of=pup_save.3fs bs=1M count=256

where count= will be megabytes, in the example it is 256 MB

mkfs.ext3 pup_save.3fs

Now you have a nicely built and formatted file. When Puppy boots it will
fill the data for you and give you a nicely working file. In other words,
Puppy is good with an empty pup_save file.

Modifying init

You want to search for ' -t ext2' - this will pick up the commands
where pup_save gets mounted as -t ext2 and you change it to -t ext3

Remembering my work has been with version 400, the init changes in
some ways, but not likely in this way. Nevertheless, make backups and
consider your work an experiment, if you will.

In init, you'll find maybe three lines like this:

mount -t ext2 -o noatime /dev/loop1 $CREATEPUPSAVE2FS

You could simply change them to this

mount -t ext3 -o noatime /dev/loop1 $CREATEPUPSAVE2FS

My options are a bit more elaborate, but that can wait.

For now I think just change as shown above in dark red. Remembering to
keep initrd.gz back ups.

Bruce

PS - after you are done, run 'mount' command and verify indeed it is mounted as type ext3



Thank you - vg1

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#5 Post by gyro »

Bruce,

Thanks again for the prompt reply.

I have a significant amount of stuff in my ext2 pup_save. So my plan is:
Create new initrd.gz.X
Make an empty ext3 file
Mount both files in a Puppy that isn't using the particular ext2 pup_save file
Copy the files from the ext2 to the ext3
Rename the ext2 file so it will not be found by Puppy
Rename the ext3 file to pup_save.3fs
Rename old initrd.gz to initrd.gz.Z
Rename initrd.gz.X to initrd.gz
Reboot to the puppy that uses these files

If things don't go well, all I have to do is boot with a different Puppy, and rename four files and I'm back in business.
Hm.., I might be able to get away with just going back to the old initrd.gz. I wonder if the standard init script will mount pup_save.3fs as an ext2 file system??

It might take me a few days, but I'll reply again when I have a result.

gyro

Bruce B

#6 Post by Bruce B »

gyro wrote:
{big snip}

It might take me a few days, but I'll reply again when I have a result.

gyro
That would work out swell. I'll continue posting without a feeling of rush.

For everyone else. This topic started based on a discussion between
gyro and myself in another topic. It didn't just come out of the blue, but
was enough of a divergence from the other topic to warrant a new topic,
(IMO)

For a little background, gyro and myself concluded an ext2 to ext3 is not
a conversion we'd want to make on a flash stick.

The flash stick writes are buffered for long periods of time, a default of
think of 30 minutes buffering, which is user adjustable, then written to the stick.

I'm curious in any one knows if flash stick writes are synchronous or asynchronous.

The hard pup_save pretty much writes in real time.

Summary: if you are running a Puppy Frugal on any other than a hard
disk, you might consider the ext3 conversion part of these postings
as 'only a matter of interest'. Although, it's just software and it wouldn't
hurt to experiment, as long as user data is backed up.

Bruce

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#7 Post by gyro »

Bruce,

Well back sooner than expected.

Here's the good news:
Did Geany "Replace" of "ext2" with "ext3" on init script, not every one, but more than the actual "mount" commands. (I'll document exact changes later.)
Created new initrd.gz and setup pup_save.3fs as ext3.
Booted into this Puppy, and it came up with the new pup_save.3fs, yes "mount" shows that it is ext3.
No problems, no worries. Everythings going great! Thanks for the help Bruce.

Here's the bad news:
On shutdown, got a "journal commit I/O error", oops!
Booted into other Puppy to do fsck on it,
Got this:

Code: Select all

# losetup /dev/loop2 /mnt/home/EzPup/pup_save.3fs 
# fsck -y /dev/loop2 
fsck 1.40.2 (12-Jul-2007)
e2fsck 1.40.2 (12-Jul-2007)
/dev/loop2: recovering journal
Clearing orphaned inode 6151 (uid=0, gid=0, mode=0100666, size=69228)
Clearing orphaned inode 6150 (uid=0, gid=0, mode=0100666, size=48744)
Clearing orphaned inode 6149 (uid=0, gid=0, mode=0100666, size=344280)
Clearing orphaned inode 6148 (uid=0, gid=0, mode=0100666, size=4096)
Superblock last mount time is in the future.  Fix? yes

/dev/loop2: clean, 22042/98304 files, 273021/393216 blocks
#
If I do it all from console, everything is clean:

Code: Select all

# losetup /dev/loop2 /mnt/home/EzPup/pup_save.3fs 
# mount /dev/loop2 /mnt/data/
# mv /mnt/data/root/workX.txt /mnt/data/root/workXXXX.txt 
# umount /mnt/data/
# losetup /dev/loop2 /mnt/home/EzPup/pup_save.3fs 
# fsck -y /dev/loop2 
fsck 1.40.2 (12-Jul-2007)
e2fsck 1.40.2 (12-Jul-2007)
/dev/loop2: clean, 22042/98304 files, 273023/393216 blocks
#
So my concern is now probably more related to the original thread, why does fsck habitually report errors on pup_save file? Is Puppy not properly umounting pup_save?

gyro

Bruce B

#8 Post by Bruce B »

gyro,

You are exceptionally easy to work with!

If I mount these file system by hand, extra ones I tack on to Puppy and
never an error.

When Puppy mounts the pup_save almost always the same error
'orphaned inodes' - at first, like yourself they bothered me, but after
months of use, they don't bother me, except I'd like to know the reason
why.

The reason they don't bother me is these problems are cleaned up in
the journal, it doesn't need a full check to locate the problems, moreover
I've never seen a hint of data loss.

Last mount time in the future has to do with where you are in the world.
Init runs with no TZ offset. Puppy shuts down with a TZ offset but doesn't
start with one.

I think this happens on the full checks only.

Did you note my e2fsck log from the other post?

There is a very bright side to this. I've only had orphaned inodes, nothing
else. Meaning; any and all problems have been limited to this. This is
clearly not the case with the ext2

What I don't think either of us have done is an Internet on orphaned
inodes + loop device. There might be a understandable reason and fix.
But it hasn't been high on my never ending list of things to do, because
it's not hurting anything.

Did I leave any thing out?

Bruce

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#9 Post by gyro »

Bruce,

I did a quick and dirty edit of the init script as a proof of concept. And it worked fine. With your help, I've reached the point where I'm confident I can do the ext3 thing in init.

But is there any likely scenario where I might end up with a corrupted pup_save.3fs, (which can quickly heal itself), but with no corruption of the underlining NTFS file system? I doubt it. But on the other hand e2fsck seems to find less errors in a pup_save.3fs than a pup_save.2fs, and on a hard drive any overheads of ext3, are 100% acceptable.

If I decide to really use ext3 pup_save files, I'll do it again and document it this time. And if I'm feeling really good I might even see if I can hack init to mount as ext2 if the file is ".2fs" and mount as ext3 if the file is ".3fs".

If I get around to doing any of this, I will post back here.
Otherwise I'm going to take my concerns with pup_save files apparently not being umounted properly, back to the e2fsck thread.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

init script to support ext3 and ext2

#10 Post by gyro »

Hi,

I've attached a copy of my "patched" version of the "init" script from "initrd.gz" in Puppy 4.1.2.
It will mount the pup_save file as either ext2 or ext3, depending on the filename. It the filename ends in ".3fs" it will use ext3, otherwise it will use ext2.

To make use of this file you need to unzip the downloaded file, and then replace the file "init" within "initrd.gz", using the techniques described by Bruce above.

To see my changes, edit the new "init" file and search for "gyro". The first instance should be in the beginning of the "fsck_func" function, where I allow both "ext2" and "ext3". The second instance should show where I introduce a new variable "INT_PUPSAVEFS", (internal pup_save file system). Then searching for "INT_PUPSAVEFS" should show where I have replaced a hard-coded "ext2" with "INT_PUPSAVEFS".

gyro
Attachments
init.zip
"patched" copy of the init script from initrd.gz in Puppy 4.1.2
(16.83 KiB) Downloaded 745 times

Bruce B

#11 Post by Bruce B »

Gyro,

Here is line 493 of your init file

read NUMSAVE

It shows only if you have more than one pup_save file. If
you do, it requires you to enter a number and hit the
enter key.

If you want to avoid hitting the enter key and just enter a
number change it to this:

read -n 1 NUMSAVE

Only do this if you have less than 10 pup_save files,
because the instant one key is received it acts on it and 10
is two keys.

There is also a way to default to a particular save file after
so many seconds, thus requiring no interaction, except
when you don't use the default (as defined by you)
pup_save file.

Bruce

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#12 Post by gyro »

Bruce,

Apart from the changes I made to support both ext2 and ext3 pup_save files, as outlined above, it is a standard init script from Puppy 4.1.2. And I'm content to leave it like that.

gyro

sidders
Posts: 464
Joined: Wed 23 Jul 2008, 18:47
Location: Bolton, uk

#13 Post by sidders »

To automatically create a ext3 (3fs) on the initial shutdown after a frugal install to compliment the hacked init , would it be good enough to tinker with the rc.shutdown script.

Off the top of your head, do you know of any adverse effects saving it to a NTFS partition for example.

Bruce B

#14 Post by Bruce B »

sidders wrote:To automatically create a ext3 (3fs) on the initial shutdown after a frugal install to compliment the hacked init , would it be good enough to tinker with the rc.shutdown script.
sidders,

I always make it on the way up, never on the way down. Puppy has been happy to populate an empty file
sidders wrote: Off the top of your head, do you know of any adverse effects saving it to a NTFS partition for example.
Not specifically, I doubt it, but I think NTFS is an adverse effect and I don't even use them, so what could I actually know?

You must find a more objective opinion.

Bruce

Bruce B

#15 Post by Bruce B »

Sidders,

Reading more cautiously. Making a pup_save.3fs is not a problem. In order for it to be of value, it must be mounted as a 3fs.

/dev/loop1 on /initrd/pup_rw type ext3 (rw,noatime,nodiratime,data=journal)

Bruce

sidders
Posts: 464
Joined: Wed 23 Jul 2008, 18:47
Location: Bolton, uk

#16 Post by sidders »

Thanks Bruce. I will do some experimenting.

Bruce B

Lesson?

#17 Post by Bruce B »

if you don't feel confident, I can stuff it into a lesson in the TUI series, it has a place

But let me know!

Jim1911
Posts: 2460
Joined: Mon 19 May 2008, 20:39
Location: Texas, USA

#18 Post by Jim1911 »

Bruce,

I have converted a number of pup_save.2fs files to .3fs and had no problems with the .3fs, but could see no advantage. However, the .3fs was never mounted properly.

Please do
stuff it into a lesson in the TUI series
and post a link to your TUI series. I have learned a lot from your posts although many are over my head.

How can we get Barry to revisit this ext2, vs ext3 question? Of course, now it's (ext4) also, since woof series pups now recognize ext4 partitions.

Still learning, Thanks,
Jim

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#19 Post by gyro »

Jim1911 wrote: However, the .3fs was never mounted properly.
The pup_save file is mounted by a script called "init", which resides within "initrd.gz". The release version of "init" always mounts the pup_save file as ext2. To get an ext3 pup_save file mounted as ext3, you need to use a modified "initrd.gz" containing a modified "init" script.

I posted a modified "init" script for puppy412, earlier in the thread that mounts pup_save.3fs files as ext3 and pup_save.2fs files as ext2.

I would like to see the release version of "init" modified so that it mounts:
pup_save.2fs as ext2
pup_save.3fs as ext3
pup_save.4fs as ext4.
Then users only have to convert and rename their pup_save file to use the filesystem of their choice. Don't have to generate a new initrd.gz.

gyro

Post Reply