Freshly upgraded, now Kubuntu won't finish booting.

[Silent Observer]

I upgraded to 16.04 today -- about two hours sitting at the console watching the progress bar creep, after coming back to it an hour along and finding it'd been sitting at a prompt waiting for me to okay setting up lightdm. After all of that, which appeared to go smoothly (lots of little reports, but none of them anything I haven't seen in previous updates on Kubuntu or other distros), and reminding myself how to get into BIOS settings on my computer to reset the boot sequence so I was once again starting from the SSD with Kubuntu on it, I got the Legacy GRUB startup screen, selected the option that launches Kubuntu -- and watched it crash before even getting to the GUI. Booted from my 14.04 USB stick, realized I hadn't created the shortcuts for vmlinuz and initrd.img that my default startup uses; fixed those, and restarted from the SSD. This time it at least started, and was obviously a different sequence of scrolling text from what I'm used to seeing, but after going through the section where it mounts all the partitions, I got the following message: "A start job is running for dev-disk...e50.device" with a timer counting up to 1min 30s. Once the timer ran out, I was welcomed to emergency mode.

I presume this has something to do with 16.04 not updating some of the customization I have on a machine with two platter drives and an SSD, a total of seventeen partitions. I just hope it's the only thing I have to fix; it's something I can probably find an answer for (likely a device or partition isn't mounting correctly).

And yes, I made a full copy of the Kubuntu partition with 14.04 before upgrading, if all else fails I can copy that back to its original location and everything should be happy.

[Silent Observer]

Okay, progress, of sorts. I found various threads online suggesting the "startup job" error was usually due to a mismatch between the contents of /etc/fstab and the actual partitions present -- in this case, the partition ID of the target partition for my backup (done with "copy partition" in KDE Partition Manager) had apparently change; I quick & dirty fixed it by commenting that line out of fstab, and now the boot goes right past that point, up to the GUI login screen. After logging in, however, the login splash never changes. I used CTL-ALT-F1 to kill the GUI, and got a working command line prompt, where I was able to successfully log in.

When I've run across this before, I recall it had to do with upgrading Xorg, and I did see a new nVidia driver install along with all the other updates during the upgrade process -- as I recall, I need to delete some configuration file (probably the one the upgrader asked me about -- did I want to overwrite the user modified config file, or keep it?). Off to find out what file that is...

[Silent Observer]

Okay, still not getting anything. I recalled long ago (3 years or so -- computer "forever") having to update/reinstall proprietary video drivers if you have an X update or kernel update, so I tried (from command line -- not easy to do) installing an old version of the nVidia driver (304) from repos. No joy, but I was informed that the sources aren't present for the "old version" kernel, 3.13.085-generic, which was kept in the upgrade from 14.04.1 to 16.04. I found that the system boots just as well in that kernel as in the new 4.4.021-generic -- and just as poorly. Each time I've installed or changed version of the nVidia driver, I've gotten the reports I'm used to seeing during kernel updates where the video driver is "baked" into the kernel, but only for the 4.4.021 kernel. I've tried renaming /etc/X11/xorg.conf (which X is supposed to generate if not present) and got no change.

I'm dying here, I'm stuck using an OS that I abandoned two years ago as hopelessly out of date and no longer supported. I can't get screen dumps from the system I'm trying to fix, because I have no way to get them onto MEPIS, and MEPIS won't mount the Kubuntu partitions (I think that's just due to fstab setup, but why re-learn how to fix a system I don't use?) so I can't just copy from the logs. I can't even read my email, because I don't want to risk this old setup mangling my email storage.

I started using Kubuntu to avoid stuff like this -- now I can't use my main desktop machine. I don't really want to copy back the 14.04 partition if I can avoid it, but if I can't get this fixed today I'll have to, because I won't have time to work on fixing it until next weekend (and I'm not really 100% confident that will work, either). If I have to do that, I'll make a copy of the installed 16.04 first, so (assuming the restoration works) I can put it back when I have time to work on it again.

Is anyone reading this who actually understands Kubuntu?

[Silent Observer]

