I have an issue with booting my openSUSE-13.1 installation on a MacBookPro:
I upgraded to the kernel from 3.11 to 3.12 via the normal update repository. The setup went without issues, but I am unable to boot into that new kernel.
Fortunately I still have kernel 3.11 installed in parallel, booting that works flawlessly. I compared the grub sections for the two kernels, I cannot spot any difference (besides the kernel version, obviously).
This is what happens out of line when booting into 3.12:
Right at the begin I get a “failed to set xfermode”, then the process complains that it waits for /dev/root but cannot find it and finally asks if it should fallback to some volume which I can neither confirm nor deny, due to the lack of a working keyboard at that time in the boot process (the system uses an internal USB keyboard).
I assume the issue is that the primary hard drive is not available because setting the “xfermode” fails.
(yes, the system has two hard drives, I moved the normal spinning drive to the bay of the optical drive and installed an SSD as primary hard drive. Have been using that setup for years now, quite happy with it)
So my question probably is:
what might be the cause of the issue?
how can I fix it, since I do not see any kernel option that looks promising
what is the difference between the two kernels in that aspect (3.11 and 3.12)
what steps can I take to examine the issue closer and provide additional information here
The system has a NVidia GeForce 9600M GT for which I use the proprietary nvidia driver.
Frankly I fail to see why that should be relevant, but maybe I miss something here…
The system fails to boot. It never comes as far as loading any kernel module let alone try to start a graphical interface. The issue is to access the root volume when using kernel 3.12 which works with exactly the same parameters when using kernel version 3.11.
The boot process hangs after the boot menu right when the boot sequence is initiated, before the root partition can be accessed.
Is the video driver really relevant here? Why?
As written I have no problems whatsoever when using kernel 3.11, including using that video driver for a graphical environment.
As I see it the driver is not touched in any way, since the system never boots. How should the video driver be relevant here?
My impression is that kernel 3.12 (or the initrd created for it) uses different parameters to access the primary drive which fails.
how can I find out what the difference here is and
This is a one time problem that effects those using NVIDIA driver and moving to the new kernel. There are numerous threads. As said it is fixed by removing and re installing the NVIDIA driver as per my instructions.
Of course you may be seeing something different. Can you boot to recovery mode with the new kernel ie in the advanced area of the grub menu
Thanks for helping me with this!
I did as you suggested but, as I expected, that did not solve or alter my issue in any way. Certainly it might be that I made a mistake somewhere on the way…
As written before I cannot boot at all using kernel 3.12, regardless of the run level. So I booted into kernel 3.11 (which works just fine, as written before) and removed and reinstalled the nvidia packages. Afterwards my graphics was completely broken and failed to load, complaining about an unresolved symbol in libglamouregl.so.
At that point I remembered that I had such difficulties before, since, as indeed I have not pointed out before (since I just remembered it myself) that the laptop has an “Optimus” setup for the graphics: that combination of an Intel and a NVidia chip. Because of this I never managed to succeed installing the nvidia driver via the normal package management. What always works is to download the driver manually from NVidia and install it via the provided installer (I hate to do such, but as said: the only option I found to get things working on this system).
That done I had my graphics setup working again for kernel 3.11.
The boot issue for kernel 3.12 obviously is unresolved and unchanged.
I’d like to ask a question here. I have very little experience with hardware setup, so please excuse if I insist on this step:
Why should the graphics driver be the cause of the issue at hand? As written (so as far as I can see) the issue is that the boot sequence, when initiated from the grub loader, fails to access the root file system (/dev/root). That is why the boot process fails immediately before even attempting to load a kernel or anything. I would expect that this is long before any potential graphics driver comes into play…
But granted, I may be completely wrong there, sure.
So and other ideas? Or any hint where I went wrong with the above attempt?
OK there are lots of thread on thins but let me try
When installing a new kernel the NVIDIA driver must be recompiled for it this is done by the KMS packages. But because 113.1 (Evergreen) is switched to the distro as a kernel supplier so they do not have to maintain the kernel. But there was a glitch in the NVIDIA packages and the drivers did not recompile correctly so you needed to uninstall the drivers and reinstall which fixed the problem.
Your problem appears to be something else. Do you have any error messages to help diagnose? It is hard to see over your shoulder.
Sure, I know about the kernel module getting built. But as written: I would expect that this is not relevant that early in the boot process. Which is why I stated twice that the system cannot access the root file system and consequently fails to boot at all.
I can only repeat the error message I posted above: “ata1:00: failed to set xfermode (err_mask=0x4)” (repeated from memory now)
it occurs right after starting the boot sequence by selecting a kernel 3.12 entry in the grub2 boot menu, regardless of normal or failsafe entry:
it states to load the initial ram disk, then the screen blanks
an error message about a missing driver for some i2c device (can be ignored, works fine later)
then above error message, repeated every 5 seconds
aber about 10 iterations (I had to try again for the exact count) it states that it is waiting for /dev/root to appear for some 20 seconds
then it states that is failed to resume from part3 of the disk (as specified in the kernel args)
finally asks if it should fallback to the drive which I can neither accept nor decline due to the lack of a working keyboard (the system uses an internal USB keyboard)
That’s it, all I can do is a hard switch off per power button. none of the normal boot sequence is even started.
Note that this issue does not occur when booting into kernel 3.11 (which I am using now). Which is why I initially believed that there must be some difference in the kernel args in the bootloader menu, but I fail to spot any.
So maybe my real question is: why do identical kernel args in the bootloader menu lead to a different way the disk is accessed?