Kernel 2.6.27 and squashfs 3.4 patch problem [solved]

[amigo]

These erros: 'incompatible pointer type' are non-critical -they just indicate that the code doesn't meet certain compiler standards. As long as the compile proceeds there is nothing to worry about.
The lzma errors are another matter. I'll have to look at the code of the patch and see what is going on. I suspect that you'll need to replace the busybox lzma with the real thing -but I'll check this out.

[Sit Heel Speak]

I suspect that you'll need to replace the busybox lzma with the real thing...

Buenos tardes amigo,

Errrr...didn't I replace busybox-lzma with the real thing, when I installed lzma-458.pet?

If the command line which the make process feeds to lzma is in error, then might not this indicate an error in Makefile?

If I choose gzip as the kernel compression algorithm in "make oldconfig", then the new kernel 2.6.27.2 does boot, and the desktop comes up, but then Puppy hangs, freezes solid, requiring cold-boot using the power button, after my 6 ATA-drive partition icons appear, but before the first of my 8 SCSI-drive partition icons appear. I must say though...it certainly boots with amazing speed! --like, 15 seconds from decompressing the kernel to desktop!

I tried putting Mark's 2.6.27 source code through the same build process, again choosing gzip as the kernel compression algorithm, but the new kernel goes into a panic shortly after decompressing.

While waiting for the results of your examination, I will try installing the newest gcc and glibc from gnu.org, so all the libs are unstripped --hardly suitable for a Puppy distro, but we'll see if having the full lib headers et cetera makes any difference.

Then, if I still don't succeed, I'll try building the patched 2.6.27.2 kernel in Gentoo. If that doesn't succeed, perhaps I'll resign myself to relying on Mark for new Muppies...then again, perhaps not...

[MU]

Try the the atached lzma.
I needed it once in my experiments, but don't remember, when.
If you have no matching lzma package installed, you should get only a bzImage 16 kb in size.
So if your is ok in size, you will not need this pet.
Mark

[MU]

people with wireless atheros chipsets might need a special version of "Madwifi".
This seems to be the case for the "eeepc".
I uploaded a pet here:
http://www.murga-linux.com/puppy/viewto ... 166#242166

Mark

[big_bass]

A screen shot

booted puppylinux 4.1 using the slackware 12.1 kernel
I am running tests still all seems to be working fine

I was so happy to get it all working

I forgot to mention I have the drives listing correctly also
look at the image

hda1
hda2
hda3
hda4

big_bass

[amigo]

Yeah, I'd avoid lzma-4.58 as it is unstable -in fact it is using a new compressed format. Also, you can't simply upgrade to the latest glibc. glibc is the heart of the system and every single program on the system is compiled against that. Upgrading will usually break the system entirely unless you are upgrading everything else at the same time. Hanging during the bootup is most likely due to some other error.

[Sit Heel Speak]

Success.

lzma-utils-4.32-5.pet indeed was the magic key.

Compiling k2.6.27.2 is actually simpler than 2.6.25.16. You don't need the unionfs-2.5_for_2.6.27-rc6.diff patch. The 2.6.27.2 source already has the unionfs patch's changes incorporated.

Also no need for the fsync_super and deny_write_access patches. Also incorporated already into the source.

All it needs is the 3.4 (rc4 version) squashfs patch and amigo's lzma patch.

1:30 AM here, bedtime. I will tune it up, build a comprehensive set of modules, and package /usr/src/linux into a tarball over the weekend, time permitting.

[MU]

I recompiled the kernel (took just some minutes), after a slight change.

/usr/src/linux-2.6.27/drivers/block/loop.c

line 1528:

old:

Code: Select all

		nr = 8;

new:

Code: Select all

		nr = 23;

Then after some small changes in initrd.gz, I can mount 20 sfs files
The new bzImage works with the old modules that I compiled before.

Mark

[raffy]

Great - would be happy to test-run it.

(FYI, the edit date of the posts do not appear at present, so readers can not tell if the first post has been updated recently.)

[MU]

Great - would be happy to test-run it.

(FYI, the edit date of the posts do not appear at present, so readers can not tell if the first post has been updated recently.)

Raffy, try to replace vmlinuz and initrd.gz with these:
ftp://ks301128.kimsufi.com/testing/pupp ... ate-20sfs/

