apt update/upgrade failed

sneakyimp · 08-19-2017, 01:42 PM

I'm running an Ubuntu 16 development server (which eventually be a production server) on Rackspace as a virtual machine. I recently was informed on login that some packages could be updated. I was able to run apt update but apt upgrade broke down with a problem. Here's the end of the output:

Code:

...blah blah blah...
Setting up update-manager-core (1:16.04.8) ...
Processing triggers for libc-bin (2.23-0ubuntu9) ...
Processing triggers for initramfs-tools (0.122ubuntu8.8) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-92-generic
cryptsetup: WARNING: failed to detect canonical device of /dev/xvda1
cryptsetup: WARNING: could not determine root device from /etc/fstab
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.

Can anyone tell me what is failing and how I might fix it? I've seen problems with virtual machines in the past where device names change and am not at all sure how to deal with this.

Habitual · 08-19-2017, 03:29 PM

Look at /etc/fstab?
Mentions cryptsetup That's a keyword. Does the host utilize what appears to be disk encryption?

Code:

apt-get install -f

is a repair suggestion I've read.

You are "running a server"?

I don't fix computers, sorry. "blah blah blah" doesn't work for me.

I found this The cryptsetup part of update-initramfs must correctly take into account PARTLABEL inside /etc/fstab, so

examine /etc/fstab critically for PARTLABEL (is that this "device name change" you mentioned?)

Good Luck.

"Fix" is restore /etc/fstab from backup.

dejank · 08-19-2017, 03:47 PM

It is just warning, because you have /etc/crypttab and it is empty. My guess is that you have cryptsetup installed, but you still did not use it. Search the net with that warning, some bug reports should show up. From what I know, it is harmless. Did you notice anything not working as it should, that warning aside?

sneakyimp · 08-19-2017, 04:14 PM

To clarify, this "server" is actually a virtual machine (i.e., a "Cloud Server" running on Rackspace.com). It was allocated/instantiated by a co-worker via their website, which has a browser-hosted control panel interface.

Quote:

Originally Posted by Habitual

Look at /etc/fstab?
Mentions cryptsetup That's a keyword. Does the host utilize what appears to be disk encryption?

We have never made any attempt to encrypt the file system, if that's what you mean.

Quote:

Originally Posted by Habitual

Code:

apt-get install -f

is a repair suggestion I've read.

Some googling reveals that this means "attempt to correct a system with broken dependencies in place." I have tried running this:

Code:

sudo apt-get install -f

and the result:

Code:

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded

.
Seems to me I would need to run apt-get install -f <package-name> but I've no idea which package to specify.

Quote:

Originally Posted by Habitual

You are "running a server"?

As clarified above, I'm talking about a virtual machine running on Rackspace's system.

Quote:

Originally Posted by Habitual

I don't fix computers, sorry. "blah blah blah" doesn't work for me.

I apologize if this is confusing. I redacted the lengthy output of the command in the interest of focusing on the problem. Most of the other output seemed fine so it didn't seem relevant.

Quote:

Originally Posted by Habitual

I found this The cryptsetup part of update-initramfs must correctly take into account PARTLABEL inside /etc/fstab, so

examine /etc/fstab critically for PARTLABEL (is that this "device name change" you mentioned?)

I have only rarely dealt with an fstab file and then only under close supervision. It's been my experience with virtual machines that complaints sometimes arise about the 'canonical' device being found or something. This seems to happen because the host (a hypervisor I presume) apparently (and inexplicably) renames the default device to something else under certain conditions and certain configuration values end up complaining about it. This is currently the contents of /etc/fstab:

Code:

$ cat /etc/fstab
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
/dev/xvda1  /               ext4    errors=remount-ro,noatime,barrier=0 0       1

#/dev/xvdc1 none            swap    sw              0       0

/dev/xvdb1 /var/www/html/cdn1 ext3 defaults,noatime,_netdev,nofail 0 2
/dev/xvdc1 /var/www/vlnt_user_upload ext3 defaults,noatime,_netdev,nofail 0 2

df says this:

Code:

~$ sudo df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             2011096       0   2011096   0% /dev
tmpfs             404076    5732    398344   2% /run
/dev/xvda1      81254044 3998536  77239124   5% /
tmpfs            2020376       0   2020376   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs            2020376       0   2020376   0% /sys/fs/cgroup
/dev/xvdb1      77277192   53144  73291940   1% /var/www/html/cdn1
/dev/xvdc1      77277192  578660  72766424   1% /var/www/user_upload
tmpfs             404528       0    404528   0% /run/user/1002

This contradicts my hypothesis that the hypervisor was changing device names. Oh well.

Quote:

Originally Posted by Habitual

Good Luck.

Thanks.

Quote:

Originally Posted by Habitual

"Fix" is restore /etc/fstab from backup.

I've never modified this file and, having done a sudo find / -name "*fstab*", it would appear there are no backup files from which to restore.

I've been googling these errors. No epihanies yet.

sneakyimp · 08-19-2017, 04:18 PM

Quote:

Originally Posted by dejank

It is just warning, because you have /etc/crypttab and it is empty. My guess is that you have cryptsetup installed, but you still did not use it. Search the net with that warning, some bug reports should show up. From what I know, it is harmless. Did you notice anything not working as it should, that warning aside?

Yes, that file is empty:

Code:

$ cat /etc/crypttab
# <target name>	<source device>		<key file>	<options>

And yes it would appear that cryptsetup is installed (not something I did):

Code:

$ sudo dpkg -l | grep cryptsetup
ii  cryptsetup                       2:1.6.6-5ubuntu2                           amd64        disk encryption support - startup scripts
ii  cryptsetup-bin                   2:1.6.6-5ubuntu2                           amd64        disk encryption support - command line tools
ii  libcryptsetup4:amd64             2:1.6.6-5ubuntu2                           amd64        disk encryption support - shared library

This server was instantiated from the available/orthodox Rackspace server images. I'm wondering if:
a) ubuntu comes with this package
b) Rackspace added this package to their base server image to support disk encryption if customers want it
c) I'm about to be git by some ransomware worm or something.

From what I can tell, the apt update worked just fine and all packages were updated. That said, this is not a critical issue, but I would like to understand what is happening.

dejank · 08-19-2017, 05:11 PM

Well, as I've said, it is looking for something that it expects to find where it does not exist. And it reports it as a warning. So, basically, all is well. And that warning can be considered to be bug, which I believe is already open. Think that you will find it if you search net with those warning message.