I patched it with unionfs 2.5.2 and squashfs 3.3.
The kernel has the name 'ext4dev' for the ext4 filesystem, so you actually have to do this:
# mount -t ext4dev <device> <mount-point>
However, there have been many upgrades and ext4 in the '29' release should be stable.
I could not find a suitable patch to convert the name from 'ext4dev' to 'ext4', so I wrote a script that simply finds all occurrences of 'ext4dev' and 'EXT4DEV' and substitutes with 'ext4' and 'EXT4'.
The kernel works fine in my full-hd installation, so I went ahead to package it all up, make sfs and so on. I also compiled lots of 3rd-party modules. I also upgraded the ALSA drivers to version 1.0.20.
Darn... this morning I have tested a live-CD built with the 22.214.171.124 kernel, and the squashfs module crashes on loading.
So, I have to start again. Find a better squashfs patch first...
Note, I want to stay with squashfs 3.3. I'm not happy that the Puppy 4.x series should have two incompatible squashsfs systems (3.3 and 4.0). So, I was thinking if 126.96.36.199 performs well, I'll choose it as the "advanced" kernel.
Right now I have to do a hunt to locate a squashfs 3.3 patch that has been verified to work with the 2.6.27.x kernel.
Comments:Posted on 9 Aug 2009, 9:44 by BarryK
Interesting, Michael Tokarev has backported squashfs 4.0 from 2.6.29 (and 2.6.30) to work on the 2.6.27 kernel:
And this guy 'hawk' has backported squashfs 4.0 from the 2.6.30 kernel:
Well, there doesn't seem to be a squashfs 3.3 patch available for the 2.6.27 kernel, but the 3.4 patch is available. If I want to be compatible with sfs files created for Puppy 4.21 and earlier, I could use the 3.4 driver but use the 3.3 mksquashfs, as the 3.4 driver will recognise and use sfs files created by the 3.3 mksquashfs.
On the otherhand, if I use the 4.0 patch, then sfs files will be compatible with all later kernels and upcoming Puppy5 builds. Hmmm...
Posted on 9 Aug 2009, 9:58 by dogone
I don't see any reason not to go with squashfs 4 so long as users are informed of the incompatibility and a suitable solution (conversion tool) is provided. The issue has to be addressed sooner or later. Perhaps a suitable "wizard" can be provided.
Posted on 9 Aug 2009, 10:07 by BarryK
sfs 3 to 4
It's easy enough to convert a sfs from 3.3 to 4.0. I think someone was working on a tool to do that on the forum?
Posted on 9 Aug 2009, 10:27 by Jota
advantages of squashfs 4.0?
What are the technical advantages squashfs 4.0 has over 3.3? Do they justify the move?
And, if you choose 4.0, then why not use the later 2.6.30.x kernel?
Since sfs's made for 4.12 and 4.21 will be able to run unmodified in 4.3, but maybe not in Puppy5, it seems more wise to do the change in squashfs only with Puppy5, unless the advantages justify the move.
Posted on 9 Aug 2009, 10:56 by dogone
No matter when the move to squashfs 4 is implemented, we face the scenario of a user up-converting his one and only pup_save file and then deciding to switch back to an older Puppy. Whichever Puppy release embraces squashfs 4, it ought to avoid this problem by backing up the user's pup_save file prior to conversion. And if possible, a means of regressing a pup_save or *.sfs to the 3.x format ought to be provided.
Posted on 9 Aug 2009, 14:12 by Sit Heel Speak
squashfs 3-4 conversion
Barry wrote: ...It's easy enough to convert a sfs from 3.3 to 4.0. I think someone was working on a tool to do that on the forum?
Mark Ulrich's squashfstools.pet?
Posted on 9 Aug 2009, 16:11 by disciple
the save file is not squashfs
dogone - the save file is not a (read-only) squashfs filesystem image, it is a (writeable) ext2 or ext3 image.
Squashfs incompatibilities are a problem for extra .sfs addons that people might use (often for large things like Openoffice or KDE). We have had a similar problem before, as the filesystem structure was different inside squashfiles for Puppy 1.x, although squashfiles were probably less prolific back then. But the really bad problem now is that we have two .isos of current puppy releases, with two different kernels, and we don't want everybody to have to make two copies of their squashfiles.
Posted on 9 Aug 2009, 16:16 by zigbert
Posted on 9 Aug 2009, 19:02 by BarryK
squashfs for 188.8.131.52
I'm still trying. The official 3.4 patch gives an error when compiling the kernel.
What annoys me is that I think I went through this before, and did find a patch that works with the 2.6.27.x kernel. Can't find it now though.
Posted on 9 Aug 2009, 23:02 by dogone
re: save file is not squashfs
Thanks disciple. I stand corrected. Live and learn.
Faced with the challenge of creating, identifying and maintaining .sfs apps in both versions, devs are likely to stick with sfs 3.x for full compatibility.
Perhaps the issue boils down to two questions:
Do we want to *prevent* Puppy 4 series users from packaging apps in sfs v4?
Do we want to *prevent* Puppy 5 series users from packaging apps in sfs v3?
Yes to both might minimize the pain.
Posted on 10 Aug 2009, 8:29 by kirk
Here's the one from the squashfs-lzma web site. The lzma stuff is separate patches.
Posted on 10 Aug 2009, 9:03 by gposil
squashfs patch for 2.6.27.x
Barry, you have done the patch before, I use your 184.108.40.206 in dpup476
Posted on 10 Aug 2009, 9:43 by Sit Heel Speak
squashfs 3-4 conversion
Barry wrote: "What annoys me is that I think I went through this before, and did find a patch that works with the 2.6.27.x kernel. Can't find it now though."
I believe you want this one, which MU and self successfully used on 220.127.116.11, it was on Ted Dog's site, late of fond memory:
File name: squashfs-rc4-3.4-patch
File size: 0.12MB
Description tags: 2.6.27-rc4 squashfs 3.4 patch
# md5sum squashfs-rc4-3.4-patch
Posted on 10 Aug 2009, 9:47 by Sit Heel Speak
squash-3.4 2.6.27.n patch
Agghhhh, the above message should have this title.
Posted on 10 Aug 2009, 12:17 by BarryK
Sit Heel Speak,
Thanks for that.
However, I might give up. Yesterday I tried two more patches from Gentoo, both failed to compile.
One of the Gentoo patches was for kernel 18.104.22.168, so I think something has changed in the 22.214.171.124 kernel that is causing the failure.
Posted on 11 Aug 2009, 14:14 by gposil
I don't know if you've got this one Barry....
Just thought i'd see if you have