Can't read superblock on /dev/sda1 (can't boot)

General system Kernel, boot, graphics & hardware
1

3+ year old EOS system. BIOS and GRUB due to motherboard support. SSD is a Samsung purchased about 2 years ago. Did my weekly pacman -Syu today with no errors seen. Rebooted due to new kernel, and up pops BIOS menu. Ruh oh.

Boot the Cassini ISO image, in a terminal:

[liveuser@eos-2023.05.28 ~]$ sudo lsblk -f
NAME       FSTYPE   FSVER            LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0      squashfs 4.0                                                                    0   100% /run/archiso/airootfs
sda                                                                                                 
├─sda1     ext4     1.0                         431a5dae-8bfb-455e-92a5-6589e17c7eb0                
└─sda2     swap     1                swap       52c8bbc6-1c14-427b-99dc-b6a2caf37595                
sdb                                                                                                 
├─sdb1     exfat    1.0              Ventoy     A496-AED9                                           
│ └─ventoy iso9660  Joliet Extension EOS_202305 2023-05-28-11-02-36-00                     0   100% /run/archiso/bootmnt
└─sdb2     vfat     FAT16            VTOYEFI    83A6-E98E                                           
sdc                                                                                                 
sr0                                                                                                 
[liveuser@eos-2023.05.28 ~]$ sudo mount /dev/sda1 /mnt
mount: /mnt: can't read superblock on /dev/sda1.
       dmesg(1) may have more information after failed mount system call.

My inxi -Faz is: http://ix.io/4z6k

  • note the drive doesn’t even show up

The later dmesg entries are at http://ix.io/4z6l

If I try to run fsck on it:


[liveuser@eos-2023.05.28 ~]$ sudo fsck /dev/sda1
fsck from util-linux 2.39
e2fsck 1.47.0 (5-Feb-2023)
fsck.ext2: Input/output error while trying to open /dev/sda1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

The two e2fsck commands both return the same text.

Running lsblk -f again after some time passed, research, web searches, *fsck efforts, the output looks different. sda1 is there, but no other - missing filesystem, label, UUID, and the other columns.

Did this drive give up and croak?

2

Can you run gparted and does it see it?

3

Not seen. gparted only sees my Ventoy USB. It does not have the sda device on the Gparted | Devices menu.

4

What happens if you unplug the ventoy usb?

1 Like
5

I’m in a live session, so I’d expect yanking the ventoy USB wouldn’t be good. Here goes:

[liveuser@eos-2023.05.28 ~]$ gparted
/usr/bin/gparted: line 192: /usr/sbin/mkdir: Input/output error
touch: cannot touch '/run/udev/rules.d/64-md-raid/assuemply.rules': No such file or directory
/usr/bin/gparted: line 221: /usr/lib/gparted/gpartedbin: Input/output error
[liveuser@eos-2023.05.28 ~]$ lsblk -f
NAME  FSTYPE    FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop squashfs  4.0                       0      100%/run/archiso/airootfs
sda
sdc
sr0
[liveuser@eos-2023.05.28 ~]$

If this would be recoverable, this would be a miracle. This looks dark.

6

If your BIOS was reset for some reason, it may have some raid controller enabled by default.
Go into BIOS and check that drives are set to AHCI type.

7

BIOS appears intact. Although I rarely hang out here. There is no RAID functionality on this motherboard, nothing about AHCI either.

BIOS doesn’t even see the drive to select it in the boot sequence. This looks like a total loss.

Shame, as I was about to streamline my backups and make them automated & robust just this coming weekend.

8

There is Raid setting and AHCI in the UEFI Bios settings. It’s under SATA configuration. I also see you have it set for UEFI legacy. Was EOS installed In MBR mode? or UEFI?

Screenshot_20230626_221346
Screenshot_20230626_221346711×769 91.9 KB

1 Like
9

This is an older motherboard, 2016 era. It claims UEFI, but lacks the modern and more recent implementations. Asus something model, unknown.

I can’t find anything RAID or even UEFI in the various menus. I’ve hunted up and down.

EOS was previously on via MBR mode as when I made it years ago I wasn’t clear if UEFI would work or not.

10 
Machine:
  Type: Desktop Mobo: ASUSTeK model: H170M-PLUS v: Rev X.0x
    serial: <superuser required> UEFI-[Legacy]: American Megatrends v: 3805
    date: 05/16/2018

The motherboard is UEFI and is set to UEFI legacy. As shown in the previous post AHCI and Raid settings are there under SATA.

Here is the manual for your motherboard.

E10763_H170M-PLUS_UM_WEB.pdf (4.6 MB)

Edit: Normally you want secure boot disabled. You want it set the UEFI only. This way it won’t boot the ISO in Bios mode and install in Bios mode. SATA drive mode should be set to AHCI not Raid. These are just some of the settings you need to be aware of when installing.

1 Like
11

Wow, what a good find with the PDF manual. Thanks. I’ll review. The UI is pretty simple, with just 2 or 3 levels of menus at the worst.

I continue to fear the disk is gone. I got a new Samsung SSD and snapped it in to the bracket, and this one is identified by the BIOS and was able to later be partitioned, formatted and have something installed on it. I can’t even get this far with the previous SSD.

I’m into mid-week busy work, and will check on this in a few days putting the old disk back in and ensuring the BIOS settings didn’t evolve.

1 Like
12

wait how it was partitioned? by the UEFI?

13

Not sure what you mean by this. Drives that are new are not partitioned and would not have a file system on it. When you install you would still use erase disc and select swap file and ext4 or other such as btrfs file system or use manual partitioning. Most new drives have to be initialized and partitioned.

Edit: Just because the drive is recognized doesn’t mean it’s already partitioned.

14

Sorry was typing fast. I should have said:

“… was later able to be partitioned, formatted, and have something installed upon it …”

15

Much better! :wink:

16

Just a Saturday update of the crap I’ve been going through.

The new drive with Linux was updated today, with a new kernel. Thus new initramfs and related. I think my edits to fstab took effect at reboot, which were UUID’s instead of the devices. One of those install things I was just getting around to.

Reboots came into the emergency shell, saying that my UUID doesn’t exist for the big partition. No way. Type exit. Another emergency shell, same error, UUID doesn’t exist for the efi boot partition. Wrong. Exit, and the init process ends, with my tty login from which I can proceed. I can login and start dwm and act normal, as far as I can tell though.

If I revert fstab back to devices instead of UUIDs, boots are perfectly normal. Thus the state right now.

This motherboard is cursed. Tomorrow (Sunday) I’ll shutdown and try the old drive again to see how it behaves. I’ll update then, which might be the end of this thread.

17

I guess check what UUID it is assigning? :man_shrugging: Does it change?

18

The two UUIDs don’t change per blkid

19

I think i have come across this one other time and i cant remember the outcome. You may be able to find a post referring to it? Not sure if it can be found. I vaguely remember it though. Of course i could be wrong and it was not the same issue. :man_shrugging: