EDIT:
More problems with 3.0.0.6 liquorix arised.
Question is now:
Is there any older liquorix 3.x.x.x ? If yes, where to get it ?
Until now, liquorix served me very well (thanx !), will be unhappy without it :-(

Old question:


< Edited by Henkye :: Nov 3, 11, 6:58 >
Back to top

That's really strange, the only thing I've made changes to was BFS.

As far as how the versions are related, 3.0.0-6.dmz.1 is the package name I set for the kernel. 3.0.0-9 is the package version - this is what the meta package pivots off of to depend on new different packages, like 3.0.0-8.dmz.1 that might be coming out soon.
Back to top

Forget to add:

Back to top

The only changes i have in the system except those in synaptic:

/etc/init/tty1.conf:


Brigde for my KVMs:
/home/henk/.aqemu/bridge:


Forcing soundcards order,added to end of:
/etc/modprobe.d/alsa-base.conf:


/home/henk/.bash_profile:


/etc/sudoers:


/etc/fstab:


Also allowed mounting in policy kit, and some autostarts in openbox.

Who knows, maybe i've made here some terrible things which worked so far, but now causing trouble ...
Back to top

Since you have so many changes on your system, some of which could easily have created an issue, the best course for you is to undo the changes one by one with the current kernel, 3.0-8 until the failure to shut down behavior vanishes. In order to discover the true culprit, undo one change, reboot, then try to shutdown again. Repeat until cause is discovered. Don't undo multiple changes because then you wont' know which is the cause. It could also be two of them together.

That would be an easy test to make, since f it shuts down, you know you've found the culprit. Then you can return the other components.

I've uploaded a temp liquorix kernel here for you 3.0.0-6 : smxi.org/sm/kernels/32/3.0.0-6.dmz.1-liquorix-686.zip

that's the zip file of the headers/lmage,. use dpkg to install them directly.

but in general it's best to know the causes if they are due to changes you have made in your system.

Also, in general, please try to break the habit of removing the previous kernel, which is by definition almost always known good and working fine, always leave it, ie, ALWAYS have one alternate kernel installed, it only uses up a 100 mB on your disk, and removing it achieves nothing except for removing the possibility of solving some as of yet unknown future issue. I usually leave 3 or 4, just because it costs me nothing, and if I discover some issue that requires some unknown past kernel to solve, there's no point in removing them for me. New kernels should always be considered as having these potentials, at least:

1. Something that was working breaks
2. Something that was broken works
3. Something that was working breaks, and something else broken works
4. No difference at all
5. An incredibly subtle issue breaks other code, not kernel, that was working, but was working due to an unfixed or unknown bug in some other unknown area, which was fixed for unrelated reasons in the kernel. This would be your case.

This list is not of course inclusive, but should be considered as all that's needed to understand why one does not install only the current latest kernel and trust that was is in essence always a beta type release (all current linux kernel releases, due to the hyperactive speed of kernel releases, must be considered as beta releases until proven otherwise.)
Back to top

hi

if testing causes too many time issues for you....you could use smxi to change your default kernel to Debian

It has a slower release cycle so you will lose all the bleeding edge stuff Damentz puts into his kernels.

2) I am a fan of application = PARTIMAGE something that a certain entity at aptosid/sidux detested with some venom....so even more reason for me to use it....he heh.

It has got me out of trouble where you may be the first person to experience a glitch as you are on sid?

Looking at what is removed is not always inclusive....some changes are not detected until reboot after doing a smxi upgrade.


good luck
Back to top

After reboot marathon (really annoying), only thing i found:
shutdown and reboot works flawlessly only in command line (X not running). Every command or script ran from or during Openbox (X) failed. For example (ran as root):

Also disabled some of my "tweaks", as techAdmin adviced. Some are just 2 important for me, to live without them - dont tried them.

At time of creating this topic, 3.0.0-6 was my current kernel. 3.0.0-8 same issue. Thx anyway.

Completely agree with techAdmin about backing up previous kernels, this time i had only ubuntu kernel as backup. My fault. Next time ill have backups of both branches.

Last thing ill try is to reinstall nvidia driver, since it was complaining about compiler version. Because, as mentioned before, have another issue: random 1-60seconds freezes.

Again, thanx for everything. I dont blame new liquorix since my system is so customized and even went through dist upgrade process ... But for now, going back to ubuntu's official kernel.
Back to top

What about the 'halt' command?

Just that: halt
no args. This should call shutdown, but give it a try.

This could be an openbox issue, totally unrelated to kernels, and the only reason the liquorix kernel has issues is that it's correctly configured.

I've seen suspend issues with various kernels but never shutdown/reboot issues.

By the way, also try this command: reboot

and see if that works from inside openbox.

Also, it would be useful to see if kde shuts down correctly, or gnome, but you probably don't want to install those so leave that alone.

You're doing a very good job with testing and diagnosis.
Back to top

Wouldn't been so ashamed, if internet wasn't full off: DO NOT COMPILE KERNEL MODULES WITH DIFFERENT GCC VERSION.
4.5 was installed, but wasn't set as default. Changed gcc link in /usr/bin from v4.6 to 4.5 That's it.

Glad i can fly again, instead of walking ! :-)
Back to top

henk, sgfxi has always checked for,, installed if missing, the proper gcc version, and set the gcc global to use the right one. For this very reason.

It's somewhat astounding to me that in 2011 some of these procedures are still so primitive, but thats why I did the sgfxi thing in the first place.
Back to top