I did not test it in Puppy 4.1 (current patched iso) yet, only in Muppy 008.4.
I just applied the same changes to Puppys initrd.gz now.
So I hope, I forgot no changes.

The bootmanager still will say "only 3 possible", as the 3 is hardcoded, and I'd have to to upload the whole iso again for that small change.

Look, if /initrd/pup_ro[3-22]
is populated with files to check, that they were loaded.

Mark

[BarryK]

I recompiled the kernel (took just some minutes), after a slight change.

/usr/src/linux-2.6.27/drivers/block/loop.c

line 1528:

old:

Code: Select all

		nr = 8;

new:

Code: Select all

		nr = 23;

Then after some small changes in initrd.gz, I can mount 20 sfs files
The new bzImage works with the old modules that I compiled before.

Mark

I thought that there is a technical limitation, you can only have /dev/loop0 - 7, because of the way the devnode major and minor numbers are assigned. But then, perhaps my information on this limitation is out of date.

[MU]

I found this via google:

Code: Select all

for i in `seq 0 255`; do mknod -m 660 "/dev/loop${i}" b 7 $i; done 

So I ran:

Code: Select all

for i in `seq 7 22`; do mknod -m 660 "/dev/loop${i}" b 7 $i; done 

Then I copied the new nodes to initrd.gz.

In init, I increased the nodecount:

in section:
######################SETUP UNIONFS LAYERED FILESYSTEM########################

around line 1026 (might differ, as I added other slight changes before):

Code: Select all

    [ $CNTLOOP -eq 6 ] && break #kernel supports max 8 loop devices,

to:

Code: Select all

    [ $CNTLOOP -eq 23 ] && break #kernel supports max 8 loop devices,

And around 1255 added:

Code: Select all

  [ -d /pup_ro6${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro7${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro8${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro9${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro10${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro11${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro12${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro13${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro14${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro15${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro16${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro17${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro18${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro19${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro20${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro21${ONEDIR} ] && rm -f $ONEOPAQUE
   [ -d /pup_ro22${ONEDIR} ] && rm -f $ONEOPAQUE

and around line 1309:

Code: Select all

mkdir -p /pup_new/initrd/pup_ro6
mkdir -p /pup_new/initrd/pup_ro7
mkdir -p /pup_new/initrd/pup_ro8
mkdir -p /pup_new/initrd/pup_ro9
mkdir -p /pup_new/initrd/pup_ro10
mkdir -p /pup_new/initrd/pup_ro11
mkdir -p /pup_new/initrd/pup_ro12
mkdir -p /pup_new/initrd/pup_ro13
mkdir -p /pup_new/initrd/pup_ro14
mkdir -p /pup_new/initrd/pup_ro15
mkdir -p /pup_new/initrd/pup_ro16
mkdir -p /pup_new/initrd/pup_ro17
mkdir -p /pup_new/initrd/pup_ro18
mkdir -p /pup_new/initrd/pup_ro19
mkdir -p /pup_new/initrd/pup_ro20
mkdir -p /pup_new/initrd/pup_ro21
mkdir -p /pup_new/initrd/pup_ro22

Finally I created in initrd.gz the folders:
pup_ro6
to
pup_ro22

This works well.
Just if I run losetup, it only displays loop0 to loop9, the others are ignored.
But they are mounted, so I think it is a limitation in the busybox losetup.

The Kernel can handle 255 loopdevices.
If the loop.c is not modified, you can activate them by a Kernelparameter in Grub:
"max_loop=255"

If that is not set, the maximum is 8.
So I increased it in loop.c, so that no kernelparameter is required.
I did not try yet, if 255 would be slower, but I think, 20 sfs files should be more than enough.
Though Slax has tons of sfs files, and so has activated 255, if I remember well.
http://www.slax.org/modules.php
Those are only official ones, I once saw a page with dozends of them. Even small programs of 3 MB were offered as mo/sfs.

I can test tomorrow, if 255 makes any difference.

Mark

[raffy]

The initrd and vmlinuz that you provided are working now, thanks. I can see pup_ro3 - pup_ro22. (But what is the top-level pup_z, just curious.)

In Slax, I have used up to 10 modules some 2 years ago, and 255 was said to be the maximum number for loadable modules. UnionFS did have its problems, but I was lucky not to have problems in my install.

[MU]

I replaced the new optional vmlinuz with a new one.
It is identical to the one before, but now I increased the possible loopdevices to 255 in loop.c.
I could not find any disadvantages.
Note: to mount more than 20 sfs, you also had to modify initrd.gz correspondingly.
I did not do this, I just uploaded the vmlinuz to show, that support of 255 loopdevices should be ok.

Some info about my plans:
next week I'm offline.
I'll travel to northern germany, to the company and visit my mother.
We will test my current Muppy 008.4d with 2.6.27 there.
I meanwhile also modified the boot-scripts, so that they use unicode (the default in this kernel).
So Muppy 008.4d will be a completly unicode based system.
If the tests are ok, I might compile 2.6.27.4 then (not released yet), and upload Muppy 008.4d in the following week.

Mark

[MU]

I encounterd a problem:
running the kernel with support for 255 SFS in Muppy.
It was compiled in Puppy.

After a varying amount of time, the screen just showed "stripes", the computer was completely frozen.

It took some time to identify the Kernel as the problem,I first thought,my graficscard was broken.

The error did not appear with the kernel without the support for 255 loopdevices.
I also did not encounter it with the 23 loopdevices,but mabe it just takes longer there.

The error might be in loop.c:

Original:

Code: Select all

	if (max_loop) {
		nr = max_loop;
		range = max_loop;
	} else {
		nr = 8;
		range = 1UL << (MINORBITS - part_shift);
	}

255 patch:

Code: Select all

	if (max_loop) {
		nr = max_loop;
		range = max_loop;
	} else {
		nr = 255;
		range = 1UL << (MINORBITS - part_shift);
	}

We now might need this:

Code: Select all

	if (max_loop) {
		nr = max_loop;
		range = max_loop;
	} else {
		nr = 255;
		range = 255;
		//MU range = 1UL << (MINORBITS - part_shift);
	}

I will check this in the nex days.

-------------------------------
Another issue:
I wanted to compile nvidia drivers in Muppy.
They need "linuxversion.h",that is not in the Kernelsource,but created,when you run "make" on the kernelsource.
So it IS included in my SFS with the precompild kernelsource.
But this was compiled with Puppys compiler, not with Muppys compiler.
So the nvidia compilation scrpt complained about some non matching issues.
This means:
though the kernel is binary compatible, I must provide Muppy with a new "pre-compiled kernel source SFS", this time compiled in Muppy.

This problem will encounter everyone, who upgraded Puppy with a different compiler lateron.

More details next week.
Mark

[raffy]

Related info: "Linux 2.6.27 will be a longtime supported kernel"
http://kerneltrap.org/mailarchive/linux-kernel/2008/10/15/3661414/thread

[MU]

it seems that the second modification of loop.c mentioned in my previous message fixed the crashes that I encountered with 255 loops.

I use Muppy 0084 with this new kernel based on the fixed code, now compiled in Muppy itself, and have no more crashes.
Tested that on 2 computers, they ran hours now.

Sidenote:
if you want to use the Standard-Puppy to use more SFS files, read this thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=35266

It describes a method, where you need no recompiled Kernel, and also provides the required patched initrd.gz.

Mark

[Béèm]

Mark,
I had a pleasant surprise when I tried again puppy on my Medion MD8818 PC which has a VIA controller (5287 or 8287, can't remember) and the sata drives supported in IDE mode. For a long time this wasn't supported, even in other distro's, but in puppy 4.1.1 it is now.

Would this support have been added by Barry on purpose or is it in the available source?

Would this support be in the 2.6.27 also then?

[MU]

I have no idea.
But there is a good chance.
I think the whole sata stuff or harddisk related issues were completely rewritten for the new kernels.
E.g. now all drives have the device "sd", no longer "hd" (hda1, hda2 ... ).

So it is possible, that this support is due to this new architechture.
This is one reason, whyI wanted to use a newer kernel in the next Muppy.

Mark

[Béèm]

In spite of what you have written, you'll bring out a next Muppy?
Then I'd like to test it on this Medion PC, as there is still a problem.
The MD8818 has an external bay in which an external HDD can be plugged on e-sata. With puppy 4.1.1 this second HDD isn't seen.

Any time frame?

BTW, I applied the 20 sfs files initrd.gz.. Nice work.