Well, I'm back on 14.04.1 at this point. Once I figured out that every time I copy a partition to a new location, it gets a new UUID (as if I'd just created a new partition, not copied data to an old one -- I presume this is specific to using partition managers to do the backup/restore), I was able to correct the fstab and Legacy GRUB so the system boots smoothly, as it did before. Of course, 14.04.1 LTS works just as well as it did before attempting the upgrade. I copied the upgraded partition, now at 16.04, to another previously empty partition, so I can put it back (and fix GRUB and fstab) when I'm ready to work on it again, but in the meantime I can use my computer for browsing, email, writing, games, etc.

For someone who uses a computer the way I do (i.e. the computer itself isn't a hobby, it's a tool, and I use Kubuntu for its combination of ease of use, stability, and freedom from the coming paid subscription model of software and operating systems), this is an obvious fail, and I seriously doubt waiting three months for the first point release and automatic upgrade notification would have made any real difference here. I might try installing 16.04 clean, except that now I don't have any empty partitions to put it in; I didn't want to do that at first, because it would take me days to get everything reconfigured to work the way I'm used to. At this point, I'm going to wait to see if anyone makes a useful suggestion on how to get the video drivers to behave in 16.04.

[vinnywright]

are you saying that ,,,,wile in the working 14.04 ,,,,,,and doing

sudo update-grub

it dose not find the 16.04 partition/ install and add it to the grub menu ?

so you could possibly boot to it and playwith/fix it !

it is a hole install just moved to a diferent partition ,,,right?

VINNY

[Silent Observer]

Well, update-grub probably wouldn't do what I want, because I use Legacy GRUB rather than GRUB 2, but yes, I could likely edit the menu.lst for the GRUB I use to point to the 16.04 backup and correct the fstab in that partition and be able to go directly to it, now that I have 14.04 back up and running. I might actually try that, as something I could do in twenty minutes or so that would let me continue hacking at getting 16.04 working when I have twenty minutes at a time to try something.

[Silent Observer]

Okay, as something that looked like it would be pretty simple to do, I went ahead and added the GRUB entry for the 16.04 upgraded partition, fixed the fstab there, and tried to boot into it, thinking I'd get the same graphics failure as previously.

Nope, not that simple. Instead, I'm getting a mount failure when the system tries to mount the root partition to the /root mount point:

mount: mounting 0c639b23-d64a-4d7f-ad6c-76c519164c4e on /root failed: No such device

I've checked that UUID multiple times; I put it in fstab and menu.lst by copy/paste from the partition properties as displayed by KDE Partition Manager, same method that worked fine as part of getting me back into 14.04.

I'm going to paste in both of those relevant files: the Legacy GRUB menu.lst that controls my system's boot (note the Windows entries are long obsolete; the Windows on this machine doesn't boot and I haven't bothered to try to fix it since long before I switched from MEPIS to Kubuntu).

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

gfxmenu /boot/grub/message

title MEPIS at sdb7, newest kernel
root (hd0,5)
kernel /boot/vmlinuz root=UUID=2db3987e-60bd-4566-b61f-20d3cd9dc39f nomce quiet splash vga=795 
initrd /boot/initrd.img
boot

title MEPIS at sdb7, kernel 2.6.36-1-mepis64-smp
root (hd0,5)
kernel /boot/vmlinuz-2.6.36-1-mepis64-smp root=UUID=2db3987e-60bd-4566-b61f-20d3cd9dc39f nomce quiet splash vga=795 
initrd /boot/initrd.img-2.6.36-1-mepis64-smp
boot

title Kubuntu 14.04 LTS at sda1, latest kernel
root (hd0,4)
kernel /vmlinuz root=UUID=b401b3f9-9dc6-4c3d-80fe-aabaf5f327cc nosplash vga=795
initrd /initrd.img
boot

title Kubuntu 14.04 LTS at sda1, (previous kernel version)
root (hd0,4)
kernel /vmlinuz.old root=UUID=b401b3f9-9dc6-4c3d-80fe-aabaf5f327cc nosplash vga=795
initrd /initrd.img.old
boot

title Kubuntu 16.04 LTS at sda8, (upgraded from 14.04.4)
root (hd0,7)
kernel /vmlinuz root=0c639b23-d64a-4d7f-ad6c-76c519164c4e nosplash vga=795
initrd /initrd.img
boot

