Kernel Interchangeability

Puppy related raves and general interest that doesn't fit anywhere else
Post Reply
Message
Author
disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

Kernel Interchangeability

#1 Post by disciple »

This is not a request for a 2.4 kernel version or anything, just a request for knowledge. There must be someone out there that understands these things :) and has some time on their hands (maybe not though - these people are more likely to be busy improving puppy!)

Some distros (eg Mepis) you can choose when booting between using a 2.4 or a 2.6 kernel. I can't say I've used it anywhere near enough to really say this, but I did not notice any difference between running it with the two kernel versions.

How do they do this?

What are the repercussions of the choice of kernel for a distro like Puppy? Is it theoretically possible to put a 2.4 kernel in a recent Puppy? (somebody said with unionfs in 2.4, you could not make the whole filesystem writable as in Puppy 2.x - that would kind of make it impractical). Would a whole lot of other things have to be recompiled or what? What functionality would be lost?

I asked this elsewhere, but I'll repeat it anyway:
I see that NTFS-3G can now be used with a 2.4 kernel. (See
http://forum.ntfs-3g.org/viewtopic.php? ... ght=kernel
and a more recent post on that forum that confirms that it is now possible).
Does anybody know exactly what they mean about checking the data consistency?

Thanks

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#2 Post by GuestToo »

How do they do this?
basically, they duplicate all the kernel modules (drivers for hardware, file systems, encryption, etc etc)
Is it theoretically possible to put a 2.4 kernel in a recent Puppy?
as far as i know, newer versions of unionfs only work with the 2.6 kernel, and you need the newer unionfs to make the entire file system (/) writable (the way Barry is doing it, anyway) ... a full, normal install to a dedicated partition could have either or both kernels, as long as there is enough space on the hard drive

i guess you could do a full, normal, non-unionfs install to the file system in a pup_save file ... in which case all the files in the Puppy file system would be copied to the file system in the pup_save file ... /bin, /dev, /etc, /lib, /mnt, /proc, /root, etc etc etc

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#3 Post by disciple »

Hey, that sounds like a cool idea. Why couldn't I think of it? It would take a bit of work to come up with a good way to do it if you wanted to provide it as a way for people with old hardware to use a new Puppy though...

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#4 Post by Nathan F »

Early alpha snapshots of Puppy2 had a 2.4 kernel, and it did work but was buggy. Thinking back on it I'm not sure whether the bugs were in the 2.4 kernel, unionfs, or the fact that Puppy2 itself was so new and untested. I think it might be worth exploring but personally have no time.

I have an older laptop which only has full hardware support with a 2.4 kernel, so right now I run Slackware on it. It might be nice to run Puppy instead, but there were bugs with pcmcia in PUppy-1.xx that prevented it booting properly unless I disabled the entire pci bus (rendering most peripherals useless). Puppy-2.10 and newer all run OK on it, but with various issues relating to sound and usb. This one just does not like the newer kernel.

Nathan
Bring on the locusts ...

amish
Posts: 615
Joined: Sun 24 Sep 2006, 23:15

#5 Post by amish »

people still develop puppy 1, although not as much as they used to.
people also are actively developing puppy 2, as is barry.

i see no reason, if it's what people want to do, why they can't make puppy 2 and puppy 1 more compatible with each other. the ultimate goal would be that you COULD swap kernels, or, keep the same kernel and swap puppy 1 and puppy 2. sounds nuts? well, i liked the idea when i suggested it a while ago, and i like it now. if enough people see the merits of it then they can work on it, otherwise, i still think it's a good idea-but just an idea.

i would like to point out that when i say something like "when i suggested it a while ago" i really don't care who said it first, and in fact, most of the things i talk about are VERY similar to ideas that have been around for a while. i may have actually been the first to mention swapping kernels in puppy... so what?

what really matters to me is that more people talk about how we can make different versions of puppy come together more, without losing what makes them special. so i'll be talking about ways that can happen, and before i read this thread i was sure that the idea of puppy 1 and puppy 2 swapping was a pipe dream (or a pup dream!) but apparantly it's not as wild and "out there" as i thought. no problem!

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#6 Post by Nathan F »

