Can't boot without commenting drive in /etc/fstab/

English Install/Boot/Login
#1

I have my drive partitioned in two sets, the first the standard partition with /home / /boot etc. (see fdisk output), and the second partition is a just for media. I transferred a sizable video file (about 11GB) from /home (first partition) to /Media (second partition) everything went fine except when I rebooted the boot failed, it asked to login as root to debug (see pic). I also had a slightly different error asking me to use:

systemctl reboot

Which did not fix my issue. I googled around and found that commenting certain drives out of /etc/fstab/ would fix the issue, it did for me, however now I cannot mount the drive due to it being absent from /etc/fstab/, uncommenting it breaks boot again.

Fstab output:

Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3b31ea67

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048  58593279  58591232    28G 83 Linux
/dev/sda2        58595326 312580095 253984770 121.1G  5 Extended
/dev/sda5        58595328  66881535   8286208     4G 82 Linux swap / Solaris
/dev/sda6        66883584 145006591  78123008  37.3G 83 Linux
/dev/sda7       145008640 312580095 167571456  79.9G 83 Linux

Link to image since it’s too large to display: https://i.imgur.com/NqmOt00.jpg

#2

What does /etc/fstab contain?

#3

From your description I cannot figure out what your setup is.
Are you using just one or two (or more) drives?
Which partitions are used as /root and /home and which is to be mounted as /Media?

The error shown in the linked image refers to USB 7, port 2 not being enumerated for whatever reason: is this an USB drive? Is it the drive to be mounted as /Media?
Please show

cat /etc/fstab

and explain how it relates to the fdisk output in case that is not obvious (to us, I understand that it is pretty obvious to you :wink: )

Apparently something is wrong with what is connected to USB7:2 and if that is a drive mentioned in fstab the system waits endlessly for it to show up before completing the boot process.
Commenting it out (if that really is an USB disk) allows booting to finish.
Generally speaking, you can mount anything without it being mentioned in fstab, it only doesn’t get mounted automatically.
Try the “mount” command (“man mount” for details) or your file manager.
But if something was corrupt on that disk or if the connection cannot be set up for whatever reason, you cannot mount until you solve that problem.

#4

It’s one drive that is partitioned, here’s fstab which I intended to include in the OP but omitted.


UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /                       btrfs  defaults                      0  0
UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /var                    btrfs  subvol=/@/var                 0  0
UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /root                   btrfs  subvol=/@/root                0  0
UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=5d75f431-14db-47c3-bd62-a25190ec3e0b  /home                   ext4   data=ordered,acl,user_xattr   0  2
UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=ddcfcfec-ae67-4a5b-b50e-838f0cb8793c  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
#UUID=36e0c062-6418-4472-a8a6-0ca7ed743f1d  /run/media/user/Media   ext4   defaults             0  0

I included fdisk just to show how the partitions were setup, I don’t know what USB has to do with it, I don’t remember editing something of the sort. The only thing in /etc/fstab that I edited was adding the last line, and it has had no issues until now. Now if it were a corrupt file how would I go about solving it since I can’t seem to mount the drive even with *mount.

*Here’s something I noticed, I tried mounting it as /dev/sda7 (as you would a USB) and it said:

>Can’t find in /etc/fstab

I tried mounting it as /run/media/user/Media (gave the same error) and I noticed that media is not present in */run *directory, that is /run/media/user/Media does not exist. This might probably be the problem, but what I don’t understand is how it got deleted, since in my memory near everything in /run is owned by root?

And if this really is the core issue, would just creating /media/user/Media again solve the problem, or even changing the path? Or are my files deleted?

Thanks.

#5

Quick follow up, I tried mounting the drive via GUI (Dolphin) and it displayed this message which seems to be more verbose and useful.

https://i.imgur.com/hwoghmL.png

#6

To begin with, you should not mount file systems in /run/media. That is for mounting spontanious added devices at run time for the desktop user.

Better to choose a place either:

  • when this mount is for a particular user, the a directory soemewhere inside that users home directory (like /home/<username>/Media or whatever name the user likes);
  • when this mount is general for all users in the system, somewhere under /. In fact /mnt is specially for these cases, thus e.g. /mnt/Media would be nice.

