10

After upgrading from Lubuntu 14.04 to 16.04, the boot takes much longer time. Running dmesg, I find one task takes a significantly longer time:

cgroup: new mount options do not match the existing superblock, will be ignored

Searching on internet, it seems to be a fstab issue. It happens to those who adjust the partitions. But the thing is that I never adjust the partitions during or after the upgrade. Also the result of blkid matches the content of fstab.

Output of sudo blkid

/dev/sda1: UUID="40F4AB0BF4AB01F0" TYPE="ntfs" PARTUUID="4de78bef-01"  
/dev/sda2: UUID="909fbd0b-69c1-45a3-b7fc-9bbe122fa7fe" TYPE="ext4" PARTUUID="4de78bef-02"  
/dev/sda3: UUID="a5e6b8bc-14b8-4032-8e01-9dbd8a7893a5" TYPE="ext4" PARTUUID="4de78bef-03"  
/dev/sda4: UUID="0471ceb6-79cd-49ad-a708-f9045d092873" TYPE="swap" PARTUUID="4de78bef-04"

Output of cat /etc/fstab

UUID=909fbd0b-69c1-45a3-b7fc-9bbe122fa7fe /               ext4    errors=remount-ro 0       1  
UUID=a5e6b8bc-14b8-4032-8e01-9dbd8a7893a5 /home           ext4    defaults        0       2  
UUID=0471ceb6-79cd-49ad-a708-f9045d092873 none            swap    sw              0       0

Can anybody say why it's giving this error message?

Improve this question

4 Answers 4

Reset to default
4

I had exactly the same issue, but after I installed a second Linux and configured it to share the swap partition with Ubuntu. Even after I adjusted the /etc/fstab file, Ubuntu would need 2 minutes to show the login screen. The command dmesg displayed the message cgroup: new mount options do not match the existing superblock, will be ignored.

In my fstab I found the following entry: #/dev/mapper/cryptswap1 none swap sw 0 0, and that was a hint that there used to exist a cryptswap partition that I probably set up when I installed Ubuntu (I do not remember now).
However, to get rid of the remains of that partition I did the following:

1. sudo swapoff
2. sudo cryptsetup remove /dev/mapper/cryptswap1 (In my case, this file was already deleted)
3. sudo vim /etc/crypttab Here, I found an entry that referred to the non-existing cryptswap. I deleted it.
4. sudo /sbin/mkswap /dev/sda4 (In your case, swap is on /dev/sda4)
5. sudo swapon /dev/sda4.

Afterwards, my Ubuntu started normally again. I hope that helps.

Improve this answer
4

My /etc/fstab somehow got a logical volume map (LVM) disk added to it. I don't know how because this is something I have never used on this machine.

/dev/mapper/vg_phoebus-lv_swap none swap sw 0 0

I used:

sudo dmsetup -v table /dev/mapper/vg_phoebus-lv_swap

and:

ls -lha /dev/mapper

to confirm there was no LVM volumes and then I removed that line from /etc/fstab.

There is a handy way to look at what's taking time to boot:

systemd-analyze blame

Mostly unrelated but through I would add it here. I also had a problem with powerd on shutdown see this bug report: powerd takes eternity to boot on pc

I disabled it as suggested:

sudo systemctl disable powerd.service
Improve this answer
2

I had the same problem after updating to 16.04. I found this answer to be very helpful and it solved my problem:

https://askubuntu.com/a/614660/319782

Long story short list your UUID's

sudo blkid

Check for UUID mismatches in /etc/fstab

cat /etc/fstab

fix mismatches if they exist

sudo emacs /etc/fstab

then reboot

Improve this answer
7
  • As shown in the original post, the result of blkid matches exactly what's inside fstab.
    – Georgie Porgie
    Aug 26, 2016 at 16:09
  • I only see three drives in the fstab but 4 in the blkid.
    – atomSmasher
    Aug 27, 2016 at 3:19
  • /dev/sda1 is the windows partition and I guess it's never added to fstab, even under lubuntu 14.04
    – Georgie Porgie
    Aug 28, 2016 at 0:07
  • 2
    How do you fix mismatches if they exist? What am I supposed to do here?
    – t q
    Nov 6, 2016 at 15:09
  • Downvoted this answer I'm afraid, as it's not offering any actual help AFAIKT.
    – TommyPeanuts
    Sep 16, 2018 at 8:52
1

I had the problem (in EC2) because I changed one of the drives (the boot drive) from a solid state drive (SSD) and to a magnetic drive. I didn't update the /etc/fstab, which showed the mount option as

defaults,discard

It turns out that the 'discard' option is unique to SSD drives* so doesn't apply to magnetic drives. I removed the discard option and the message went away.

*http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .