Using the defaukt x86_64 kernel openSuSE 11.2 (uograded from 11.1) works fine.
I have compiled my own kernel using the 11.1 config with minor changes. Botting runs fine and looking at the boot.msg compared between the default and my own kernel I only see preloadtrace.ko module missing on my own kernel which I would not expect causing mthe problem.
After the boot I am unable to login on the X login screen, text console or ssh.
The X login hangs after I entered username/password. Th elogin box disaapears and the backgroundscreen remains.
On the text console (after stopping xwindows via CTRL-Backspace) I can enter the username but the password prompt will not appear.
On ssh, where I login via plublic key I will get a message that the key will be used for login and then the session hangs as well.
You are using an older kernel (recompiled) to try and run packages compiled for the newer kernel. I’d not expect that to work. Can’t you make the desired changes to the newer kernel? Or maybe I don’t understand???
No, I used the .config from the older kernel in order to make sure I have the same option selection in the new kernel. I did then a new “make menuconfig” to set new options to their default. Then I recompiled the kernel which is the same as the default one that comes with 11.2 (2.6.31.5).
Rather than use the old 11.1 config file, you should generate a new one (clonefonfig), and then re-apply your changes you made to 11.1 as a patch.
There’s no reason to think you’ll get a bootable config, after a years updates, using the old file. To make such changes easier, I add rcs(1) to default install, and do “mkdir RCS; ci -l <file>” before I modify things. Makes it easy to generate patches with “rcsdiff -u” and merge in changes made, even after 6-8 years or so, when I look at changes to packages used in distro’s like 7.1, 8.2 etc
“make cloneconfig” simply uses the config of the current kernel which is not what I intend to do. I have made many adjustments to the old kernel config which I do want to reuse.
Thanks Malcolm for the link. I am with linux since 1992 starting with a 0.9x kernel distributed on a set of 10 to 20 floppy disks at that time.
For each version of kernel I ever used since I have build my own kernel so I have some experience with building kernels
For each problem I ever encountered in kernel building I found the solution myself. However this time as I am not able to login will on the other side there is no error in the boot log except for the preloader I have no clue what to look, and especially I need a hard retart each time I do a test which I would like to avoid if possible.
First of all, my kernel is bootable ! Everything starts up without any problem, only login is a problem which points towards pam*.
Second, there are many reasons I could believe my way works, since I do it since long.
Basically the method you mention and mine are not really different. I use the old file, run the config opver it which fills it up with the default values of the new kernel, which is exactely the same like doing makeconfig from scratch and modifying the same settings as before. Settings no longer existing in the new kernel are simply ignored anyway.
Personally I have never ever used cloneconfig as I have reviewed each option separately myself starting from the default config.
I agree however that in this particaular case it might be worth giving a try merging the config from the default kernel with my old one. If this works it would not show that my way of doing is wrong, but it will point me to the bad setting.
I will write a script to do the merge and keep you posted.
> For each problem I ever encountered in kernel building I found the
> solution myself. However this time as I am not able to login will on the
> other side there is no error in the boot log except for the preloader I
> have no clue what to look, and especially I need a hard retart each time
> I do a test which I would like to avoid if possible.
The preloader should not be a problem. I’m running 2.6.32 and
2.6.32-git kernels that I build myself. The latter has part of the
changes that will be in 2.6.33. I get the preloader errors when I
boot, but they cause no problem.
As a workaround, create a new account without a password and disable
auto-login (if you use it). You will have to enter a password when you
create the account, but then edit /etc/passwd and remove the “x”
between the first and second colons. I suspect you already know that,
but I put it in for the benefit of other less-experienced users.
Can you log into the new account? If so, what happens when you “su -
root”? Did any interesting messages come out on the screen or in the logs?
I understand that, but you have run an installer and used an 11.2 kernel, which has options chosen by kernel team.
Then you can do your customisation, from a working configuration. Also benefit from SuSE alterations since your previous work, which are likely to be in sympathy with changes to the system, Example, kernel pre-emption used to be disabled, because there were performance problems with ReiserFS under it.
Great that it worked, but in general you have been lucky, one day you won’t be.
Cloning the working configuration, and then you can change settings, is the only supportable option.
If you’ve a patch of changes you made against the old kernel file, then you can re-apply those value changes and see where items have altered.
Doing clone-config and applying a few customisations with a sed script is fairly simple, there’s no advantage to messier solutions which ignore possibilities inherent in kernel code developments.
PS. Update now out fixes the “Uhhh… too many forks” message that was coming out of the script /sbin/prepare-preload
While the merge did produce a working kernel it did not producte the expected result.
The rerason is that in my kernel config I have deslected a lot of options only leaving what I do require. This results in variables being unset which then will be overwritten (set) by the current config (/proc/config.gz).
I have set the KDE login to autologin without password and this at least works for my kernel as well (SSH login still hangs), so now I do have a way to do proper reboots and can diagnose th eproblem more securely.
I was writing to early in my previous post. Unfortunately proper shutdown is still not possible because KDE complains that it cannot contact the session manager for logout. Pressing CTRL_ALT_Backspace does leave KDE but still hangs the console (no shutdown is done).
Is started this time from my merged config deconfiguring all I do not need. This first time I built the kernel I did desekect th ewrong network driver and did get no network, but console login worked fine.
Then I have reconfigured the network drivers and got a workign networlk but tghis time the same problem as before.
However I did also configure an USB serial console where I got messages about mingetty bein stuck:
Ok, I did now my lastattempt to do it the usual way with no success.
What I did is build my own mingetty generating assembler listing and map files to be able to analyze it from a crash dump. Then I build the same kernel setting up panic() for soft stuck and hung tasks. But unfortunately the kernel did not crash eventhough it reported stuck CPU again.
I do now go the safe way for this kernel by merging the default settings with my settings and update (correct) changed settings by running menuconfig once on the merged config.
A kernel built that way did work before, so I hope it still does
A few additional notes:
The kernel which usually hung the logins in mingetty did sucessfully boot once, without any changes, but failed again on the next reboot. Probably due to timing.
For some diagnostic reasons I did boot the kernel once only up to runlevel 3 with success. Logins did work on the console and remote via ssh. As I was not expecting this (unless it would be like the single success above), I did then manually “init 5” starting KDE with autologin enabled. After I attempted to start a terminal window the problem appeared again. This would indicate that the problem may be linked to X Windows. However I did not do any further tests as data safty goes first.