title Kubuntu 16.04 LTS at sda8, (upgraded from 14.04.4)
root (hd0,7)
kernel /vmlinuz.old root=0c639b23-d64a-4d7f-ad6c-76c519164c4e nosplash vga=795
initrd /initrd.img.old
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

And here's the /etc/fstab as it exists in the 16.04 partition, which would be /dev/sdc8 -- and when not booting from that partition, mounts as /mnt/sda8.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
# UUID=1b6bbb3a-6060-474c-a3c5-1ac32ab1cdd7    /               ext4    defaults 0       1
UUID=1b6bbb3a-6060-474c-a3c5-1ac32ab1cdd7    /mnt/sdc1    ext4    defaults    0    0
# /home was on /dev/sda6 during installation
# UUID=fc4dda46-31d9-4746-aca0-306f449a5489    /home           ext3    defaults        0       2
UUID=fc4dda46-31d9-4746-aca0-306f449a5489    /mnt/sdc6    ext3    defaults    0    0
# swap was on /dev/sda5 during installation
# UUID=309c3566-5e92-421c-a646-19704e89ca3c /swap            swap    sw              0       0
# Other Linux drive: /dev/sda7
UUID=14e7415b-f636-419b-a988-430187ce738d    /mnt/sdc7    ext3    defaults    0    0
# NTFS/Windows drives: /dev/sdb1
UUID=5E5C65065C64D9F3    /mnt/sdb1    ntfs-3g    auto,user,exec,relatime    0    0
# NTFS/Windows drives: /dev/sdb5
UUID=88CCAB91CCAB77D8    /mnt/sdb5    ntfs-3g    auto,user,exec,relatime    0    0
# NTFS/Windows drives: /dev/sdb6
UUID=3680C08C80C05451    /mnt/sdb6    ntfs-3g    auto,user,exec,relatime    0    0
# NTFS/Windows drives:
UUID=E6ACC7B2ACC77B95    /mnt/sdb7    ntfs-3g    auto,user,exec,relatime    0    0
# NTFS/Windows drives:
UUID=48CCD912CCD8FB60    /mnt/sdb8    ntfs-3g    auto,user,exec,relatime    0    0
# NTSF/Windows drives:
UUID=CA58E44A58E436BB    /mnt/sdb9    ntfs-3g    auto,user,exec,relatime    0    0
# new SSD partitions
UUID=5244bd6b-56d2-4966-bc64-b5d145e681ec    /mnt/sda1    ext4    errors=remount-ro    0    1
UUID=a7bf4f9c-f525-4646-87dd-f897cec03c66    /swap    swap    sw    0    0
UUID=b401b3f9-9dc6-4c3d-80fe-aabaf5f327cc    /mnt/sda5    ext4    defaults    0    1
UUID=2db3987e-60bd-4566-b61f-20d3cd9dc39f    /mnt/sda6    ext4    defaults    0    0
UUID=5dc15ff8-963e-47d4-8d05-fb421bbe72fc    /mnt/sda7    ext4    defaults    0    0
UUID=0c639b23-d64a-4d7f-ad6c-76c519164c4e    /    ext4    defaults    0    0
UUID=4b9c2919-2a90-432e-84e8-28483861a4b0    /home    ext4    defaults    0    2

[vinnywright]

ya your /etc/fstab is extremely F'ed up the blkid's do not match as per the grub-menu-list and the fstab ,,,,,,and the fstab for 16.04 is not mounting a / (root)

VINNY

[Silent Observer]

Look again. The fstab mounts / on the next to last line. The partitions are kept in the same order in the fstabs for multiple installs (one each of MEPIS and Kubuntu on an old platter drive, and on the SSD, before this upgrade attempt put Kubuntu in two other partitions). I think you'll find on closer examination that the UUID for that partition does in fact match the one specified in menu.lst for 16.04.

I'll admit it may be less than clear to an outsider, but this comes from updating and upgrading fstab from the original (installed on a 120 GB platter drive alonside Windows and data partitions filling a 1 TB platter) to MEPIS and Kubuntu partitions copied to the SSD, which also had two more vacant 20 GB partitions and a 150 GB /home partition shared between the installs (separate user home folders, however).