Realistically speaking I don't think anyone will be working on using 2.4 in Puppy2 for a while, and I don't think it will work well for the live cd. However, I think it would be feasible to create a realtively easy way to add a 2.4 kernel to a full hard drive install of Puppy2. Most of it could be contained in a simple unleashed package, actually. But you would have to boot the live cd using 2.6 in order to do the installation. If nobody else takes up the challenge maybe I will when things settle down. I've compiled kernels for Puppy several times now anyway.

I do think it would be a good idea to update the 1.xx series anyway though, as it was a good solid disk to run live on older hardware. Definately there were advantages over the current Puppy in terms of supporting old obscure soundcards and also usb1 (which barely seems to work in 2.6 kernels). Why not a retropup iso? I think I'd enjoy it.

Nathan
Bring on the locusts ...

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#7 Post by disciple »

That's interesting (early alphas...)
You wouldn't want to put both kernels in a live CD, although if it wasn't too difficult to do it would be a cool idea to do a 2.4 live CD with Puppy 2 architecture every now and then - the trouble with the 1.10 concept is the lack of compatibility with most things people have been writing for 2.x (although it is surprising how many things do work if you try :)
What I was thinking is that G2s idea might be more useful than swapping the kernel in a hard-drive install - perhaps a CD that will boot something ultra-minimal, then put a file on the disk with a full install in it, and boot from that next time - so it would be like a frugal install, but with everything in the pupsave file.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#8 Post by Nathan F »

Really any configuration you can imagine is possible, it just takes work to implement. An idea I've had for a long time is a Puppy install only cd, which would boot a very minimal environment and immediately launch an installer. This would be a great boon to machines of a certain vintage, which can run a PUppy full installation quite well but have trouble with the live cd. These are usually the same machines that benefit from the 2.4 kernel as well.

And yes, I agree that an up to date iso with the 2.4 kernel would be desirable for a lot of reasons, and even better if it is based on the Puppy2 filesystem and init, with T2 binaries. The thing is though, unionfs probably will cause problems, remember Barry had reasons for going to 2.6. Actually, the last I looked there were no official downloads for unionfs in the 2.4 kernel anymore, so it would be quite difficult at this point.

Nathan
Bring on the locusts ...

muggins
Posts: 6724
Joined: Fri 20 Jan 2006, 10:44
Location: hobart

#9 Post by muggins »

nathan,

you mention that you were thinking of making a puppy install cd, for minimal computers, how difficult would it be to implement a script like veclinuxe's vinstall, to allow installation to hdisk directly from an iso image on hdisk?

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#10 Post by Pizzasgood »

What about Aufs? Does it have the same compatibility issues as UnionFS?

@muggins: for a frugal install, probably not very. I don't know about a full install, but probably not much more difficult than a frugal.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#11 Post by disciple »

This is a little off topic, but can you do a full install in a usb flash drive, or just a frugal install? This idea of doing a full install in a save file might be useful for flash drive installs also, as if you ever update any software or anything, it would save space (maybe this would not be worth it due to a lack of compression - if that is the case I guess it would slow booting also), and you could have a full install without partitioning in order to be able to use files in Windows as well...
Do many people use Puppy on flash drives?

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#12 Post by disciple »

Aufs is only developed and tested with a 2.6 kernel... I guess it could always be investigated further. Interesting reading Nathan's blog and seeing that in some ways Unionfs has gone backwards - can't load and unload squashfiles with a 2.6 kernel.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#13 Post by Nathan F »

