Kernel Panic in under two seconds

[Silent Observer]

I've recently installed Kubuntu 14.04 64-bit, intended as a successor to Mepis 11 64-bit. I started a thread asking about Kubuntu Live showing my hard disks with different drive designators (sda and sdb are swapped from the way Mepis 32-bit and 64-bit, and antiX 13.2 64-bit, and every other live distro I've used in the last couple years, see them), but I've resolved questions on that by using root=LABEL=<partition label> to designate the root location. I'm still encountering a much more serious problem: Kubuntu won't boot successfully. Given that my other thread seems to have fallen by the wayside, I've started a fresh one specific to the boot failure.

The live session works fine, and the install from the Live USB went smoothly (I permitted downloads of non-free software such as Flash, and updates, during install). Last night, I reinstalled Kubuntu from a USB created with unetbootin 603-1 on an antiX 13.2 32-bit system (installer started from inside the Live session after mounting all system partitions other than the ones to be written during the install -- a work-around I found for the "Prepare" step hanging on a system with many partitions), into a freshly reformatted 20 GB ext4 partition, with home going to a shared ext3 partition but a unique user name (so no conflict of the user folder with any other installed distro), and reused the same 4 GB swap partition I've previously used with Mepis 32-bit and 64-bit, and antiX 64-bit (this has worked fine when installing Mepis 11 64-bit with 32-bit already in place, and when installing antiX 13.2 64-bit with 64-bit Mepis already installed).

Whenever I attempt to boot the installed Kubuntu, however, whether I launch directly from Grub Legacy (already in place on the MBR of my Linux drive and controlling boot of Mepis, formerly antiX, and Windows XP as well as Kubuntu if/when I get it working) or chainload Grub 2 (installed in the root of the Kubuntu partition, so as not to replace the Grub I know how to fix), no matter what cheat codes I've tried, I get a kernel panic in anything from 1.2 to 2 seconds, with the message "init not found" and "try passing init= to the kernel." Googling that message has led to a number of things people have done that solved the problem -- some of which aren't applicable to my system (disable "secure boot" in BIOS, which isn't even an option on my five-plus year old motherboard), others which don't seem to have any effect (chroot to the Kubuntu partition and run update-initramfs). I've attempted cheat codes that were useful getting other Debian based distros to start: nomce and nomodeset (separately), with the only change being how long the kernel panic took to appear and how much boot text scrolled past too rapidly to read before the panic.

I don't know if it's normal given that there hasn't been a completed start, that the user folder (/home/<username>/) contains only three hidden files: .bash_logout, .bashrc, and .profile (I'd have expected to see pre-created Desktop, Documents, etc. folders, at least, but I haven't looked at an install with a file manager prior to starting it before). I also don't know if this could be related to the install seeming to jump from 87% complete after setting up and initializing a bunch of packages, to "ready to reboot" (other installers have, at times, seemed so busy doing invisible things in the background that they didn't update the progress information late in the install -- and worked fine afterward).

Here's my system information:

System info:

Kubuntu 14.04 64-bit, installed but not booting (as multi-boot alongside WinXP and Mepis 11 64-bit)
KDE 4.13.0
Legacy GRUB 0.97-64, optionally chainloading to Grub 2 as set up by the installer.
System has WinXP SP3 32-bit, Mepis 11 64-bit, and Kubuntu is installed in a freshly reformatted 20 GiB partition, reusing 4 GiB swap and with a new home folder (unique username) in a partition shared with Mepis and previous antiX install.

Desktop system
MSI P6NGML motherboard, onboard video disabled, onboard sound active, onboard ethernet active
Intel Core2Quad 2.67 GHz (Q9440, I think) -- 64-bit, 4-core, w/ 3 MiB Level 2 cache, running at default clock
nVidia GT520, 1 GiB RAM, PCIExpress x16, default data rate, GPU, and RAM clocks
4 GiB RAM installed, default RAM clocks
2 HDDs -- one SATA 1 TB, less than a year old, 6 NTFS partitions (my old Windows drive) on motherboard connector; one IDE 120 GB, 7-8 years old (4 partitions: swap, Kubuntu64, shared /home with separate user folders, and Mepis11) on motherboard connector; both drives read healthy with S.M.A.R.T. monitor at last check. Kubuntu64 partition is 20 GB, freshly formatted, shared /home partition has 24 GB free space; /swap is 4 GB.
1 Sony CD-RW 40x sharing IDE channel with IDE hard disk.

[claydoh]

grub legacy, yay lemme crank the gears in my brain for a second on that,
basic things first:
Is kubuntu's grub installed to kubuntu's partition?
Have you updated your "master" grub, to detect and set up the OSs? (sudo update-grub?)
It has been ages since I ever had to hand edit anything in grub to boot any OS outside of Haiku, even going back to the grub-legacy days.

If you hand edited the chainloader entry, perhaps post what you used

Actually, reading further down, it is definitely wrong not having the home dir populated. I am almost positive those are created during the install, and not during initial login.

[Silent Observer]

I think I've tried update-grub since installing Kubuntu the first time, but every time I do that (going back to when I installed Mepis), it puts hd1 where hd0 should go for Mepis (and antiX, when I had it on), and vice versa -- I have to go back through and correct all the "root" lines. This seems to stem from setting my BIOS to boot from the IDE hard disk in precedence over the SATA drive (which has Windows on it); the (several years newer) SATA device "wakes up" faster and gets assigned sda during the earliest part of startup, before Grub loads stage 1.5 (the part we see), but the BIOS setting means the IDE reports as hd0 at the BIOS level. I think...

Here's the current Kubuntu stanza from menu.lst:

title Kubuntu 14.04 LTS at sda1, kernel 3.13.0-24-generic
root (hd0,0)
kernel /boot/vmlinuz-3.13.0-24-generic root=LABEL=Kubuntu64 
initrd /boot/initrd.img-3.13.0-24-generic
boot

I've also used a couple formats of chain loading; the one I have immediately at hand is this:

title Kubuntu 14.04 LTS at sda1
rootnoverify (hd0,0)
chainloader +1

Modified from the one update-grub makes for Windows; this one successfully loads Grub 2, which then gives a similar kernel panic at a slightly different time stamp. I was also given one that invokes core.img in the Kubuntu install, but I'd have to go look that one up on the Mepis forum; it's quite different syntax but gives exactly the same result as the this one. Over on the other thread, leftoverture (must be a Shickele fan) said he'd had a similar problem with 64-bit Kubuntu 14.04 and solved it by installing 32-bit (on a 3-core AMD processor and AMD/Radeon graphics, vs. my Intel Core2Quad and nVidia graphics) -- but what's the point of running 64-bit hardware if you can't run a 64-bit OS?

I've seen kernel panics similar to this (though a little further into boot) when I installed a kernel on my Pentium II laptop that didn't have support for processors that old (antiX version 3.13.x, for instance). I've run 64-bit 3.13 and 3.14 kernels on this Core2Quad machine before, however (I had 3.14.4-antix-1-something in the antiX install that was wiped to make room for Kubuntu), and it's hard to picture a kernel compile having dropped support for a processor that's been out of production for less than five years.

I just looked, and what I have in my Kubuntu user folder is a faithful copy of the contents of /etc/skel -- which I'd normally expect to contain the "skeleton" of the user folder (I learned to back up my KDE settings there in Mepis, to allow easy restoration after two instance of a corrupted desktop), but has just those same three files. I'm pretty sure there's supposed to be more in /etc/skel (at a minimum, the basic KDE setttings in the .kde folder). I wonder if there isn't a problem with the installer as created by unetbootin or as found in the downloaded iso file. Is there another Live USB creator I could download? Without a DVD drive, I can't burn Kubuntu on an optical medium.

Edit: woops, sorry, missed a question:

chainload Grub 2 (installed in the root of the Kubuntu partition, so as not to replace the Grub I know how to fix)

Yes, Grub 2 is installed in the Kubuntu partition, and appears to run correctly if invoked via chainloader.

[Leftoverture]

Why are you so persistent of installing the 64-bit Kubuntu, if I may ask? Like I told you in your other thread, I encountered the same problem for the first time in the live of my 3 year old pc. Kubuntu is the first distro ever of which I am only able to install the 32-bit version, don't know why.. FWIW: I have 4 GB of RAM and 3910.5MB is used, I suppose the remaining 100MB is used by my GPU.

[Silent Observer]

Why are you so persistent of installing the 64-bit Kubuntu, if I may ask? Like I told you in your other thread, I encountered the same problem for the first time in the live of my 3 year old pc. Kubuntu is the first distro ever of which I am only able to install the 32-bit version, don't know why.. FWIW: I have 4 GB of RAM and 3910.5MB is used, I suppose the remaining 100MB is used by my GPU.

It should be enough to say, it's my computer and I want it to work my way. Supporting that, I'd note that your 3910.5 MB is barely more than 3.5 MiB (which would be 3,758,096,384 or 3758.1 in MB); now that I have Kubuntu 64-bit booting, it reports 4,144,836,608 bytes (3.86 GiB) installed RAM, which would be 4144.8 MB using the old 1,000,000,000 byte GB measurement. MiB (mebibyte) is a binary-specific measure; 1 MiB is 1024x1024x1024; 1 GiB is 1024 times that. Also, I expect that by the time I'm ready to replace Kubuntu in 2017 or 2019 (assuming it passes my usability testing over the next few weeks), there'll be 64-bit applications that aren't available in 32-bit versions (just as there were pretty quickly 32-bit Windows applications that couldn't run on 16-bit Windows, when Win95 came out). Installing 64-bit Unbuntu gives me the option to run both 64-bit and 32-bit versions of software, due to multi-arch support.

And that to say, bobbicat supplied the solution to the kernel panics (it had been suggested in the thread on Mepis forums where I asked for pointers to a replacement for Mepis, also, but bobbicat bypassed my last question over there, on whether I'd need to syslinux the resulting USB partition): use dd to create the USB instead of unetbootin, then reinstall from that. Once I remembered to relabel the Kubuntu partition to match the root=LABEL=Kubuntu64 in Grub, it booted right in (initially, it booted via Grub 2, because I forgot to look for the checkbox in the installer to put Grub 2 in sda1 instead of the MBR, but after running the Grub repair from Mepis System Assistant, I'm back to booting directly from Grub Legacy -- not better than Grub 2, perhaps, but more comfortable in that I can fix most things that will go wrong with it using a text editor from virtually any Live CD/USB).

I'd have to suggest this (dd-created USB installing successfully, unetbootin-created USB install failing, undetected until the reboot) points to a bug in either unetbootin or the various Ubuntu derivative installers, as it seems there have been a number of reports that unetbootin sometimes produces a bootable, seemingly correctly-working Live USB that produces a failing installed OS. Given unetbootin appears to be the only easy to find non-distro-specific Live USB creator for Linux user who aren't guru enough to know how to use dd for this, it seems it would behoove the (*)Ubuntu developers to work with unetbootin developers to ensure the installers work with unetbootin.

Edit: Umm, how do I mark the thread "solved" in this software?

[claydoh]

I don't know. I have had unetbootin fail somewhat regularly for a number of different non-Ubuntu distros, so perhaps it is not OS specific.
They use Ubuntu's launchpad for bug reports, and I do not see as many reports on booting the thumb drives as I would have expected - either they are not common enough, or no one is filing them.



I won't tell you how to manage grub, but I will say that grub 2 is just as easy to edit as the old one, it is just the what and where that has changed. Might be worth investigating.

[Leftoverture]

Great that you've got it up and running!
I know that sometimes Unetbootin can be a pain...somewhere...but I never had problems with Debian based distributions, at least, the ones I tried.
Where Unetbootin puts a label, dd doesn't

Kubuntu is actually the first 64-bit 'Debian' I encountered that wasn't a friend of Unetbootin...

OpenSuse won't work with Unetbootin, that's for sure, and Arch.

For those I have used the dd way, you only have to format your usb devices after using them this way.

[Silent Observer]

I don't know. I have had unetbootin fail somewhat regularly for a number of different non-Ubuntu distros, so perhaps it is not OS specific.
They use Ubuntu's launchpad for bug reports, and I do not see as many reports on booting the thumb drives as I would have expected - either they are not common enough, or no one is filing them.



I won't tell you how to manage grub, but I will say that grub 2 is just as easy to edit as the old one, it is just the what and where that has changed. Might be worth investigating.

Okay, I've filed a fresh unetbootin bug report. I'm considering reinstalling Grub 2 in the Kubuntu64 partition; that will allow me to install grub-customize and get some practice managing Grub 2 so I can decide which one does the job better for me.

Meantime, since I do have Kubuntu booting and no longer get the kernel panics, and more importantly am pretty confident what caused (the 87% to reboot jump in the installer) and solved (creating USB with dd instead of unetbootin) the problem, I'd like to mark this thread and the other one as solved -- but I don't see a way to do that.

[bobbicat]

If you are logged in and you initiated the thread, check out 'Thread Tools' at the right on the bar up top
You'll find the place to mark a thread 'SOLVED' in there
Glad you had a successful install, hope you enjoy

[Silent Observer]

If you are logged in and you initiated the thread, check out 'Thread Tools' at the right on the bar up top
You'll find the place to mark a thread 'SOLVED' in there
Glad you had a successful install, hope you enjoy

Thanks. I'm enjoying it immensely so far; I've already got a few tweaks in place that make it feel a lot like my old Mepis system -- except it seems faster (might well be; the 3.13 kernel is probably more efficient than the 2.26 Mepis uses).

[jlittle]

An observation after following the thread.

If you like editing menu.lst and controlling grub that way, and have several distros, you can use grub 2 in a similar fashion. I suggest using a separate small partition just for grub, and maintaining grub.cfg there by hand. Grub 2 instances in each of your installed distros then don't trample on each other, and some random system update won't upset stuff, and moving partitions around doesn't make your system unbootable. I've seen this approach recommended here, and on the grub help mailing list. Every so often, perhaps once a year, I review the grub.cfg generated by my Kubuntu install and see if there's some new stuff I'd like in my hand-maintained one.