5

I'm using an Ubuntu Server (13.04) Minimal installation (with the Xubuntu Metapackage as a desktop environment, if that matters) on x86_64 on my Samsung notebook. I'm currently forced to use the no-longer-maintained version of the proprietary AMD graphics driver (fglrx-legacy) as the open-source "radeon" driver heats the card 15°C more in idle.

That's why I'd really like to try kernel 3.11 with the new power management features for AMD cards. The problem is, once I install a mainline kernel the system freezes after selecting the kernel in Grub with the messages:

Loading Linux 3.11.0-laptop ...
Loading initial ramdisk ...

And nothing happens. How can I find out what's wrong? Are there any logs from that early in the boot process stored somewhere?

Some more information: The system works perfectly with the Ubuntu Raring Kernel self-compiled from Git (which is based on 3.8). It doesn't work with mainline Kernel 3.9 or 3.10 (same problem). I also tried a pre-compiled "generic" version of 3.10, doesn't work either. I have 4 partitions on the hard drive: /boot (unencrypted), /, /home and swap (all LUKS/dm-crypt encrypted). The notebook is a Samsung NP-R522H. The GPU is a Mobility Radeon HD 4650.

Improve this question
3
  • What specific model number do you have for the Samsung laptop? Include the AMD card info too. Please add this info to your question towards the bottom.
    – slm ♦
    Sep 7, 2013 at 21:50
  • @slm Ok, did that.
    – qasfux
    Sep 8, 2013 at 19:01
  • The 'initial ramdisk' is just a Linux disk image. Ungzip it, uncpio it, and look around. It's almost definitely composed entirely of shell scripts. cat them and find out what they do.
    – mikeserv
    May 11, 2014 at 1:25

2 Answers 2

Reset to default
3

Potential Problem?

You problem sounds like it's related to this particular issue with Samsung laptops + UEFI + Linux.

Further Research

I searched on your particular model # and did not find anything that jumped out as a potential source of your issue. So I do not think it's a widely know issue at least at this point, so your next course of action is to debug the issue.

Debugging a Kernel

Here are the order of things to try.

  1. verbose

    During the boot phase, add the following kernel parameter to the list.

    linux ..... verbose

  2. debug

    If the verbose argument doesn't shed any light the next level to check is debug.

    linux ..... debug

  3. others

    There are several levels beyond that, but let's not get ahead of ourselves. Let's try the above first and see if they show where the Kernel is hanging.

References

Improve this answer
1
  • @phoenixyz - see updates for things to try.
    – slm ♦
    Sep 9, 2013 at 1:15
0

Sorry, I totally forgot this question.

The solution back then was to use the Saucy (Ubuntu 13.10) Kernel, which is based on 3.11, instead of the vanilla/mainline one. Some changes probably broke compatibility, at least with my combination of hardware and software.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.