Muggins - Probably not all that hard, but time consuming to get it all worked out right. Vector uses about the simplest possible installer, it just decompresses an image into the partition. Secondary images are available for big chunks of software, usually in groups. This is why installing Vector can be done in under half an hour, whereas some distros might go on for two to three hours (and then only the first couple cd's).

The issues with loading and unloading squashfiles while up and running have more to do with the fact that Puppy2 unions everything on the root filesystem rather than on /usr. In Puppy2 all of the unionfs tools fall inside the unionfs, along with any scripts you might execute to automate the process, and any programs. Interacting with unionfs is almost like causing a split second power outage, everything gets disconnected briefly. Aufs so far seems to be less picky about it, even though neither one was really intended to be used quite so heavily as is occuring in distros like Puppy and Slax. It would be nice if aufs were available for 2.4 kernels but it is only for very recent 2.6 at this point.

You could theoretically do a full install in a flash drive, but it isn't a good idea. With all the disk writes that would take place the media would quickly degrade and become unusable. I think I remember someone actually installed Windows98 on a flash drive once, and it failed after only a month or two.

It's good to throw ideas around like this though. I can tell already that there is interest in some things I have been considering as future projects, and can revise the ideas to match what is wanted or needed. A few totally new concepts are getting pushed forward too.

Nathan
Bring on the locusts ...

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#14 Post by Pizzasgood »

The OS in a filesystem-image (which is essentially the same as installing Puppy inside a save-file) is something I thought about when first learning about loop-back devices. That's actually what Puppy does already, except that it uses three images (two compressed and read-only and one normal).

You could technically put the entire pup_xxx.sfs file in initrd.gz and then just have two images, but since initrd loads into a ramdisk, you'd need more ram. It would use the same amount of ram for people who have enough, because for them the pup_xxx.sfs file loads into ram anyway. But for people without enough, the pup_xxx.sfs file doesn't load into ram. A big initrd.gz file wouldn't have that option.

You could also probably make a writable initrd.gz, and store the entire thing in it. Then all your changes would also be loaded into ram, and you wouldn't need UnionFS either. This would need the most ram, but would potentially be the fastest running. It would have to store your changes in the ramdisk, then recompress it and flash it back to the initrd.gz file at each shutdown though. You could use an uncompressed initrd instead, then just copy the data back at shutdown.

Another possibility is using just a normal, writable filesystem image. Not compressed or anything. I'm not quite sure how the archetecture of that would work, if the kernel can just mount it, or if you'd need to have a small initrd.gz to mount it and pivot_root. It's definitely possible though. Then you wouldn't get any ram-benifits, but you'd be directly writing to your data and using less ram.

All of those will work on any filesystem Linux can read, so long as you can get a boot loader to load it. If all that's availible is Windows partitions, you might have to use a boot-disk or put the bootloader in the MBR, but they'd work.

That last one seems the most obvious to me. I thought about it almost immediately after reading about loop-back devices and filesystem-images. At the time I was using ZipSlack, a stripped version of Slackware that comes in a 99MB zip file. You extract it into a directory on a FAT16 partition, and start it with a batch file and I think loadlin. It used UMSDOS to work directly in FAT, no images. However, it needed to make a bunch of files in order to keep up with the extra data a FAT partition doesn't store, like permissions. That meant if you looked at it from Windows, you'd see a bunch of weird files, and editing things from Windows was risky. So I thought, "Why don't they just put it in a filesystem image? It would be cleaner, use a normal ext2/3 filesystem, and be mostly safe from accidental edits from Windows.

Probably the biggest problem would be resizing the image. A script in the initrd.gz could do it, run by a keypress, or a boot parameter, or even by checking a flag when first mounting the file, unmounting, resizing, and remounting. If you were good enough, you could even get it to revert to initrd from within the image, unmount, resize it, then reload the image, without rebooting.


Personally, I'm a fan of Puppy's method. It keeps the OS itself small and pristine, runs fast, and is easy to work with because of the small number of files. Easy backups, easy upgrades, easy deletions.
Last edited by Pizzasgood on Wed 14 Mar 2007, 02:43, edited 1 time in total.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#15 Post by disciple »

Yes, Puppy's method is superb. But a single filesystem image would also be a pretty cool alternative method, as backups would be just as easy (but take up a little more space).

figueroa
Posts: 22
Joined: Fri 06 May 2005, 03:57
Location: Ohio
Contact:

Puppy 2.14, Kernel 2.6, older laptop, NO sound problems!

#16 Post by figueroa »

This is a rave. I've been using Puppy continuously and been a fan since late 2003, though I surely haven't posted to the forum for some two years.

I was disappointed when Puppy left kernel 2.4 behind, but lo and behold, since early in the 2 series, Puppy's 2.6 kernel has supported ALL of my laptop's (a KDS Valiant 671XH) hardware (except its lousy winmodem - nobody does that) automatically and flawlessly. Mainly, every other distro fails to properly configure the soundcard, an ALi Corporation M5451 that uses the "trident" module under 2.4 and the "snd_ali5451" in 2.6. In fact, there is continuing discussion on Ubuntu forums about all of the ALI M5451 soundcards that aren't working - so if any of you know how this magic is being managed, do consider going over there and giving them a hand.

Still faithful Puppy lover,
Andy Figueroa
figueroa@philippians-1-20.us

Post Reply