So prior to upgrading and after the initial install of the OS i ran the script, then i installed all the updates and prior to rebooting the system i ran it again. Then i rebooted and couldn’t back into the system. :).
i’m looking into figuring out how to peform a mkinitrd from the recovery cd tonight. Might try to force it. I’m also going into the additional UUID entries that were created in my blkid output. Not sure if there are conflicts with having two entries in that blkid list with the same UUID… i’m taking a look at that as well.
I was initially targeting the ati/amd video drivers but i don’t think they are the issue. i’m using the open source radeon drivers as far as i can tell.
Ah yes.
I forgot about the ucode-amd/ucode-intel update.
IIRC on stock 13.2 those package are not installed, but the updates do install them.
So try to uninstall them and taboo them in YaST.
Then the workaround with adding dis_ucode_ldr to the boot options should not be necessary.
@johannesrs: To get into your system, try to add this option, by pressing the ‘e’ key at the boot menu, searching for the line starting with “linux” and appending “dis_ucode_ldr” at the end. Then uninstall ucode-amd and ucode-intel and your system should (hopefully) boot again.
Btw, because it has been asked, you should be able to install/update/remove from a LiveCD/Rescue System by specifying the --root option to rpm or zypper. I’m not sure if/how to call mkinitrd though.
Or (better) chroot to the installed system as described in the bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=913996#c13
But if adding “dis_ucode_ldr” works, this is not necessary of course. (and if it doesn’t, you experience a different issue anyway, and uninstalling ucode-* probably won’t help either… )
I actually tested a few scenarios last night. remoing the ucode-amd and ucode-intel worked like a champ on an already froze machine i tried.
but also, i did a fresh install of the os and used the kernel of the day that is specified in that post. Ran all the updates and again go stuck at the loading initial ramdisk. Instead of going in through rescue i just put the dis_ucode_ldr into the kernel command line and it got me right in without installing the two ucode packages .
so for right now i’m in and updated. i’m not quite sure of the ramifications of disalbling the ucode but we’ll find out.
I’m suffering that problem 3 months ago. I reinstalled OS 13.2 at leats 4 or 5 times. The installation was fine, but after some update (I can’t say exactly what installation) the message “Cargando ramdisk inicial” (it was showed in spanish) changed to “Loading initial ramdisk” and, from that point, I was able only to boot from the 3.16.6-2 but not in 3.16.7-21. Later, in some other update, ALWAYS in the next reboot my PC was hanged on “loading initial ramdisk”.
Today, I was in the same trouble, and bored of reinstalling and reconfiguring, I found your solution and … IT WORKS!!! :’(
I was desperate and even thinking in changing to another Linux in my HTPC, but this patch solved my dilemma.
THANK YOU VERY MUCH!!!
I can’t undertstand why that problem is not solved in some update. This kind of bugs make give up people of trying to adopt OpenSUSE as their operating system.
Because it is not a problem on most systems, and the cause has not been found yet.
But, there seems to be a testing kernel available now with a possible fix. Have a look at the bug report, test it, and report your findings in the bug report.
See https://bugzilla.opensuse.org/show_bug.cgi?id=913996#c107 in particular.
This kind of bugs make give up people of trying to adopt OpenSUSE as their operating system.
Well, it is not an openSUSE specific problem either if I understand the comments in the bug report correctly.