Livemedia trouble w realtime kernel

Hi, I got some terrible trouble when using kernel-rt …
If I add the kernel-rt to my appliance my appliance builds fine, however I cannot boot into the live media.

When I try to boot the image created from the build I get error:
Reboot Exception: failed to mount root filesystem.
Reboot Exception: failed to mount clic filesystem.

The thing is that as soon as I add kerlen-pae or kernel-default the problems goes away and I’m able to boot the image. . kernel-rt package is the one from opensuse updates repo…

Seems there are some configuration files for rt kernel missing in the build server ?
There must be something wrong with some scripts not compiling my build for the correct mount setup for realtime kernel ?

Here is a screenshot:
http://lh6.ggpht.com/_AGwJBqgP7p8/TNyE78b6IYI/AAAAAAAAArw/Zkn88PFOwhQ/problems.png

Screenshot of ALT+F3 output
http://lh5.ggpht.com/_AGwJBqgP7p8/TNyGPSU_DZI/AAAAAAAAAsY/-uabOHfPK9E/s576/problems2.png

So I am no expert of the Kernel-RT, but that is experimental as I understand it and while it promises low latency, I would surely use the kernel-desktop I would think and see what that does first and if it works, perhaps you don’t really need rt. Anyway, it is just a thought.

Thank You,

I need a low latency kernel for music production, the default kernel is not sufficient

I encountered similar problems when i tried to build an appliance with susestudio in times of openSUSE 11.2:
Build failed during RPM installation with kernel-rt

I wasn’t able to build the appliance. Even jengelh himself had issues with that.
I’ve done a standard openSUSE install and then changed the kernel to jengelh’s kernel-rt.
This seems to be the only possible way so far…

If i got a little time i will try building an appliance with susestudio again and post
the susestudio link here, so you can use it as template for building yours.

There is definitively something not right in how the build service builds with a rt kernel.

After discovering that the appliance always enables some of the default kernels when selecting the kernel-rt from the OSS repo no mather what I did I banned all other kernels, fine… Now off to build: success, ok so now let’s try to boot it on testdrive and live cd media: failed, no error this time, only a black screen after “grub/boot selection”

Anyway, the adding of kernels might have something to do with a dependency for ndiswrapper and for iscsitarget, however that has little to do with anything…

The main issue is that now that no other kernel than the kernel-rt from the updates repo is selected my screen goes all black.
I’ve tried this in two appliances with different configurations so I am pretty sure the problem is not human :slight_smile:

If anyone with rights on susestudio would like to take a look it is here: Sign in – SUSE Studio

summary:

  • build appliance with ether a default kernel or pae kernel: result = everything OK
  • build appliance with kernel-rt from openSUSE 11.3 OSS: result = ether failing with the errors given in original post, or fails with a black screen after “grub/boot selection”
  • build appliance with kernel-rt from j.eng repo: result = dependency problems with RPM, j.eng’s packages are compiled with an older version of RPM or something like that

Conclusion:
Due to the fact that the only thing that have changed is the kernel I strongly believe there is some misconfiguration in susestudio

On Fri, 12 Nov 2010 11:06:02 +0000, tertitten wrote:

> Due to the fact that the only thing that have changed is the kernel I
> strongly believe there is some misconfiguration in susestudio

You might want to use the ‘feedback’ link within Studio to ensure you’re
getting the attention of the developers with this. They also will be
able to look at your appliance and see if there’s anything there that
might be done differently to make this work right.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

I filed a feedback at the 11’th, I haven’t gotten any response to it (don’t know if I should get one or not)

Just for fun I tried with kernel-trace as well and ended up wiht the same problems…