[Silent Observer]

To quote one of the great philosophers of our age, "D'oh!"

I found the problem with the menu.lst. It was missing five characters from each of the Kubuntu 16.04 entries. I should have had "root=UUID=" where I only had "root=".

With that repaired, I'm once again getting all the way to the graphic login; I enter the user name and password, hit "Enter", and get -- nothing. Not a black screen, rather, no change other than clearing off the login dialog. My login splash remains for at least several minutes (it used to change to the KDE startup progress animation within two or three seconds after logging in). If I hit CTL-ALT-F1, I get a command line login prompt, and there appears to be a fully functioning 16.04 command line Linux -- which I used just now to issue the following commands (as su -- I've set my system up to use su instead of doing everything from sudo, and I have a different color scheme for GUI apps opened with su privilege, so I don't forget who I am):

apt-get update
apt-get install nvidia-361

This resulted in the usual "build-in" sequence as the driver modules are embedded in the kernel -- but with a failure 139 when depmod was to be built in. I don't know what this means -- how can I fix it?

[Router Gray]

i'm aware this isn't addressing your other issues, but one thing that might make life easier with the moving and rearranging of partitions is to stop using UUID and start using LABEL, since those only should change if you change them yourself, altho if you copy one to somewhere i think you will have to label it after copying it.

[Silent Observer]

I was originally using LABEL= and was informed at some point (as I recall) that that was deprecated in favor of UUID= (at least for fstab purposes, and it's far easier to have GRUB and fstab use the same disk identifiers) -- and a UUID only changes if I copy or format a partition. Otherwise, I can have (as I do) two partitions named "Kubuntu64", one on the old 120 G platter drive, and the other on the newer SSD, and they don't conflict, because they're identified by UUID.

With no help on the no-GUI front after this much time, it's tempting to suggest I'll wait for 16.04.1 to come out and try upgrading again at that point. It'd be nice to have some time between now and then to work with 16.04, be able to file some bug reports or learn to deal with things that have changed -- but clearly no one really knows how to fix some of the things that are broken with this new release; Canonical should have held it, rather than release on time with a fairly bad beta.

Edit: After posting this, I restarted to 16.04, and once I reached the command line login, was informed there was an update. Installing the update got me several upgrades, and resulted in rebuilding the nVidia 361 driver, this time without the failure at depmod. With high hopes, I restarted -- with the same results I've had before: after the GUI login, the system just sat on the login splash.

Sigh. Any suggestions, requests for more information to help troubleshoot, or anything at all?

[Router Gray]

may i suggest you get to that command line again and uninstall the nvidia driver, which should result in automatically using nouveau, and see if everything works then? if it does, you have at least narrowed things down. for that matter you don't maybe even have to uninstall it, if you know your way around in the Xorg stuff you can just prevent it loading and make it load nouveau instead, but i'm not that deep into the way things are done these days to be able to tell you the steps, i just know it should be do-able.

[Silent Observer]

may i suggest you get to that command line again and uninstall the nvidia driver, which should result in automatically using nouveau, and see if everything works then? if it does, you have at least narrowed things down. for that matter you don't maybe even have to uninstall it, if you know your way around in the Xorg stuff you can just prevent it loading and make it load nouveau instead, but i'm not that deep into the way things are done these days to be able to tell you the steps, i just know it should be do-able.

I've actually already tried that; I could tell it was loading nouveau becausethe resolution of the login screen changed, buy the result after logging in was the same. I also tried leaving it for a very long time after the login dialogue had cleared, inspired by the length of time restarts were taking sometimes after trying to get the GUI back up -- with the result that something shut the computer down (didn't restart, did a power off) while I was away from console.

[Router Gray]

hmm. have you tried either deleting/temporarily renaming your kde profile? or another way and more thorough to the same goal, create a new user and log the new user in? but that at least points to some other culprit than the video driver.

another thing you might play with is, if you have some other desktop environment than KDE available, log into it, and if that succeeds, disable all the screensaver/power management/screen lock kind of stuff, especially if your other DE lets you run the kde control center.