Borea Deitz's questions

I just installed Ubuntu 24.04 and I've already hit a problem of things changing with no notice.

On Ubuntu 20.04, when I created a system user using adduser, it created a home folder for that user:

$ sudo adduser --system --group barney
Adding system user `barney' (UID 114) ...
Adding new group `barney' (GID 119) ...
Adding new user `barney' (UID 114) with group `barney' ...
Creating home directory `/home/barney' ...

Now, in Ubuntu 24.04, the exact same command suddenly works a different way:

$ sudo adduser --system --group barney
info: Selecting UID from range 100 to 999 ...

info: Selecting GID from range 100 to 999 ...
info: Adding system user `barney' (UID 112) ...
info: Adding new group `barney' (GID 112) ...
info: Adding new user `barney' (UID 112) with group `barney' ...
info: Not creating `/nonexistent'.

No home folder is created. Okay, fine, one of the thousand paper cuts of using Linux that I've gotten calloused to.

Can I correct this by manually adding the /home/barney/ directory? That is, if I run

$ sudo mkdir /home/barney
$ sudo chown barney:barney /home/barney
$ sudo chmod 775 /home/barney

is that precisely the same as /home/barney/ having been created as the home folder for barney at the time the user was added, or are there further complications under the hood that I'm not aware of?

I've just installed MySQL 8.0.36 on Ubuntu 22.04 and now I want to run mysql_secure_installation.

The guide for this precise thing at Digital Ocean indicates that on Ubuntu, running mysql_secure_installation produces a logic loop if you don't configure the MySQL 'root' user's password first. Following its instructions, I did so:

$ sudo mysql
[sudo] password for user: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.36-0ubuntu0.22.04.1 (Ubuntu)

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'crocodile69210';
Query OK, 0 rows affected (0.00 sec)

mysql> exit;
Bye

After doing this, I am unable to run mysql_secure_installation at all. When I try, I get a password error:

$ sudo mysql_secure_installation

Securing the MySQL server deployment.

Enter password for user root: 
Error: Access denied for user 'root'@'localhost' (using password: YES)

This happens when I enter both the MySQL 'root' user password that I established earlier (crocodile69210) and my OS sudo password. If I enter no password at all, the result is the same except the last line is (using password: NO).

What do I do to be able to run mysql_secure_installation?

Edit: It appears that the ALTER USER statement above does not actually set a password. If I run $ mysql -u root -p and literally copy and paste the password that I set, which is still visible in the terminal history, I cannot login to mysql:

$ mysql -u root -p
Enter password: 
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

I'm not sure if or how this illuminates the problem.

Edit 2: Working on the theory that the Digital Ocean guide is wrong, I uninstalled MySQL ($ sudo apt remove mysql-server) and then re-installed it. I did not run the ALTER USER command given in the DO article. I still cannot run mysql_secure_installation and get the same "Access denied" password errors I got during the first attempt.

Edit 3: More information

When I first installed mysql-server from a fully blank slate, I was able to use $ sudo mysql immediately to access the MySQL interactive shell. I find that after 1) uninstalling mysql-server using $ sudo apt remove mysql-server AND 2) fully purging mysql-server using $ sudo apt purge mysql-server, after I reinstall I still can't use $ sudo mysql. I get the "Access denied" password error. So, something about the first installation is obviously still hanging around. Figuring out what this is will likely help solve the whole problem.

Final Edit:

1. On Ubuntu, apt purge (or apt remove --purge) simply don't work for MySQL. You must follow this procedure to fully uninstall MySQL from your system.

2. I generated the password for the MySQL 'root' user using a password manager, and I did not inspect the password. It had a backslash in it (\). When setting the password using the ALTER USER command, the shell interprets this as an escape character and removes it before passing it to MySQL. Thus, my 'root' password was not actually what I thought I was setting it to.

Do not use backslashes in MySQL passwords

I'm running Ubuntu 20.04 with Plasma desktop. When I boot up and login to the computer, I get a "KDE Wallet Service" modal with the message

The application 'kded5' has requested to open the wallet 'kdewallet'. Please enter the password for this wallet below.

I want this not to appear. In trying to gather the information needed to fulfil this desire, I found this AskUbuntu question which seems to describe the same problem.

One of the answers on that post has this tidbit of information:

On login, networkmanager tries to connect to the wifi and therefore needs access to kwallet. org.kde.plasmanetworkmanagement is a kded module so the request comes from the kded5 process.

Because my modal occurs when the machine attempts to connect to WiFi, and because it will not connect to WiFi until after I enter my sudo password, I'm certain this is my issue: Plasma's networkmanager is trying to get my WiFi password stored in KWallet's default wallet kdewallet, so I have to open the wallet each time.

I never asked to use KWallet, and in fact I never knew exactly what it was until today. On my Ubuntu systems that use the Gnome or Cinnamon desktops, I've never had to worry about wallets or built-in password managers. Instead, I type in my WiFi password once, and it's remembered forever without me having to deal with it ever again. This experience with other DEs demonstrates that it is within the realm of Turing completeness for my computer to store my WiFi password without me having to administer a specific password manager for it or to open a password wallet every time I want to use it.

Given that this experience is known to be possible, can it be implemented in Plasma? Specifically, is it possible to make the Plasma networkmanager store my WiFi password somewhere other than KWallet, but instead somewhere analogous to where Gnome and Cinnamon store it, such that I don't have to administer a password manager and open its database manually every time I want to use WiFi?

I'm trying to troubleshoot a passwords issue on Ubuntu 20.04 with the KDE Plasma desktop. I keep encountering two different phrases, "KWallet" and "KDE Wallet". I can't untangle what these are enough to figure out how each might be affecting my problem.

I found documentation for "KDE Wallet Manager" on utils.kde.org. It makes no mention of "KWallet".

I found documentation for "KWallet", including "KWallet Manager" on docs.kde.org. It makes a reference to "the System Settings module KDE Wallet" but doesn't give much explanation for how "KWallet" is related to this "KDE Wallet".

In the Plasma Menu, I find entries for both "KWalletManager" and "KDE Wallet". I did not ask to install either of these, so I assume both are built-in to Plasma. When I open each one, I get two completely different dialog windows. This, plus the fact that there are two separate documentation pages, suggests that "KWallet" and "KDE Wallet" are two different things.

However, when I get a dialog modal that refers to the "KWallet" default wallet kdewallet, that modal has the title "KDE Wallet Service" in the taskbar. This, plus the reference to KDE Wallet in the "KWallet" documentation, suggests that there is some relation between "KWallet" and "KDE Wallet".

What is the relation, if any, between "KWallet" and "KDE Wallet"?

I have two systems, A and B. A is Ubuntu 16.04, and B is Ubuntu 20.04. Each has a utility user 'rufus' defined on it. 'rufus' has no login on either system.

I want to understand why 'rufus' has different default umask values between the two systems. On system A (16.04), I get

$ sudo -u rufus sh -c umask
0022

On system B (20.04), I get

$ sudo -u rufus sh -c umask
0002

Running umask for both my own user and for 'root' returns 0022, the expected default, on both systems. Whatever the difference is, it seems to relate to some property specific to 'rufus'.

Here are the things I've considered:

1) system users

Some Linux systems define different default umasks for system users than for regular users.

On system A (16.04), 'rufus' has

$ id rufus
uid=999(rufus) gid=999(rufus) groups=999(rufus)

On system B (20.04), 'rufus' has

$ id rufus
uid=114(rufus) gid=119(rufus) groups=119(rufus)

On both systems, /etc/login.defs has a default umask of 022 and the system user window commented out

UMASK           022
# System accounts
#SYS_UID_MIN              100
#SYS_UID_MAX              999

but /etc/adduser.conf has

FIRST_SYSTEM_UID=100
LAST_SYSTEM_UID=999

indicating that 'rufus' is a system user on both systems (that is, UID > 99 and UID < 1000). So it doesn't seem like this explains the difference in default umask.

2) Login scripts

A user's default umask can be set by login scripts, either global ones like /etc/profile or user-specific ones like ~/.profile. 'rufus' has no login, so these files shouldn't affect what umask returns, because they are never processed.

To be thorough, however, I double-checked the files

/etc/profile
/etc/bash.bashrc
~rufus/.profile

on both systems ('rufus' does have a home folder). None of them set a value for umask. So for a couple of reasons, it doesn't seem like this explains the difference in default umask.

3) /etc/passwd

A user's 'umask' can be set in /etc/passwd.

On System A (16.04):

rufus:x:999:999:,,,:/home/rufus:/usr/sbin/nologin

On System B (20.04):

rufus:x:114:119::/home/rufus:/usr/sbin/nologin

Neither of these set 'umask', so it doesn't seem like this explains the difference in default umask.

4) libpam-umask

I know very little of this, but I understand it can be used to set the umask value for a user. On both systems, libpam-umask is provided by the package libpam-modules. This package installed on both systems, but I have never used it or configured it. On both systems, the config files /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive have no umask setting on the line

session    optional    pam_umask.so

so unless there's somewhere else I need to look, this doesn't seem to explain the difference in default umask.

That's all I can think of. What else can explain the difference in what umask returns for 'rufus' between the two systems?

One question I'd like answered in particular is: When Ubuntu sets a default umask for all system users (UID 100-999), in what file is this set?. This seems to be yet another piece of Linux's signature "secret information".

I've just migrated a system from Ubuntu 16.04 to Ubuntu 20.04. This system runs a set of scripts that create new directories as part of their normal operation. On both systems, the parent/ directory is owned by the same user and has the same permissions (drwxr-xr-x). On the Ubuntu 16.04 system, the script-created subdirectories parent/subdir1/ have the same permissions as parent/, drwxr-xr-x. On the Ubuntu 20.04 system, these subdirectories are instead created with permissions drwxr-x---. The scripts have not changed between the two systems, yet the subdirectories they create have different sets of permissions.

Question 1: Between Ubuntu 16.04 and 20.04, did something change about how default permissions are determined for a newly-created subdirectory?

One potential complication to this question is that the new subdirectories are being created in an external NFS partition. That is, the parent/ directory lives on this NFS partition, so it's literally the same directory for both Ubuntu systems. Both Ubuntu systems are ext4, and they mount this partition via identical systemd unit files.

Question 2: Between Ubuntu 16.04 and 20.04, did something change about how the ext filesystem interacts with a mounted NFS filesystem, particularly for the purposes of creating files and folders?

In addition to these questions, I'm also open to other suggestions about why my new directories have different permissions after the migration.

I have a 16.04 server that I haven't been able to upgrade to 20.04, so I'm considering Extended Security Maintenance for it.

The linked page says that ESM only applies to the 'main' and 'restricted' repositories. In order to know if ESM will work, then, I need to determine what packages are installed that are outside of these repos. The easiest way to do this would be to produce a list of all installed packages along with the repo each belongs to.

Is there a way to do this?

I have an Ubuntu 16.04 installation with a set of snap directories in /snap/. As I upgrade to Ubuntu 20.04, can I expect to be able to copy these snap directories directly into a corresponding /snap/ directory on 20.04 and have them work?

Would I need to do anything else to make it work? Or is this completely unworkable, and I'm going to need to reinstall all the snaps on the new 20.04 system?

I'm trying to use an Ubuntu 18.04 LiveUSB to recover a lost file. I've booted into the LiveUSB. Now, I need to install the 'testdisk' package.

I can run $ sudo apt update and $ sudo apt upgrade with normal output and no errors. However, I can't install packages. If I use apt-cache show to find a package, I always get a "No packages found" error. For instance:

$ apt-cache show testdisk
N: Unable to locate package testdisk
E: No packages found
$ apt-cache show cowsay
N: Unable to locate package cowsay
E: No packages found

If I try to install, I always get results like

$ sudo apt install testdisk
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package testdisk.

I am connected to the network and can browse the Internet normally from the LiveUSB.

This AskUbuntu answer says that I ought to be able to install packages to the LiveUSB. I don't need it to be persistent, I just need testdisk long enough to recover a file.

How can I install packages in an Ubuntu 18.04 LiveUSB?

What Ubuntu 20.04 package gives the Perl module Locale::Language? I've looked on https://packages.ubuntu.com/ but I can't find anything. Web search isn't turning up anything. Not sure I'm searching right.

I'm trying to install Bugzilla 5.0.6 on Ubuntu 20.04. The Bugzilla docs state that I'll need the package 'libtemplate-perl-doc'. This does not exist in the 20.04 repos. A package search shows that it existed for 16.04 but disappeared by 18.04.

I know that sometimes packages get absorbed into other packages or renamed. I can't find any information on what happened to 'libtemplate-perl-doc' between 16.04 and 18.04, however. How do I install whatever 'libtemplate-perl-doc' installed on 16.04 to make Bugzilla work on 20.04?

I have two computers. One, Computer A, runs Ubuntu 18.04. The other, Computer B, runs Ubuntu 20.04.

On Computer A, I have a ~/.bash_aliases file

-rw-r--r--    userA    userA    /home/userA/.bash_aliases

with the following aliases:

alias sudo='sudo '
alias runtest='$HOME/bin/test_script.sh'

The ~/bin/test_script.sh file

-rwxr--r--    userA    userA    /home/userA/bin/test_script.sh

has the contents

#!/bin/bash
echo ~

When I run the alias as both userA and root, I get

$ runtest
/home/userA
$ sudo runtest
/home/userA

(which is what I want, for what it's worth).

On computer B, I'm trying to make an identical setup. The ~/.bash_aliases file

-rw-r--r--    userB    groupB    /home/userB/.bash_aliases

has the same aliases

alias sudo='sudo '
alias runtest='$HOME/bin/test_script.sh'

The script ~/bin/test_script.sh

-rwxr--r--    userB    groupB    /home/userB/bin/test_script.sh

has the exact same contents as on Computer A. On Computer B, however, running the alias as both userA and root gives different results:

$ runtest
/home/userB
$ sudo runtest
/root

Notice that when executing $ sudo runtest, ~ is interpreted as the $HOME folder of the user (userA) on Computer A, but the $HOME folder of root on Computer B. I would like it to return /home/userB, just as it does on Computer A.

Things I've checked:

• I have sourced .bash_aliases on both machines since last editing them.

• /etc/sudoers is identical on both computers, and neither has env_keep set anywhere within /etc/sudoers.d/.

• /etc/pam.conf and /etc/pam.d/sudo are identical on both computers.

• The $PATH values are identical for both users and for both roots, respectively.

For the users:

$ echo $PATH
/home/user(A|B)/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

For root on both Computer A and Computer B:

$ sudo su
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

There must be something different between the two computers, but I've checked everything I know to check. What else could explain the different behavior? Did something change between 18.04 and 20.04 that would affect this?

I recently upgraded 14.04 to 16.04, which includes a transition from Upstart to systemd, and I can't figure out what systemd is doing with my network.

NetworkManager, systemd-networkd, and systemd-resolved are all inactive:

$ systemctl status NetworkManager.service
● NetworkManager.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
$ systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor pre
   Active: inactive (dead)
     Docs: man:systemd-networkd.service(8)
$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor pre
  Drop-In: /lib/systemd/system/systemd-resolved.service.d
           └─resolvconf.conf
   Active: inactive (dead)
     Docs: man:systemd-resolved.service(8)

No trace of either NetworkManager or systemd-networkd are in my journalctl from the last boot:

$ journalctl -u NetworkManager
-- No entries --
$ journalctl -u systemd-networkd
-- No entries --

Nevertheless, the network is fine. The server is connecting to the DB server and its webapps are internet-accessible as normal. How do I determine what network configuration manager I'm using? I have to be using one, right?

Edit Here are the contents of /etc/network/interfaces:

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp
#iface eth0 inet static
#   address x.x.x.x
#   netmask x.x.x.x
#   network x.x.x.x
#   broadcast x.x.x.x
#   gateway x.x.x.x
#   # dns-* options are implemented by the resolvconf package, if installed
#   dns-nameservers x.x.x.x y.y.y.y
#   dns-search x.x.x.x y.y.y.y

I have an Ubuntu 14.04 installation that I'm trying to do-release-upgrade to 16.04. When I try, I get the error

Not enough free disk space

The upgrade has aborted. The upgrade needs a total of 76.2 M free space on disk '/boot'. Please free at least an additional 58.8 M of disk space on '/boot'.

apt-get autoremove and apt-get clean did not remove any files. From web searching, it looks like the standard solution to this problem is provided by Alaa Ali's answer to this AskUbuntu question, which is to apt-get purge unused kernel images. Following this advice, I removed 41 kernel images. This did not free up any space on /boot, however.

Before apt-get purgeing the 41 images, the output of df -h was

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G  4.0K  3.9G   1% /dev
tmpfs           785M 1012K  784M   1% /run
/dev/sda2        47G   28G   17G  62% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            3.9G   88K  3.9G   1% /run/shm
none            100M   20K  100M   1% /run/user
/dev/sdb1       459G  121G  338G  27% /data
/dev/sda1       114M   89M   17M  85% /boot
/dev/sda4       404G   90G  295G  24% /home

After purging, the output of df -h is

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G  4.0K  3.9G   1% /dev
tmpfs           785M 1012K  784M   1% /run
/dev/sda2        47G   28G   17G  62% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            3.9G   88K  3.9G   1% /run/shm
none            100M   20K  100M   1% /run/user
/dev/sdb1       459G  121G  338G  27% /data
/dev/sda1       114M   89M   17M  85% /boot
/dev/sda4       404G   90G  295G  24% /home

Nothing has changed. I still get the same error when I try to do-release-upgrade.

Comparing the output of dpkg -l | grep linux-image before and after purging images confirms that the kernel images were removed.

Every answer on this that I've found has boiled down to autoremove, clean, or purging kernel images, and none of those have worked. What do I do now?

Edit: Additional Information

Here is the output of dpkg -l | grep linux-image before purging:

$ dpkg -l | grep linux-image
rc  linux-image-2.6.32-21-generic            2.6.32-21.32         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-23-generic            2.6.32-23.37         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-24-generic            2.6.32-24.43         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-25-generic            2.6.32-25.45         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-26-generic            2.6.32-26.48         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-27-generic            2.6.32-27.49         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-29-generic            2.6.32-29.58         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-30-generic            2.6.32-30.59         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-31-generic            2.6.32-31.61         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-32-generic            2.6.32-32.62         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-34-generic            2.6.32-34.77         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-37-generic            2.6.32-37.81         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-38-generic            2.6.32-38.83         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-39-generic            2.6.32-39.86         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-40-generic            2.6.32-40.87         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-41-generic            2.6.32-41.94         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-44-generic            2.6.32-44.98         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-3.13.0-107-generic           3.13.0-107.154       amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
rc  linux-image-3.13.0-116-generic           3.13.0-116.163       amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
rc  linux-image-3.13.0-157-generic           3.13.0-157.207       amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
ii  linux-image-3.13.0-164-generic           3.13.0-164.214       amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
ii  linux-image-3.13.0-170-generic           3.13.0-170.220       amd64        Signed kernel image generic
rc  linux-image-3.13.0-66-generic            3.13.0-66.108        amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-32-generic             3.2.0-32.51          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-33-generic             3.2.0-33.52          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-34-generic             3.2.0-34.53          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-35-generic             3.2.0-35.55          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-36-generic             3.2.0-36.57          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-37-generic             3.2.0-37.58          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-38-generic             3.2.0-38.61          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-39-generic             3.2.0-39.62          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-40-generic             3.2.0-40.64          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-41-generic             3.2.0-41.66          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-45-generic             3.2.0-45.70          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-48-generic             3.2.0-48.74          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-49-generic             3.2.0-49.75          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-53-generic             3.2.0-53.81          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-58-generic             3.2.0-58.88          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-88-generic             3.2.0-88.126         amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-89-generic             3.2.0-89.127         amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-92-generic             3.2.0-92.131         amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-extra-3.13.0-107-generic     3.13.0-107.154       amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
rc  linux-image-extra-3.13.0-116-generic     3.13.0-116.163       amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
rc  linux-image-extra-3.13.0-157-generic     3.13.0-157.207       amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
ii  linux-image-extra-3.13.0-164-generic     3.13.0-164.214       amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
rc  linux-image-extra-3.13.0-66-generic      3.13.0-66.108        amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
ii  linux-image-generic                      3.13.0.170.181       amd64        Generic Linux kernel image

Here are the commands I used to purge images:

$ sudo apt-get purge linux-image-2.6.32-{21,23,24,25,26,27,29,30,31,32,34,37,38,39,40,41,44}-generic
$ sudo apt-get purge linux-image-3.2.0-{32,33,34,35,36,37,38,39,40,41,45,48,49,53,58,88,89,92}-generic
$ sudo apt-get purge linux-image-3.13.0-107-generic
$ sudo apt-get purge linux-image-3.13.0-116-generic 
$ sudo apt-get purge linux-image-extra-3.13.0-107-generic
$ sudo apt-get purge linux-image-extra-3.13.0-116-generic
$ sudo apt-get purge linux-image-3.13.0-66-generic
$ sudo apt-get purge linux-image-extra-3.13.0-66-generic

Here is the output of dpkg -l | grep linux-image after running the above purge commands:

$ dpkg -l | grep linux-image
rc  linux-image-3.13.0-157-generic           3.13.0-157.207   amd64        Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii  linux-image-3.13.0-164-generic           3.13.0-164.214   amd64        Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii  linux-image-3.13.0-170-generic           3.13.0-170.220   amd64        Signed kernel image generic
rc  linux-image-extra-3.13.0-157-generic     3.13.0-157.207   amd64        Linux kernel extra modules for version 3.13.0 on 64 bit     x86 SMP
ii  linux-image-extra-3.13.0-164-generic     3.13.0-164.214   amd64        Linux kernel extra modules for version 3.13.0 on 64 bit     x86 SMP
ii  linux-image-generic                      3.13.0.170.181   amd64        Generic Linux kernel image

Here are the current contents of /boot:

$ ls -l /boot
total 81817
-rw-r--r-- 1 root root  1169147 Dec  5  2018 abi-3.13.0-164-generic
-rw-r--r-- 1 root root   166221 Dec  5  2018 config-3.13.0-164-generic
-rw-r--r-- 1 root root   166221 May  9 09:35 config-3.13.0-170-generic
drwxr-xr-x 5 root root     1024 Jul 19 14:43 grub
-rw-r--r-- 1 root root 31803728 Jul  9 13:28 initrd.img-3.13.0-164-generic
-rw-r--r-- 1 root root 31804631 Jul  9 13:28 initrd.img-3.13.0-170-generic
drwx------ 2 root root    12288 Jul 22  2010 lost+found
-rw-r--r-- 1 root root      254 Dec  5  2018 retpoline-3.13.0-164-generic
-rw------- 1 root root  3417774 Dec  5  2018 System.map-3.13.0-164-generic
-rw------- 1 root root  3418683 May  9 09:35 System.map-3.13.0-170-generic
-rw------- 1 root root  5905712 Dec  5  2018 vmlinuz-3.13.0-164-generic
-rw------- 1 root root  5909496 May 14 15:03 vmlinuz-3.13.0-170-generic

Here is uname -r:

$ uname -r
3.13.0-170-generic

Edit: Summary

I've managed to get /boot to have 58M available by removing one more kernel image. do-release-upgrade needs 77M, so I still need around ~20M.

The remaining kernel image (the one that I'm currently using) is 31M. Beyond that, everything else in /boot totals ~15.9M. There doesn't seem to be a way to free enough space to run do-release-upgrade without deleting my current kernel image. Does anyone see anything I'm missing?

Data to tally up disk space:

$ sudo du -h -d 1 /boot/
12K /boot/lost+found
6.7M    /boot/grub
47M /boot/
$ ls -lh /boot
total 40M
-rw-r--r-- 1 root root 163K May  9 09:35 config-3.13.0-170-generic
drwxr-xr-x 5 root root 1.0K Jul 23 13:41 grub
-rw-r--r-- 1 root root  31M Jul  9 13:28 initrd.img-3.13.0-170-generic
drwx------ 2 root root  12K Jul 22  2010 lost+found
-rw------- 1 root root 3.3M May  9 09:35 System.map-3.13.0-170-generic
-rw------- 1 root root 5.7M May 14 15:03 vmlinuz-3.13.0-170-generic

Edit: Resolution

It seems clear that I'm not capable of resolving this issue. Thank you to everyone who kindly offered information and advice!

I have a data server and two VMs. The first VM, clone14, runs Ubuntu 14.04. The second VM, clone16, was cloned from clone14 and then upgraded to Ubuntu 16.04.

Both VMs have the exact same /etc/fstab file that includes a line mounting a directory from the data server, whose IP address is 99.99.99.99 in this example:

99.99.99.99:/data/NFS/primary            /disks          nfs     rw,soft,intr,actimeo=60 0 0

Everything always works as intended on clone14, but clone16 will not consistently mount the remote directory. Sometimes it will partially mount it, with only some of the subdirectories and files available within the clone16:/disks/ mountpoint.

The big change from 14.04 to 16.04 is Systemd instead of Upstart as the init system. Systemd is supposed to accept fstab entries without a problem, but something is clearly messing up here.

I've searched for "update fstab for systemd" and related terms, but I haven't found anything I can interpret as useful. This post contains almost my entire knowledge of fstab and mounting in Linux, so please use small words when responding. As always, context and explanation in your comments and answers are valuable to me and others who find this page in the future.

How do I figure out what's wrong and correct it?

I'd like to find what package is installed on Ubuntu 14.04 (server) that gives access to the javac command. The RHEL line of distros has yum provides for this, but there doesn't seem to be anything similar for the Debian family.

This AskUbuntu question suggests using dpkg -S and apt-file, but neither of these work:

$ sudo dpkg -S `which javac`
dpkg-query: no path found matching pattern /usr/bin/javac

apt-file search appears to work at first:

$ apt-file search javac
javacc: /usr/bin/javacc

Except that apt-cache policy shows that this package isn't even installed, so it's obviously not the package that provides javac.

$ apt-cache policy javacc
javacc:
  Installed: (none)
  Candidate: 5.0-5

How can I find out what package provides the javac command?

I previously tried to do-release-upgrade a VM running Ubuntu 14.04 server. The upgrade process kept halting to ask me what to do about config files that were not as expected, which I didn't know how to answer, because why would I. While spending several hours researching each file in turn to try to figure what to do with each one, the SSH connection (or something) dropped, and the upgrade halted as botched. I had to restore the VM from backup.

I'd like to try again. Is there any way to "dry run" do-release-upgrade to find out in advance what questions it's going to ask me so I can be prepared this time? There's nothing in the man page about a dry run, and web searches turn up nothing.

I've just installed Kubuntu 16.04 on a Lenovo T560 Thinkpad. The wireless connection works poorly - on startup, it won't search for wireless networks (there's also no UI element available to prompt a search for networks, but that's a different complaint). And when a wireless network is found, it routinely drops the connection.

Basically, I have to keep a terminal open to run $ sudo service network-manager restart almost constantly. None of the other devices that use the network have a similar problem.

Is this likely a driver issue? The wireless device is

product: Wireless 8260
vendor: Intel Corporation

and I'm using the iwlwifi driver.

Edit: here's the output of dmesg | grep iwl:

[ 4.853206] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-19.ucode failed with error -2 [ 4.853222] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-18.ucode failed with error -2 [ 4.853231] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-17.ucode failed with error -2 [ 4.853602] iwlwifi 0000:04:00.0: Unsupported splx structure [ 4.864965] iwlwifi 0000:04:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm [ 4.904463] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 [ 4.904778] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 4.905880] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 5.050828] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' [ 5.054589] iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0 [ 5.399303] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 5.400038] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 5.540881] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 5.541309] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 1668.562182] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 1668.563595] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 1668.702349] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 1668.702959] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 2082.791322] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 2082.792716] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 2082.931669] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 2082.932277] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 2986.102813] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 2986.103733] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 2986.241431] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 2986.241948] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 3183.242126] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 3183.243588] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 3183.381723] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 3183.382147] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 4635.249047] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 4635.250403] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 4635.388702] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 4635.389223] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 7071.802648] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 7071.804023] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 7071.941558] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled [ 7071.942093] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled