2

I recently installed Ubuntu 18.04 Server on the nvme drive of a PC. During installation, I chose to use GPT and EXT4. After operating normally for a few weeks, the system had a disk failure, and then would no longer boot directly into the OS.

Booting into the OS is now only possible by selecting the nvme drive as the boot disk from the BIOS. Then, the system will operate normally until there is another disk failure.

To troubleshoot, I tried running fsck: sudo fsck /dev/nvme0n1. This gives an error, The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem.

However, if I fsck certain partitions, the result is either the same error or a clean fsck report.

  • Partition 1 (/dev/nvme0n1p1) is the 1MB boot partition. fscking it gives the superblock error.
  • Partition 2 (/dev/nvme0n1p2) uses the rest of the drive space. fscking it gives the clean results.

My questions are:

  1. I think Partition 1 may not be EXT4, which is why fsck doesn't work. What is the typical file system or organization scheme of the boot partition?
  2. I am trying to fix the periodic disk failure. Would the superblock issue have anything to do with it? If not, how should I troubleshoot further?
  3. Since the system no longer boots into the OS, I think the boot partition is corrupted. How can I fix this? Is this related to the disk failure?

Here is the output from lsblk -o NAME,FSTYPE,LABEL,MOUNTPOINT,SIZE,MODEL | egrep -v "^loop"

NAME        FSTYPE   LABEL                           MOUNTPOINT            SIZE MODEL
sda                                                                        1.8T ST2000DM008-2FR1
└─sda1      ext4                                                           1.8T 
sdb         iso9660  Ubuntu-Server 18.04.2 LTS amd64 /cdrom               14.9G USB Flash Drive 
├─sdb1      iso9660  Ubuntu-Server 18.04.2 LTS amd64                       834M 
└─sdb2      vfat     Ubuntu-Server 18.04.2 LTS amd64                       2.4M 
nvme0n1                                                                  465.8G Samsung SSD 970 EVO Plus 500GB          
├─nvme0n1p1                                                                  1M 
└─nvme0n1p2 ext4                                                         465.8G 

Here is the output of sudo parted -l

Model: ATA ST2000DM008-2FR1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2000GB  2000GB  ext4


Model: Samsung SSD 970 EVO Plus 500GB (nvme)
Disk /dev/nvme0n1: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2097kB  1049kB                     bios_grub
 2      2097kB  500GB   500GB   ext4
8
  • Can you include the output from lsblk -o NAME,FSTYPE,LABEL,MOUNTPOINT,SIZE,MODEL | egrep -v "^loop" in your question? – WinEunuuchs2Unix Jul 1 '19 at 17:16
  • @WinEunuuchs2Unix Yes – qnkxsovc Jul 1 '19 at 17:19
  • re: 1) The first partition on a booting drive AKA the EFI partition (if MBR partitioning is not used) is typically formatted as FAT32. en.wikipedia.org/wiki/EFI_system_partition – K7AAY Jul 1 '19 at 17:32
  • 1
    If using gpt with BIOS boot, then you have a bios_grub partition. That always shows as error in gparted as it is unformatted. It is just space for grub2's core.img which with MBR is normally in space just after MBR, but that space with gpt is used as part of gpt partition table. So fsck error is normal, since not ext4. You only use fsck on the ext family of formats, ext2, ext3 & ext4. – oldfred Jul 1 '19 at 20:29
  • 1
    It looks like your BIOS is in 'Legacy' mode. This should be changed to UEFI mode and sda1 should be formatted to FAT32, then re-run boot-repair. Make sure you back-up/image the sda1 partition first before attempting any of this. – Paul Benson Jul 2 '19 at 19:57
2

If using an older kernel a newer one might solve the problem. However in Arch Linux Solid state drive/NVMe it says:

Samsung drive errors on Linux 4.10

On Linux 4.10, drive errors can occur and causing system instability. This seems to be the result of a power saving state that the drive cannot use. Adding the kernel parameter nvme_core.default_ps_max_latency_us=5500 disables the lowest power saving state, preventing write errors.

This sounds like your best first step.


Reply to comments

My Samsung 960 Pro is similar to your Samsung 970 EVO. As a reference I'll include my own system and yours will look similar after repair:

$ lsblk -o NAME,FSTYPE,LABEL,MOUNTPOINT,SIZE,MODEL | egrep -v "^loop"

NAME         FSTYPE LABEL            MOUNTPOINT   SIZE MODEL
nvme0n1                                           477G Samsung SSD 960 PRO 512GB               
├─nvme0n1p9  swap                    [SWAP]       7.9G 
├─nvme0n1p7  ext4   Old_Ubuntu_16.04 /mnt/old    23.1G 
├─nvme0n1p5  ntfs                                 859M 
├─nvme0n1p3                                        16M 
├─nvme0n1p1  ntfs                                 450M 
├─nvme0n1p8  ntfs   Shared_WSL+Linux /mnt/e         9G 
├─nvme0n1p10 ext4   Ubuntu_18.04     /mnt/clone  27.2G 
├─nvme0n1p6  ext4   New_Ubuntu_16.04 /           45.1G 
├─nvme0n1p4  ntfs   NVMe_Win10       /mnt/c     363.2G 
└─nvme0n1p2  vfat                    /boot/efi     99M 
sr0                                              1024M DVD+/-RW DW316  
sda                                             931.5G HGST HTS721010A9
├─sda4       ntfs   WINRETOOLS                    450M 
├─sda2                                            128M 
├─sda5       ntfs   Image                        11.4G 
├─sda3       ntfs   HGST_Win10       /mnt/d       919G 
└─sda1       vfat   ESP                           500M 
2
  • Thanks. Do you recommend a way to repair the boot partition? – qnkxsovc Jul 1 '19 at 17:46
  • 1
    @qnkxsovc I've never had to repair a disk myself but you can't repair it when it is mounted. It's really a separate question you would be best served to post so experts could answer it but I suppose you can boot with a live USB and then run fsck to repair it. Now that you mention it I don't see a boot/efi on your system so it's not mounted yet anyway. – WinEunuuchs2Unix Jul 1 '19 at 17:56

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.