Announcement

**Silent Observer** · Jul 20, 2014, 01:03 PM

Well, lacking any response over the course of four-plus hours, and Sunday being when I have free time, I went ahead and cleared the partition and installed Kubuntu 14.04 64-bit (it went so quickly, I can just put 32-bit in its place if it turns out I need that to give Pipelight a reasonable chance to work right). Install went smoothly enough once I'd started the Live session and ensured that all partitions except the one that was to receive Kubuntu, the swap, and the one that was to be /home were mounted; instead of hanging at "Prepare" for half an hour before I gave up, as previously, in less than five minutes I had a warning that partitions were mounted and asking if I wanted to unmount them -- and I was off and running. The install went very smoothly, though it helps to have installed other flavors of Linux a number of times in terms of figuring out how to select the partitions to be used. To avoid damaging my existing bootloader (GRUB 0.97-64) resident in the MBR of what's usually sdb, but which Kubuntu was seeing as sda, I told the installer to put the bootloader in sda1. After installation was complete, I hand edited /boot/grub/menu.lst, as I've done multiple times before, but on restarting and selecting the new Kubuntu entry, I got an instant kernel panic. Here's the text of the menu file:

timeout 10
color cyan/blue white/blue
foreground ffffff
background 0639a1

gfxmenu /boot/grub/message

title MEPIS at sdb7, newest kernel
root (hd0,6)
kernel /boot/vmlinuz root=/dev/sdb7 nomce quiet splash vga=795 nouveau.modeset=0
initrd /boot/initrd.img
boot

title MEPIS at sdb7, kernel 2.6.36-1-mepis64-smp
root (hd0,6)
kernel /boot/vmlinuz-2.6.36-1-mepis64-smp root=/dev/sdb7 nomce quiet splash vga=795 nouveau.modeset=0
initrd /boot/initrd.img-2.6.36-1-mepis64-smp
boot

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=/dev/sdb1 nomodeset quiet vga=795 nouveau.modeset=0
initrd /boot/initrd.img-3.13.0-24-generic
boot

title Windows NT/2000/XP at sda1
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd0,0)
chainloader +1

title Windows 95/98/Me at sda5
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd0,4)
chainloader +1

title MEMTEST
kernel /boot/memtest86+.bin

What's listed here as sdb is the IDE drive with my Linux partitions, while sda is the Windows drive with the NTFS partitions.

I note that Kubuntu would have used GRUB 2 by default, which I'm glad I avoided because it's very confusing to try to make any changes, but it appears that something isn't getting preset correctly by Legacy GRUB; I didn't get a copy of the entire kernel panic message (I can reproduce it and take a photo of the screen, if necesary), but it said something about passing "init=" to the kernel. I doubt this is a conflict with my hardware, as I've previously run 3.13.x and 3.14.x antiX kernels on this machine and the panic was (I think) too early to have loaded anything very specific in the way of drivers.

**SteveRiley** · Jul 20, 2014, 01:31 PM

Two things strike me as potential sources of your problem:

Originally posted by Silent Observer View Post

nVidia GT520, currently on default Live session drivers, will have nVidia drivers installed via sgfxi

Originally posted by Silent Observer View Post

kernel /boot/vmlinuz-3.13.0-24-generic root=/dev/sdb1 nomodeset quiet vga=795 nouveau.modeset=0
I didn't get a copy of the entire kernel panic message...but it said something about passing "init=" to the kernel

I don't think any of us here use sgfxi to install nVidia drivers. Instead, we use either Jockey (the GUI tool) or apt-get to install the packaged drivers from the *buntu repository. Some of us prefer the more up-to-date drivers from the Xorg-Edgers PPA.

You are passing nomodeset and nouveau.nomodeset to the kernel. Any reason why? The nVidia driver works just fine with modesetting -- in fact, I think it's required.

**Silent Observer** · Jul 20, 2014, 03:04 PM

Okay, if there's a better/different tool for installing nVidia drivers, I'm glad to hear it -- sgfxi the graphic driver piece of a huge script set collectively called inxi, which appears to be more or less standard through the Debian universe (apparently except for Ubuntuland). If I get a current nVidia driver and Xorg is happy with it, I don't much care how I get it. As it happens, I haven't done that at all yet; I was presuming I'd do that ahead of other stuff only if there were video problems (past experience with Mepis was that the nouveau driver didn't work well with my hardware, but newer nouveau as found in antiX and seemingly Kubuntu seems fine), and obviously haven't gotten that far yet.

I'm passing the nomodeset and nouveau.modeset=0 because those are what's been required with other Debian-based distributions I've tried in the past (I don't have any idea where to get clues from Grub 2 about what Kubuntu is expecting), but I've also tried commenting that line and replacing it with one that ends after the drive designator, with identical results. The startup isn't getting far enough to set a video mode, or even to set the high resolution text mode my other distros use during startup. I've tried running update-grub from Mepis, but it fails to detect that Kubuntu has even been installed -- possibly because I didn't allow the bootloader to overwrite the one I already have on hd0.

However the drives are getting unswapped (even with Grub Legacy, I'm having to use sda1 instead of sdb1 for the Kubuntu to find the correct partition), it doesn't look as if there'll be a problem with trying to write to the wrong drive, at least; if I use the same designators as the other menu.lst entries, GRUB gives an error about an invalid partition (expecting ext3, finding NTFS) rather than starting just enough to give a kernel panic.

Here's a screen photo of the kernel panic I'm getting; hopefully there's some information there that someone can interpret, because it's Greek to me.

**Silent Observer** · Jul 20, 2014, 06:22 PM

Well, as is sometimes the case when I try to fix Linux issues, I've made it worse. I tried to use the Mepis System Assistant in Grub Repair mode, in hopes it would detect Kubuntu, and even though I backed up the working menu.lst, I've now got a situation where I can't boot even after using a live CD to replace menu.lst with the previously working one. I think I might have specified the wrong boot disk (got confused on what was the startup disk after this crossup with Kubuntu disagreeing on which was sda and sdb, I think) or wrong partition. If I can't get it going myself before bedtime, I'll post over on the Mepis forum for help getting Mepis and Grub Legacy straightened out, and check back here after I can boot from the hard disk again.

Edit: Well, it helps to have made the same mistake previously, and to have a good memory (for some kinds of details). I've got things back to where they were in terms of booting to Mepis, meaning my system is as usable as it was when I first posted. I've also got the same kernel panic trying to start Kubuntu.

At this point, I've got very little invested in this Kubuntu installation; if it would be easier to start over with a few modifications to the process (which, as far as I can tell, was very standard other than putting Grub 2 on sdb1 instead of the MBR of sdb), I could do that with the loss of only a few minutes reinstalling. Alternately, should I be trying to chainload Kubuntu, and if so, how does that command differ from the one that starts Windows XP?

**Silent Observer** · Jul 21, 2014, 04:03 PM

Okay, answering my own question to some level -- I used the following stanza to launch Kubuntu:

title Kubuntu 14.04 LTS at sda1, kernel 3.13.0-24-generic
rootnoverify (hd0,0)
chainloader +1

I got pretty much what I expected -- the Grub 2 startup menu, looking like this:

Now, confident I'd be launching Kubuntu exactly the way the installer planned, I went ahead: and got a kernel panic that looks almost identical to the one I got launching Kubuntu directly from Grub Legacy:

I think I've got a corrupted install.

**SteveRiley** · Jul 21, 2014, 08:20 PM

Maybe your initramfs actually is bad? You might try booting from a live CD, chrooting into your Kubuntu install, and creating a new initramfs.

**Silent Observer** · Jul 22, 2014, 04:08 AM

Two complicating factors to doing that. First, I don't know how to manually create a new initramfs (I can probably find out); second, on the presumption that I might have a corrupted download, I re-downloaded the Kunbuntu 14.04 64-bit iso and re-burned it to the USB key -- wrote the key twice with a fairly old version unetbootin, the only method I have to create a bootable USB in Mepis 11 -- and I keep getting "Operating system missing" when I try to start from the USB.

I installed unetbootin on my second desktop machine, which runs antiX 13.2 on (antiX and Debian) testing repos, and got a much newer version of unetbootin, which is capable of downloading Kubuntu 14.04 64-bit, but that was still writing the USB when I had to go to bed last night (5 AM comes too damned early). I'm going to test that USB write in about two minutes, and if it works, I'll Google how to recreate initramfs -- and I'll post back with the results, though likely after work (have to get off here at 6:30 EDT to be at work on time).

**Silent Observer** · Jul 22, 2014, 02:17 PM

Okay, the USB written by the newer version of unetbootin (603 something) booted fine this morning; however, I didn't find I could chroot from the Kubuntu live session. I don't recall now whether I got an error message (along the lines of "command not found") or couldn't navigate to the proper location to set the root, but this afternoon I tried it from Mepis 11. As root:

cd /mnt/sdb1/
chroot /mnt/sdb1/
update-initramfs -ct -kall

I got a report that initrd.img.3.13.0-24-generic was being created, and no errors of any kind (once I found the correct syntax for each command). I restarted, and got the exact same kernel panic trying to load Kubuntu.

Probably unrelated, but potentially useful, I discovered that the wubi.exe found in the root directory of the Kubuntu Live USB created by unetbootin would start with Wine 1.7.19 (Mepis test repos build) and offer to install several flavors of Ubuntu (including some I wasn't aware of, such as Mythbuntu) from within "windows" (which would be Wine/Mepis). I didn't think that looked likely to work out well (given the number of programs that only mostly work in Wine), so I canceled the operation, but some of the options I was being offered made it look like a virtual machine setup.

**Leftoverture** · Jul 24, 2014, 03:26 PM

Hi,

I'm new here but this could be my story.
I tried to install Kubuntu 64-bit as well today but failed exactly as you did.

I also got a kernel panic and my screen looked quite the same as yours.
I have used unetbootin to make a bootable usb-stick twice and the results were the same, kernel panic after rebooting.

A live session went fine by the way.

So I decided to burn a 32-bit Kubuntu and it worked!!

Strange, because this is the first time I had to use a 32-bit instead of a 64-bit distro to make my machine running...in the 3 years I have this machine.

(64-bit AMD triple core with AMD graphics and 4 gigs of RAM)

**Silent Observer** · Jul 24, 2014, 04:56 PM

Hmm. That brings up the question of who, if anyone, has successfully installed Kubuntu 14.04 64-bit? I'm on an Intel processor (Core2Quad 9440, 2.7 GHz) with nVidia graphics (which works just fine with the default nouveau driver in the live session, and did that same in antiX), so it doesn't seem likely we'd have the same hardware conflict. It also looks like I've got all the help I'm going to get from SteveRiley, three days since his last reply.

One possibility; I didn't check the MD5 sum on the original download, so it's possible there could have been a corrupted file that didn't affect the Live session. Given I've had the same result (though not identical panics) from Grub Legacy, Grub 2, and Grub Legacy with "nomodeset" cheat code, I'm about ready to try installing Kubuntu again. The install from USB is so fast, I have little or nothing to lose...

**Silent Observer** · Jul 24, 2014, 06:54 PM

Okay, I checked the MD5 sum for the downloaded ISO, did a fresh write to the USB key using the version of unetbootin in the antiX or Debian testing repositories (603 something), and installed Kubuntu again. Everything went smoothly -- and I got the same kernel panic again after rebooting. I don't have the information I need to even look for what causes this.

**Leftoverture** · Jul 25, 2014, 03:03 AM

I also checked the md5sum, as always. As told before, I installed it twice, but failed, but I'm fine with the 32-bit because of the 4 GB of RAM.

**Silent Observer** · Jul 25, 2014, 02:04 PM

I have experience running 32-bit Mepis on my machine; it reports only 3.5 GiB RAM present, which occasionally makes a difference (vs. 4.0 GiB), such as when editing a large photo scan, opening multiple applications, or running a virtual machine. I could install 32-bit, then upgrade to a PAE kernel to access the full installed RAM, but I recall there was considerable hate and discontent when I did that upgrade on 32-bit Mepis 11 -- it was quite a bit less work to install 64-bit. I have more experience with upgrading kernels, now, so it might be different, but I don't see why I shouldn't be able to run 64-bit. I'm running 64-bit Mepis 11, and was running a side install of antiX 13.2 64-bit before I wiped that partition to install Kubuntu.

**bobbicat** · Jul 25, 2014, 06:18 PM

I've had difficulties with unetbootin, yum etc myself in the past
You might try making a Live DVD and avoid the USB method

you could also try making a pen drive installer this way, it works for me :

sudo dd if=/path/to/.iso of=/dev/sdx

where
the .iso is the latest verified 'Ubuntu/Kubuntu CD live' download
[sdx] is your usb pen drive device
64bit ubuntu/kubuntu will work okay
use an empty pen drive, 4gb or bigger

ensure you have hard disk space for the install
and you know where it is
[I usually do a manual install, just a matter of defining which partition[s] to use,
for simplicity format to ext4]

Kubuntu/Ubuntu shouldn't need complicated preparation work to install
boot from pen drive and just follow on screen instructions
the installation should complete quite quickly without any problems

[sort out nvidia drivers after install is complete
look in system settings/driver manager]
I've used nvidia for years with kubuntu, it just works

when you have installed and are in Kubuntu run in console:
sudo apt-get update && sudo apt-get dist-upgrade

I'm no super-geek but I've been running Kubuntu for many years
I've always found it simple enough for even me to manage,
reliable, versatile and very economical.

Announcement

Installing Kubuntu first time; disks show swapped?

Installing Kubuntu first time; disks show swapped?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment