0

I had a fully functioning 15.10 VM running under VMWare Fusion for testing Swift and pressed the "Update Software" button today. 300mb later it no longer boots. If I then recreate the VM from scratch and try the update again it fails to boot again. Red message about /etc/rc.local not something... flashes on screen just before boot hangs. Any ideas, fixes? This seems pretty serious to me.

Organic Marble
  • 23,641
  • 15
  • 70
  • 122
J. Doe
  • 1

2 Answers2

0

I had this issue with VMware Workstation 12 Player. The temporary fix is likely similar. I started the VM and it didn't fully complete. I thought, like you, it was the software update that did it. The only updates I had were the kernel update, so that had to be it. I fixed my issue by rebooting with the old kernel.

The fix requires that an ssh server be installed on the VM. Start the VM and let it get to the "hung" state. ssh into the machine and edit /boot/grub/grub.cfg to have it default to the old kernel (3.19.0-49 for me). You can do this by moving the menuentry for the old kernel to the top of the list. Reboot the machine with 'sudo reboot' and hope the VM reboots correctly.

A Dukeman
  • 1
  • Thanks A, unfortunately I didn't have OpenSSH server installed but pressing "shift" at exactly the right time during the boot allowed me to back out to the previous kernel and get things up and running by a fairly painful edit to /boot/grub/grub.cfg. I can't believe this passed QA though. This isn't an obscure configuration! – J. Doe Feb 24 '16 at 12:33
-1

This may be a bug.....been working the snapshots in VMWare so far, but sure hope a fix comes along soon! As it is I'm not updating until I know for sure it's safe.

Post edit: I just can't keep my hands off a screwed up computer...tried a couple more times....reverted to screenshots a couple more times.....read someone booted from an older kernal using the startup screen. I thought I had tried that to no avail, but what I must have done is used the safe start screen from that older kernal and tried to repair the packages. The short story is: If you boot from an older kernal via the start menu, you're saved. Good luck! Hope they fix this soon! I'm not sure how I'll know when it's safe to update now!

PS Just noticed the title of this discussion! I'm in Windows VMWare, but it looks like in this case, it doesn't matter - this being an Ubuntu problem more than a VM problem.

PPS Also tried a repair install(NOT clean install) to no avail - so save yourself the effort - it don't work. this is highly ******!

So, J. Doe, what was the painful edit you made to /boot/grub/grub.cfg to fix it? Since it was so painful, maybe you can make it so us less-talented individuals can cut and paste the edit.... OK, so I read through /boot/grub/grub.cfg, not that I understand it.....but do you think it would be safe, then, to simply delete the menuentry section using/referring to 4.4....that way it would proceed to just use 3.19.....?? On the other hand, looking at the file once more it isn't at all that clear to someone who doesn't understand the code where, exactly to begin and end the delete, so some help would be in order. Huh, huh, please?

HERE'S AN ACTUAL ANSWER!!!:

A temporary solution (until the bug is fixed) was to remove the version 4.2.0-30 kernel. This should revert you back to whatever the last version that was working. The command below worked for me:

sudo apt-get --purge remove linux-image-4.2.0-30-generic linux-image-extra-4.2.0-30-generic

Yipee....that worked for me, too! But that still begs the question, "When is it safe to update?" I guess we'll just have to pay attention to Ubuntu info.....

zlot
  • 1