1

I've got a problem with XUbuntu 19.04. On every boot, it runs a file system check that times out after 1:30 (killed by systemd) before the boot process continues.

It all started after I installed Debian 10.0 alongside (removed after only one attempt to boot, as it didn't recognize my video).

The tricky part:

The UUID that it's trying to check does not exist.

So I can't simply do a fsck on that drive once it's finished booting. There is no "trigger file" for "all" file system checks at the root.

I cannot do "tune2fs -l <...>" or "tune2fs -c" on the drive because the drive (the UUID) does not exist.

I already restored the partition to an image from before the issues began - and the file system checks continued. So it seems to be the partitions (why and how and what's changed?) and not Ubuntu, but... I also have Fedora installed on this computer and it boots without any strange file system checks just fine.

I also tried rebooting into single user mode - the drive's UUID does not exist there either.

A photo of the file system check: https://imgur.com/BMc76bU

How can I troubleshoot this? Obviously, I'd like the system to stop trying to fsck a non-existent drive.

EDIT:

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda4 during installation
UUID=6d09fece-2e15-43ab-bf90-0ced66eb69df /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=9309-1800  /boot/efi       vfat    umask=0077      0       1
# /home was on /dev/sdb3 during installation
#UUID=d516763d-bc3e-4dda-ab61-aa562dfaba18 /home           ext4    defaults        0       2
UUID=0433c6e7-07f7-4f2b-9da1-6d0756d79eba /home           f2fs    defaults        0       2
# swap was on /dev/sda5 during installation
UUID=272f11a2-5157-432e-8a54-84758de52ef1 none            swap    sw              0       0

# Western Digital RE

# /mnt/archives
UUID=41b0e3d1-2f97-4d6e-916c-7286abb7cfae       /mnt/archives   ext4    defaults        0 2

# /mnt/documents
UUID=14EE-1640  /mnt/documents  vfat    uid=kman,gid=kman,iocharset=utf8,codepage=866 0 2

# Toshiba 

# /mnt/passport
UUID=b74afcc2-5e68-4922-ae6a-f745d6cfeb12   /mnt/passport   ext4    defaults,noauto 0 2


sudo lsblk -f | grep -v loop
NAME        FSTYPE LABEL         UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                  
├─sda1      vfat                 9309-1800                             993.9M     3% /boot/efi
├─sda2      ext4   Frida         b60e174a-488e-46f5-b1f0-f57badcc9182                
├─sda4      ext4   Xandra        6d09fece-2e15-43ab-bf90-0ced66eb69df   47.1G    19% /
├─sda5      swap                 ec8b5ba8-b727-4d2b-b640-916109098845                
└─sda6      ext4   Android files 2af1d4f1-0da6-44e1-baf1-ab343080829e                
sdb                                                                                  
├─sdb1      vfat                 58A2-0240                                           
├─sdb2      ntfs   WinSystem     01D4A449338F8A80                                    
├─sdb3      ntfs                 01D4A449350624F0                                    
└─sdb4      ntfs   WinData       01D4A449F36DE360                                    
sdc                                                                                  
├─sdc1      ext4   Passport      b74afcc2-5e68-4922-ae6a-f745d6cfeb12                
└─sdc2      ntfs   Tanya         3D1341DE1547D4CB                                    
sdd                                                                                  
├─sdd1      vfat   DOCUMENTS     14EE-1640                              79.5G    20% /mnt/documents
├─sdd2      ext4   Archives      41b0e3d1-2f97-4d6e-916c-7286abb7cfae  392.8G    28% /mnt/archives
└─sdd3      ntfs   WinArchive    01D4A4BE55414770                                    
sde                                                                                  
sr0                                                                                  
nvme0n1                                                                              
├─nvme0n1p1 ext4   FHome         92e607fa-dda6-449f-9675-f1155f590e8e                
└─nvme0n1p3 f2fs   XHome         0433c6e7-07f7-4f2b-9da1-6d0756d79eba  174.5G     9% /home
Improve this question
6
  • 3
    Probably the UUID of your swap partition has been changed. Please add output of cat /etc/fstab and lsblk -f | grep -v loop to your question. – mook765 Jul 7 '19 at 12:13
  • That's it - the ubiquitous swap partition! UUID=272f11a2-5157-432e-8a54-84758de52ef1 Debian did format it as part of installation procedure. Not sure why Fedora wasn't confused, going to look into that next. – Kostya Vasilyev Jul 7 '19 at 13:11
  • @mook765 please add a proper "answer" (not comment) so I can mark it as "accepted" and you can receive points for it. – Kostya Vasilyev Jul 7 '19 at 13:12
  • I've reset the swap partition's UUID to what it was before with "mkswap -U <...>" and now everything is back to normal. Fedora wasn't affected - it doesn't have its swap partition in fstab, probably just does "swapon --all". – Kostya Vasilyev Jul 7 '19 at 13:30
  • If you changed the UUID of the swap partition to the former value, Debian will complain about the same thing, at least in one of the systems you should adapt fstab. – mook765 Jul 7 '19 at 13:32
0

As it turned out in comments, the installation of Debian formatted an already existing swap-partition and so changed it's UUID.

To find out what's going on the contents of /etc/fstab and the output of lsblk -f | grep -v loop should be viewed.

Both systems, Debian and Xubuntu use the same swap partition, both systems have a fstab-line regarding the swap partition. You have to use the same UUID in thisfstab-line in both systems. So if you changed the UUID back to the former value, you have to adapt /etc/fstab in your Debian installation, otherwise Debian would be affected in the same way during boot.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.