Well, damentz has been slaving over a hot kernel stove, and has just launched his 32 bit full zen kernel deb packages, and his new repo, liquorix.net.

These kernels are fast, and fglrx WILL work on them, unlike the sidux kernels.

While these are of course somewhat experimental, if you want the latest zen kernels, and you want to use smxi, it's all ready to go, for 32 bit users anyway.

While in theory these will probably also install on Testing, for now I'm putting this in the antix sid forum because sid is more experimental anyway.

So, to get the latest zen sourced kernel with full modules and smxi support, simply do this:

In a code editor, as root, open: /etc/apt/sources.list
Add these lines:
Save sources.list, then start up smxi, and go to the advanced kernel install section. You will see a new item, install-liquorix-kernel, select it, and it will install your new zen liquorix kernel from apt, and then install any currently supported modules, just like smxi normally does for debian kernels for example.

damentz of course would appreciate feedback, and so would I.

If these kernels work out, I will probably replace the kernel sidux zips with the zen liquorix zips, because they do most users more good, since they are fglrx supporting.

Please post feedback here, and I'll point damentz to this thread as well. Thanks

Enjoy!

64 bit will come along a bit later, damentz has to do some more work to make those. Keyrings will also come later, for now these are just unauthenticated installs.

h2 and damentz - thanks.

Just managed to successfully install the zen kernel via smxi.
A piece of cake it was.

It is working ok, nvidia installed just fine.

For those that don't know, what would be the advantage of using a zen kernel rather than the default MEPIS or sidux one?

Edit: Found a problem. It doesn't detect my logitech usb gamepad. MEPIS and sidux kernels do.

I'm all over it. Will let you know. Will I have to re-install the ati driver/catalyst control center?

Hello:
I tried upgrading to the zen kernel on my old Dell Inspiron 7500. First the good news: the smxi script worked like a charm and everything installed without a problem.

The bad news is that, just like in the case of the sidux kernels, during boot the system hangs for a long time at:

Uniform CD-ROM drier Revision : 8.20
sd 0:0:0:0: Attached scsi generic sg0 type 0
sr 1:0:0:0: Attached scsi generic so1 type 5

After several minutes, it proceeds to the next 4 lines:

Busybox v.1.10.2 (Debian 1:1.10.2-2) built-in shell (ash)
Enter 'help' for a list of built in commands

/bin/sh: can't access tty; job control turned off
(initramfs)


and I just get a blinking cursor at the end of the line. This has been a very consistent problem with sidux kernels and now a zen kernel. However, Debian and Mepis kernels are fine.

Any ideas on how to solve this would be great

thanks.

Pedro

Bugs in smxi fixed: now should correctly download all modules during post kernel install process, that was not working.

zen kernels have a lot of new features and advanced options.

Since this is basically the first public announcement of the kernel, we'll see how things go, the main thing was to get another option for fglrx users than the default debian vanilla kernel.

I've tested it, and it runs the system more efficiently, but I also had a few glitches, like everything, there's a learning curve involved until damentz gets this stuff working solidly, but early tests are promising.

If sidux and the liquorix both fail to boot, I'd look at your grub data, and at /boot/grub/device.map, and make sure it's pointing to /dev/sdx, not /dev/hda, which is not supported by libata kernels. Also of course, check /boot/grub/menu.lst to make sure it's not using /dev/hdxx for the root path, but instead UUID=<partition uuid> or LABEL=<partition label>

Also, I'd check your /etc/fstab to make sure it's not trying to load /dev/hda for root, although the way mepis handles fstab is a problem if you want to tweak things, it's too dynamic, well, it's dynamic. This is another thing that Warren really needs to take a look at and fix, udev does that for you now, and mepis sort of fights with udev itself for control, which was ok in the past, but it's not so great now.

Issues I'll probably figure out: why suspend to disk fails when it works on sidux kernels, but these zen ones use a different hybernation method so I might just be missing a package or something.

Keep in mind, changing this means that debian kernels would then not boot, if that's the problem, but it's easy to change it back using a livecd to edit that file. Not the most elegant solution, but it works.

Ok, I had a little trouble at first. smxi could not d/l sm...... something and would not offer the Liquorix kernel. After the third attempt it was finally offered, downloaded and installed. I then reinstalled the fglx ati driver and rebooted. The kernel booted without issue and x started, so far everything is working well.

Thanks again h2. Should I be looking for anything in particular or watching any logs for reporting back? Let me know.

Nice job!

Sounds like a temporary glitch with the server, that's not related.

eriefisher, I'd say things to look out for are: things that might catch new users but which you have already resolved on your system, such as device.map syntax, menu.lst syntax, fstab issues, then of course if there are any hardware issues. Then you can help filter those predictable issues from problem reports and let damentz deal with the actual kernel related issues, which are a difference class of problems.

Nice round of applause to damentz for stepping up and starting the very hard work of learning how to do all this at a very rapid rate, from building his own repo, learning how to run the kernel / deb constructor scripts, learning about what gpl issues need to be handled, as well as just having fun making the things.

We'll see how he does, once these are a bit more tested, I'll be adding them as alternate zip archive file methods, but there's some stuff to learn first.

I already saw some positive things, seems to be running the hardware more efficiently, cooler, on a laptop test, that's the first thing I noticed.

hey anticapitalista, i'll see if I can figure out why that gamepad doesn't work. It may be usb autosuspend, I'll take a look.

By the way, for irc users, you can look up damentz on irc.oftc.net channel #smxi

If his nick is present and not marked as away you can discuss issues with him in real time, but overall I think it's good to have forum postings so other people can read them and get the information they need.

It's also easier referencing a forum thread than an irc chat in my experience, for future debugging and development purposes.

Nice to 'see' you here damentz and great work on the kernel.

There was also a problem mounting usb devices. They were not recognised with your zen kernel, but are with the MEPIS and sidux kernels.

I'll check again, maybe I was missing a module.

My usb stick(512mb) mounted just fine anti. I actually have found no issues with the kernel yet.

Well, I've made some progress in the zen kernel battle. I changed /boot/grub/menu.lst to using UUID and I'm getting further in the boot.

However, now it's hanging at device-mapper

Here's my fstab file. H2 mentioned something about /dev/hda1 but I'm not sure if I should change this or not, or what to change it to, UUID?? or take it out altogether?

# Pluggable devices are handled by uDev, they are not in fstab
/dev/hda1 / ext3 defaults,noatime 1 1
/dev/hda2 swap swap sw,pri=1 0 0
proc /proc proc defaults 0 0
usbfs /proc/bus/usb usbfs devmode=0666 0 0
devpts /dev/pts devpts mode=0622 0 0
sysfs /sys sysfs defaults 0 0
/dev/hda3 /home ext3 defaults,noatime 1 2
# Dynamic entries below
/dev/cdrom /media/cdrom udf,iso9660 noauto,users,exec,ro 0 0
/dev/hdc /media/cdrom udf,iso9660 noauto,users,exec,ro 0 0


Mepis kernel still work fine.

thanks for any help.

Pedro

Here's another update. Following the"no guts, no glory" rule, I went ahead and changed /dev/hdx references in fstab to /dev/sdx and then I was able to get the zen kernel to boot up.

So far it seems to be working fine, so I'm happy about this and particularly that I was able to overcome this problem.

Thanks to h2 for his explanations.

Pedro

To continue with the saga, zen kernel works fine, MEPIS kernel though is hosed (something about the swap file being corrupt) and even after I get a log-in screen, I can't log in, it says log-in failed.

I suppose I could go back to fstab and rename everything back to hdx, but is this the solution? Does it come down to either the zen kernel or MEPIS? and by the way, sidux still does not work. This is just my old laptop and so it's not a big deal, but hopefully, I will run into fewer problems if I want to try different kernels on my new laptop (or a destop).

thanks.
Pedro

The issue here isn't so much sidux/zen kernels vs mepis kernels, it's libata enabled kernels vs legacy kernels.

Basically, you need to use one method per operating system, with IDE drives. With Sata drives, the drives are seen as /dev/sdx, but with ide, they are seen as /dev/hdax in non libata kernels, and as /dev/sdx in libata kernels.

But you can't use /dev/sdx in any case, you need to use either UUID or LABEL for all mounts of root, home, swap.

That avoids one kernel not seeing it and another one seeing it.

But device.map will be an issue as well. Basically, the linux world needs to switch over to using libata, but some distros aren't doing that yet, but they have to do it, for reasons such as you are seeing. There's more stuff internally sometimes too, with swap, that needs to be uuid/lable mounted, in a specific syntax, as well.

So you can't really switch back and forth easily until you have converted all your mounts in fstab to use uuid or label, same in menu.lst, and any other files that have that data on them, /dev/hdx that is.

One of the better, and technically very hard things, that sidux did almost 2 years ago if I remember right, was carry out this conversion permanently, because it's the future, using /dev/hdx really shouldn't be happening anymore, but I think even Debian kernels will show that for ide drives still, and for cdroms in some cases.