For the first case above, many people prefer to mount at e.g. /mnt/media and then let the user make a symbolic link in his home e.g.

ln -s /mnt/media Media

((the above assumeing that his working directory is his home direc tory at the moment of executing this).

But that is a sidestep. Back to your problem:

To find out what partition your fstab points at, please do

ls -l /dev/disk/by-uuid/*36e0c062-6418-4472-a8a6-0ca7ed743f1d*
#7

I don’t remember setting the partition in /run/media, that partition is there since my previous debian install, I believe it was added there automatically, I noticed it was different from debian’s /mnt, but I assumed openSUSE differed.

I get


lrwxrwxrwx 1 root root 10 Jul 17 10:51 /dev/disk/by-uuid/36e0c062-6418-4472-a8a6-0ca7ed743f1d -> ../../sda7

When executing the command you suggested.

#8

Try running top in an Xterm, then plug in the USB drive. Does it report connection as sdb, or as something else, like sdf or sdg, like some of mine do, depending into which port it’s plugged?

Try changing

#UUID=36e0c062-6418-4472-a8a6-0ca7ed743f1d /run/media/user/Media ext4 defaults 0 0

to

UUID=36e0c062-6418-4472-a8a6-0ca7ed743f1d /home/xtrnlDATA ext4 nofail 0 0

If successful, do as HCVV wrote:

mkdir /home/xtrnlDATA; mkdir /home/user/xtrnlData; ln -s /home/xtrnlDATA /home/xtrnlData

UUIDs are easy for computers to use, but not for people. So, instead of above, or as a learning exercise, use a unique volume label you create and can remember for each partition on the USB disk. Create one if one doesn’t already exist, (following examples presume the USB disk is sdb and contains only a single partition):

tune2fs -L xtrnlData /dev/sdb1

or (using same sdb/single assumption), do:

e2label /dev/sdb1 xtrnlDATA

or use YaST2 partitioner. Then use this in fstab

LABEL=xtrnlData /home/xtrnlData ext4 nofail 0 0

Various means exist to discover if an EXT4 filesystem has a label, e.g.:

blkid /dev/sdb1

or

e2label /dev/sdb1
#9

Thus indeed that UUID refers to /dev/sda7.

Now we have to find out why you have problems mounting it.

Try

mount -t ext4 /dev/sda7 /mnt

and show that here.

In the mean time you could try to explain a bit better about your first post, because (I am sorry to say) in contains a lot of not understandable and unexplained items.
E.g. you say “I transferred a sizable video file (about 11GB) from /home (first partition) to /Media (second partition)…” Now, apart from your misnomers about “first” and “second” partition, how did you transfer?
Please remember that using words that have only a general meaning do not inform others about the ways you exactly did things.

#10

The ext4 filesystem on /dev/sda7 doesn’t seem to be in good shape (“can’t read superblock on /dev/sda7”).
Try running the following as superuser (root) to see what is going on (/dev/sda7 should be unmounted for meaningful results):

e2fsck -f -n /dev/sda7
#11

There is no USB drive apparently (see post #4). The USB error mentioned in the linked photo seems unrelated to the issue at hand.

#12

That is why I asked him:

  • to mount it so we can see an real error message instead of what some GUI program made of it (and i could not read the smallprint);
  • asked him how he “transferred”, or maybe destroyed.
#13

observations,

on this laptop the following works,

output of cmd,

tosh-sm60<2018Jul17@16:51><~/Updates/15.0/inxi>... lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   93G  0 disk 
├─sda1   8:1    0    2G  0 part [SWAP]
├─sda2   8:2    0   30G  0 part /
└─sda3   8:3    0   61G  0 part /home
sr0     11:0    1 1024M  0 rom  
tosh-sm60<2018Jul17@16:53><~/Updates/15.0/inxi>...

so fstab changed as follows, original entries #'ed,

/dev/sda2        /      ext4  acl,user_xattr  1  1
/dev/sda3        /home  xfs   defaults        1  2
/dev/sda1        swap   swap  defaults        0  0

# /dev/disk/by-path/pci-0000:00:1f.2-ata-1-part2  /      ext4  acl,user_xattr  1  1
# UUID=e7fcbd31-a552-4bc1-85bb-3cc1a0353c45       /home  xfs   defaults        1  2
# UUID=4e86c8ff-4a58-4234-a70f-acc6412c4d54       swap   swap  defaults        0  0

if uuid or path parameters are to be used try,

tosh-sm60<2018Jul17@17:01></etc>... ls /dev/disk/by-path/
pci-0000:00:1f.2-ata-1  pci-0000:00:1f.2-ata-1-part1  pci-0000:00:1f.2-ata-1-part2  pci-0000:00:1f.2-ata-1-part3  pci-0000:00:1f.2-ata-2
tosh-sm60<2018Jul17@17:02></etc>... ls /dev/disk/by-uuid/
0d694a37-9245-4ccd-9314-90e948e79657  4e86c8ff-4a58-4234-a70f-acc6412c4d54  e7fcbd31-a552-4bc1-85bb-3cc1a0353c45
tosh-sm60<2018Jul17@17:02></etc>...

then make the appropriate changes in the fstab file

#14

ps

if more info is required use the -l parameter, eg,

tosh-sm60<2018Jul17@17:19><~/Downloads>… ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Jul 17 16:43 0d694a37-9245-4ccd-9314-90e948e79657 → …/…/sda2
lrwxrwxrwx 1 root root 10 Jul 17 16:43 4e86c8ff-4a58-4234-a70f-acc6412c4d54 → …/…/sda1
lrwxrwxrwx 1 root root 10 Jul 17 16:43 e7fcbd31-a552-4bc1-85bb-3cc1a0353c45 → …/…/sda3
tosh-sm60<2018Jul17@17:20><~/Downloads>…

#15

Please re-read the thread.

We are at the point were we know which fstab entry is failing. We know which UUID is mentioned there. We know to which partition this points to. I do not see any need to find that out again along another path. The result will be the same. And basically there is nothing wrong with that fstab entry, thus why changing it?

The problem is that the file system on that partition (/dev/sd7) will not mount. It is supposedly an ext4 file system, but the superblock is damaged.

We try to confirm this with a straight mount command (thus avoiding all layers that a GUI adds).

And, working already at the next step, we try to find out what this “transferring a sizable video file (about 11GB) from /home (first partition) to /Media (second partition)” means. How was it done? That is interesting because it seems to be the action that initiated the problem.

#16

@Quads
PLEASE when you use code tags, include the command as well as the output. It is very difficult to understand otherwise. Especially so when follow the label “Fstab” (which is a text file and has no output) with what might be the output of “sudo fdisk -l /dev/sda”.

We only have the contents of an hand-edited text file to suggest that /dev/sda7 is formatted as ext4. Try this variation on Henk’s suggestion please:
Make sure that any lines referencing “/dev/sda7” or “UUID=36e0c062-6418-4472-a8a6-0ca7ed743f1d” are commented out, then


 #  mount /dev/sda7 /mnt

 #  df -hT |grep mnt

 # umount /mnt
#17 

$ sudo mount -t ext4 /dev/sda7 /mnt
$ mount: /mnt: can't read superblock on /dev/sda7.



$ sudo e2fsck -f -n /dev/sda7
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (6473116, counted=3606789).
Fix? no

Free inodes count wrong (5228004, counted=5227995).
Fix? no

/dev/sda7: 14876/5242880 files (2.4% non-contiguous), 14473316/20946432 blocks

Is this output helpful?

Transfer was made from Downloads folder in my home directory, to the Media directory on /dev/sda7 (if that clears it up) and was made via move command in Dolphin (Ctrl+X > Ctrl+V)

If you mean commented out in /etc/fstab they already are.

 
# mount /dev/sda7 /mnt

Gives same error as above, can’t read superblock.


# df -hT |grep mnt

Gives no output.


# umount /mnt
umount: /mnt: not mounted.

I know I made a mess of explaining things, and I should’ve saved the original error when it showed up. I’ll try again with /dev/sda7 not commented in /etc/fstab to see ifI can reproduce the original error, not the USB one. Thanks for your patience.

#18

Follow up, on boot I get:


Give root password for maintenance
(or press Control-D to continue):

Giving password gives me root shell, whereas pressing Control-D outputs:


    63.347070] JBD2: Invalid checksum recovering block 8 in log
    63.350127] JBD2: Invalid checksum recovering block 8 in log
    63.593076] EXT4-fs (sda7): error loading journal
You are in emergency mode. After logging in, type journalctl -xb " to view system logs , "systemctl reboot" to reboot, "systemctl default" or ^D to boot into default mode.
Give root password for maintenance
(or press Control-D to continue:

I’ll try to get system logs, I’ll edit them into this post.

#19

There is NO need to boot with it un-commented. It can not be mounted. Not as ext4 and also not when we let the mount comment decide if it is another file system type (as suggested by eng-int).

And again I want to stress that saying

Gives same error as above, can’t read superblock.

is NOT what people here like to see. They like to see the copy/paste between CODE tags of the complete thing: the line with the prompt and the command, the lines that follow, up to and including the line with the next prompt. Then we can see and you can refrain from typing what we see. Even the case “Gives no output” is covered then because we will see only the two lines! It is so easy to do IMHO. Look at this example:

henk@boven:~> df -hT |grep mnt
henk@boven:~>

That is all, no explanation needed.

Conclusion: there is no valid file system there. At least not one that can automagicaly detected by the mount command, and certainly no ext4.

Now the e2fsck shows some problems. Maybe eng-int has some more experience here, but we could start with finding the alternative superblocks. But for that we need to know the blocksize which with the file system was created. I am a bit lost here.

And about your description:

Transfer was made from Downloads folder in my home directory, to the Media directory on /dev/sda7 (if that clears it up) and was made via move command in Dolphin (Ctrl+X > Ctrl+V)

I never use things like Ctrl+. so again I am a bit lost here (When using Dolphin to move files, I either have a slpit Dolphin window or two Dolphin windows and drag the file from one place to the other).
But I do understand the starting point (your ~/Downloads/ directory), but I am uncertain about the place where it went. Was that /run/media/user/Media/.

I ask this again and again because one possibility that came to my mind is that you did not copy to a place in the file system, but to the device. That would of course destroy the file system, but it would also mean that the file itself can still be retrieved.

#20

I apologize, it’s because I am not so experienced with technical issues that I assume it’s easier to present them like this to others, although it’s obvious you guys would have no problem handling technical output. I’ll do it right from now on.

Conclusion: there is no valid file system there. At least not one that can automagicaly detected by the mount command, and certainly no ext4.

Now the e2fsck shows some problems. Maybe eng-int has some more experience here, but we could start with finding the alternative superblocks. But for that we need to know the blocksize which with the file system was created. I am a bit lost here.

And about your description:

I never use things like Ctrl+. so again I am a bit lost here (When using Dolphin to move files, I either have a slpit Dolphin window or two Dolphin windows and drag the file from one place to the other).
But I do understand the starting point (your ~/Downloads/ directory), but I am uncertain about the place where it went. Was that /run/media/user/Media/.

I ask this again and again because one possibility that came to my mind is that you did not copy to a place in the file system, but to the device. That would of course destroy the file system, but it would also mean that the file itself can still be retrieved.

That’s exactly where it went (I hope), /run/media/user/Media/ is where I store all of my media files (images, music, videos) so that they are unaffected by reinstalls or distro hopping. The file in question was a movie, to my memory I just Cut and Pasted into /run/media/user/Media. It finished without apparent problems. I also have the /Media directory bookmarked in Dolphin and that would make sending it to the device harder although mistakes could happen.

Do I have any options for more troubleshooting on the partition considering it cannot be mounted? (By this I mean to find out if I had actually sent it were I should’ve)

For what it’s worth, I have full system logs from:


# journalctl -xb

But they are 46 pages long (when opened in Kate), so I’ll have to post them on pastebin if you think they would be useful.