Announcement

Collapse
No announcement yet.

Installing Kubuntu first time; disks show swapped?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Installing Kubuntu first time; disks show swapped?

    (Full system details at bottom)

    I'm trying to install Kubuntu 14.04 to replace a side installation of antiX 13.2 64-bit (testing repos) which is failing to accomplish what I need from it, which is give me a system that lets me use the same browser for both Flash and Java, and won't require a clean reinstall every couple years. I thought the rolling nature of testing repos would do that, but it's keeping me from being able to install Wine, hence Pipelight, which appears to be the only currently available solution to making a current Flash version available in a Linux browser that can also use Java. With Ubuntu (and hence Kubuntu) offering upgrades with major version changes, the time required when the old version starts to get too arthritic will be greatly reduced (compared to a clean install and reinstalling all packages and recreating all settings).

    Where the question arises is this: I ran into the bug in which the Kubuntu installer hangs at the "Prepare" step, which my reading suggests is due to taking a huge amount of time to examine the dozen or so partitions on two internal hard disks (my two external drives are powered down, so not detected, else this would be even worse). I found the work around is to ensure all the partitions I won't be clearing for / or using for swap and /home are mounted in the live session before starting the installer, so I started Kubuntu Live and opened kparted -- only to find that the drive designators (sda1, sdb1) are swapped from what my existing Linux installations (and existing Legacy GRUB) use. Complicating this is the fact that, in order to get my almost six year old MSI P6NGML motherboard to boot from the IDE drive with Linux partitions on it while the SATA drive with Windows XP is present, I have the BIOS/CMOS set to swap the drives, and use MAP in menu.lst to reswap when I want to boot to Windows (which I haven't done since mid-2013, and don't expect to do in future). So, I'm finding kparted in Kubuntu Live is unswapping my drives.

    I think I can go ahead with the install (clearing the partition currently containing antiX, reusing my existing swap, and creating a new user folder in the existing partition where I have all my /home folders -- which last has worked well in the past when upgrading Mepis 11 from 32- to 64-bit and when installing antiX 13.2 64-bit) and depend on manually editing the existing GRUB menu.lst to find the new Kubuntu, but I'm concerned that the Kubuntu install will become confused about what drive designator it's on and potentially overwrite stuff stored in one of my Windows partitions -- which would be disastrous, since it'd be confusing EXT4 with NTFS if that were to occur.

    Am I okay with this, or will I need to use MAP in menu.lst to reswap the drives the way I already have set up for the Windows launch?

    Also, since this is mainly about being able to use Pipelight, do I need to stick with 32-bit Kubuntu to have that work smoothly, or would 64-bit work equally well? I have 4 GiB RAM installed, but I've done a PAE kernel upgrade once before when using Mepis 11 32-bit, and expect it could be managed in Kubuntu if needed; however, if 64-bit has no disadvantages relative to Pipelight and Wine, I'd rather install that version to start with.

    System info:

    Kubuntu 14.04 32-bit, currently live (trying to install as multi-boot alongside WinXP and Mepis 11 64-bit)
    KDE 4.13.0
    Legacy GRUB 0.97-64, but I'm not started with GRUB yet; booted to Kubuntu Live USB via unetbootin.
    System has WinXP 32-bit, Mepis 11 64-bit, and I'm trying to replace antiX 13.2 64-bit (testing) with Kubuntu.

    Desktop system
    Intel Core2Quad 2.7 GHz (Q9440, I think) -- 64-bit, 4-core, w/ 3 MiB Level 2 cache
    nVidia GT520, currently on default Live session drivers, will have nVidia drivers installed via sgfxi
    4 GiB RAM installed
    2 HDDs -- one SATA 1 TB, less than a year old, 7 NTFS partitions; one IDE 120 GB, 7-8 years old (six partitions including the one that's to receive Kubuntu; also contains other Linux, shared /home with separate user folders, and swap) both read clean with S.M.A.R.T. monitor
    1 CD-RW 40x
    Last edited by Silent Observer; Jul 20, 2014, 07:59 AM. Reason: Provide GRUB version information

    #2
    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.

    Comment


      #3
      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.

      Comment


        #4
        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.Click image for larger version

Name:	0720141513.jpg
Views:	1
Size:	66.6 KB
ID:	642338

        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.

        Comment


          #5
          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?
          Last edited by Silent Observer; Jul 20, 2014, 06:44 PM.

          Comment


            #6
            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:
            Click image for larger version

Name:	0721141753.jpg
Views:	1
Size:	73.3 KB
ID:	642339

            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:
            Click image for larger version

Name:	0721141754.jpg
Views:	1
Size:	114.8 KB
ID:	642340

            I think I've got a corrupted install.

            Comment


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

              Comment


                #8
                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).

                Comment


                  #9
                  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.

                  Comment


                    #10
                    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)

                    Comment


                      #11
                      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...

                      Comment


                        #12
                        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.

                        Comment


                          #13
                          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.

                          Comment


                            #14
                            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.

                            Comment


                              #15
                              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.
                              Last edited by bobbicat; Jul 25, 2014, 06:30 PM.

                              Comment

                              Working...
                              X