To totally unlock this section you need to Log-in
Login
Linux doesn’t always run smoothly on Hyper-V, although it’s undeniable that the situation has gotten substantially better as Microsoft has put more effort into it.
Sometimes, the way that Linux manifests a problem befuddles administrators that are used to the Windows platform. When issues crop up that we’re unfamiliar with, there is a strong temptation to wonder if it’s because there’s something wrong with Linux or if it’s a Hyper-V issue. From experience, we know that most people tend to blame Hyper-V first.
One such scenario is a Linux-based virtual machine is instructed to shut down or restart, but never does. The assumption seems to be that something has gone wrong in the guest-to-host communications process. One “fix” that we saw was to disable Dynamic Memory. Sorry, but that isn’t a fix — at best, it’s a work-around.
This article was written using Ubuntu Linux, but should be applicable to any Debian-based distribution. Other distributions might have similar symptoms and fixes, although you’ll have to look elsewhere for a translation. Depending on your confidence in your Linux system and skills, you might want to take a backup before trying the steps shown here.
Unfortunately, there isn’t a single reason that a Linux system might refuse to shut down. It’s very verbose about it, though, so you might be able to just watch the process and find out that it’s hanging up in a particular location and search on that for a fix. The case that we are going to present here is one that can happen to anyone, is fairly simple to reproduce, and has a fix that is not at all obvious.
NOTE: in this scenario the "hang" on shutdown or restart of Linux is NOT due to Hyper-V but an internal Linux behaviour with the /boot mount point.
The symptom is quite simple: the guest goes through all the motions of shutting down and reaches the point where it should stop or restart, and then simply hangs:
The final line states “Reached target Shutdown”. When all is well, this is the very last thing that’s displayed before the guest shuts down or restarts, as instructed.
If you’re having the same problem, there’s a very simple way to find out. Run the following at any prompt:
In the output, check the Mounted on column for the /boot mount point. If it is all, or mostly, consumed, this is likely to be your problem. Compare to the following:
What’s likely happened is that you’ve updated the system kernel a few times. Unlike other packages, old kernels are not automatically cleaned up by the normal processes.
How to Clean Up Old Kernels on Ubuntu Linux
The very first thing to do is find out which kernel you’re currently running. The reason is simple: don’t delete that one. To determine your current kernel version, type the following:
uname -r
On my system, that produced:
From that, we know that we do not want to delete anything about kernel version 3.19.0-33. Why would Linux allow me to delete that version? Why doesn’t Windows stop me from running “deltree %systemroot%”? The point is, take a few seconds to protect you from yourself.
The next thing you need is a list of old kernels that are hanging around. That’s discovered with:
dpkg --get-selections | grep linux-image
Mine produced the following output:
To remove an item from the list, just enter the following:
apt-get remove --purge linux-image-3.0.19.0-21-generic
You do not need to specifically remove the items marked with the word “extra”. They will be automatically removed along with the kernel of the same name.
You’ll then be taken through the normal apt-get process of confirming the removal and watching the results as they happen. Repeat the above steps for any remaining kernels...except the one from step 1.
Note: It is possible to issue multiple items after –purge, but we recommend that you not do so in this case. We actually caused our test system to hang when we tried that. It recovered just fine, but we don’t know that you’d want to take that kind of gamble on a production system.
If you’re running through PuTTY, there is a way to make this process faster. First, type out the remove line:
apt-get remove --purge
Make sure you put in a space after purge. Then, scroll back up to the list of kernels. Highlight the oldest:
Then just right-click. PuTTY will automatically append the highlighted text wherever the cursor is, automatically producing this line (or whatever you highlighted on your system):
apt-get remove --purge linux-image-3.19.0-21-generic
That’s it! Just press [Enter] and finish up as normal from step 4.
Confirmation
Once all the old kernels are removed, run df again. You should have much different results:
If your Linux system is in a place where a bit of downtime won’t hurt anyone, verify your results the easiest way:
shutdown -r now
If all went well, your Linux guest should restart as expected. Unless you deleted your active kernel, the worst-case scenario is that you have a much cleaner boot partition.
Why Removing Old Kernels?
For LVM, encrypted, or limited-storage systems, you need to regularly remove old kernels to prevent your computer (/boot partition) from running out of storage space.
Removing old kernels is easy. You can do it manually, or set unattended-upgrades to do it automatically. For details, open terminal from App Launcher or via Ctrl+Alt+T shortcut keys, and follow the steps below:
Remove Automatically Installed Kernels (AutoRemove)
To remove the kernels that were automatically installed via regular system updates, open terminal and run:
sudo apt autoremove --purge
It will ask you to type in user password and then remove old kernels as well as other automatically installed packages that are no longer needed.
Remove Automatically Installed Kernels (DPKG)
To enable automatic removing of old kernels:
Run command to enable unattended upgrades. For Desktop Ubuntu 16.04, this is enabled by default.
sudo dpkg-reconfigure unattended-upgrades
Edit the config file via command (first install gksu via sudo apt install gksu):
gksudo gedit /etc/apt/apt.conf.d/50unattended-upgrades
When the file opens, uncomment the following line and change the value to true:
//Unattended-Upgrade::Remove-Unused-Dependencies "false";
So it looks like:
Remove manually old kernels via DPKG
If your /boot partition has already full while doing an upgrade or package install, and apt can’t remove packages due to broken dependency, here you can manually find out the old kernel packages and remove them via DPKG:
Run command to check out current kernel and DON’T REMOVE it:
uname -r
List all kernels excluding the current booted:
dpkg -l | tail -n +6 | grep -E 'linux-image-[0-9]+' | grep -Fv $(uname -r)
Example output:
rc linux-image-4.4.0-15-generic 4.4.0-15.31 amd64 Linux kernel image for version 4.4.0 on 64 bit x86 SMP ii linux-image-4.4.0-18-generic 4.4.0-18.34 amd64 Linux kernel image for version 4.4.0 on 64 bit x86 SMP rc linux-image-4.6.0-040600rc3-generic 4.6.0-040600rc3.201604120934 amd64 Linux kernel image for version 4.6.0 on 64 bit x86 SMP
There will be three status in the listed kernel images:
- rc: means it has already been removed.
- ii: means installed, eligible for removal.
- iU: DON’T REMOVE. It means not installed, but queued for install in apt.
Remove old kernel images in status ii, it’s “linux-image-4.4.0-18-generic” in the example above:
sudo dpkg --purge linux-image-4.4.0-18-generic
If the command fails, remove the dependency packages that the output tells you via sudo dpkg --purge PACKAGE.
And also try to remove the respective header and common header packages (don’t worry if the command fails):
sudo dpkg --purge linux-image-4.4.0-18-header linux-image-4.4.0-18
Finally you may fix the apt broken dependency via command:
sudo apt -f install
A VM based on Ubuntu Linux could not shutdown or restart in Microsoft Hyper-V environment (also in VMware ESX). Let’s see how to check and fix a common issue regarding this behaviour. See: http://heelpbook.altervista.org/2017/ubuntu-linux-server-guest-vm-hyper-v/ #hyperv #microsoft #linux #ubuntu