On a HP dc7900 i have Ubuntu 16.04 on /dev/sda2 and 18.04 on /dev/sda1, both booted via grub.

I never had any problems with 16.04, so I guess the hardware is OK.

Suddenly 18.04 does not boot anymore. At some point during booting:

uuid=5fa5fa5f-dbb5-4986-991d-49a793bb5711 not found ...

I don't know the exact message anymore. Boot-Repair intelligently removed 18.04 from grub. How can I add 18.04 back to grub?

fsck.ext4 -v /dev/sda1

e2fsck 1.42.13 (17-May-2015)
/dev/sda1 has unsupported feature(s): metadata_csum
e2fsck: Get a newer version of e2fsck!

mount -t ext4 /dev/sda1 /mnt

No problem filesystem on sda1 is read/write accessible, no errors at all! So the filesystem seems to be still OK?

Ubuntu program Disks => sda1 unknown partition type

Program GParted => ext4

mke2fs -n /dev/sda1

mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 5120000 4k blocks and 1281120 inodes
Filesystem UUID: fb4ee7db-bcd6-4a78-9986-86e56ac24f0c
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 

e2fsck -f -b 32768 /dev/sda1
e2fsck 1.42.13 (17-May-2015)
e2fsck: Bad magic number in super-block 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

Are all these superblocks defect or is there some other problem?

To me it seems the information about the filesystem type may have been damaged. How can I set it to ext4? Can the 18.04 instance be rescued or reinstalled?

The 18.04 was not quite stable:

  • sometimes it hung when powered down.
  • when clicking "settings" it would definitely freeze.
    What wondered me, at reboot I never saw a fsck.
    Are superblocks updated at powerdown? can these freezes be the cause of defect superblocks?

No Windows on this system.

sdb      8:16   0 931,5G  0 disk 
├─sdb9   8:25   0     8M  0 part 
└─sdb1   8:17   0 931,5G  0 part 
sr0     11:0    1  1024M  0 rom  
loop2    7:2    0  87,7M  1 loop /snap/keepassxc/49
loop0    7:0    0    45M  1 loop /snap/core18/442
sdc      8:32   0 931,5G  0 disk 
├─sdc9   8:41   0     8M  0 part 
└─sdc1   8:33   0 931,5G  0 part 
sda      8:0    0 465,8G  0 disk 
├─sda4   8:4    0     7M  0 part 
├─sda2   8:2    0  19,5G  0 part /
├─sda3   8:3    0 426,7G  0 part /sda3
└─sda1   8:1    0  19,5G  0 part 

sda1 is the bad one

sda2 16.04

sda3 holds data

sdb and sdc are zfs mirror disks, not relevant.

gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 590C357D-ECF5-4EC4-A2A0-D50995D7C934
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2029 sectors (1014.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        40962047   19.5 GiB    8300  
   2        40962048        81922047   19.5 GiB    8300  ubuntu2
   3        81922048       976758783   426.7 GiB   8300  home
   4       976758784       976773119   7.0 MiB     EF02  

mount -t ext4 /dev/sda1 /mnt
cat /mnt/etc/fstab :

UUID=5fa5fa5f-dbb5-4986-991d-49a793bb5711 /               ext4    errors=remount-ro 0   1  
/swapfile                                 none            swap    sw                0   0  
UUID="9b34e80a-e998-424e-98b9-8decdfe851d6" /sda3     ext4    errors=remount-ro 0   2     


= = = = Next steps:

Started Ubuntu 18.04 LiveCD

  1. fsck -f /dev/sda1 => OK no errors
  2. tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1 => OK
  3. blkid still does not show sda1 (sda2,sda3, rest are all in the output)

I tried boot-repair: it issues an error. To me it seems the filesystem type is missing on sda1.

$ blkid
/dev/sda2: UUID="28bb4996-360d-4639-9e50-86aae98011fe" TYPE="ext4" PARTLABEL="ubuntu2" PARTUUID="2e36442b-f19f-4226-8912-aa2f7238d7c1"
/dev/sda3: UUID="9b34e80a-e998-424e-98b9-8decdfe851d6" TYPE="ext4" PARTLABEL="home" PARTUUID="62ee15b5-cbc6-4a84-98a9-cdfe9989549f"
/dev/sdc1: LABEL="zfs-samba" UUID="4660143235353326727" UUID_SUB="4506863601154525374" TYPE="zfs_member" PARTLABEL="zfs-42c380b70bbdd342" PARTUUID="000598e0-1e8f-0240-af28-8d231f696a01"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/sdb1: LABEL="zfs-samba" UUID="4660143235353326727" UUID_SUB="15368172379392166768" TYPE="zfs_member" PARTLABEL="zfs-00675688e5b3099d" PARTUUID="79a673f3-670f-7744-8a4c-27a45ad7597b"
/dev/sdd1: UUID="2018-07-25-03-21-56-00" LABEL="Ubuntu 18.04.1 LTS amd64" TYPE="iso9660" PTUUID="663eb4c4" PTTYPE="dos" PARTUUID="663eb4c4-01"
/dev/sdd2: SEC_TYPE="msdos" UUID="0D5F-1DB6" TYPE="vfat" PARTUUID="663eb4c4-02"
/dev/sda4: PARTUUID="68954dcd-3db6-484b-af0c-986360d2d0d7"
/dev/sdb9: PARTUUID="5c43b7a9-635c-ea4b-bc14-fd863ff0aea5"
/dev/sdc9: PARTUUID="682730d5-bc4a-4c4c-b4b4-262ffed34722"

No sda1 reported!

But again I can still mount by explicitly stating the filesystem type:

mount -t ext4 /dev/sda1 /mnt

Without -t ext4 it fails.

| improve this question | | | | |
  • Do you dual/triple boot with Windows? Is your disk MBR or GPT formatted? Do you have access to a 18.xx Ubuntu Live DVD/USB? If so, the fsck needs to run from there, as it's newer than the fsck that you probably ran from 16.04. Can you edit your question with 1) a gparted screenshot, 2) sudo blkid, 3) cat /etc/fstab from sda1? Report back to @heynnema – heynnema Jan 7 '19 at 16:03
  • @heynnema, see the extra info in the original question. – Rob Frohwein Jan 7 '19 at 18:06
  • Best is to run boot-repair to create boot-info-summary and provide link, this will give us better overview. – mook765 Jan 7 '19 at 18:17
  • @RobF thanks for the info. You forgot sudo blkid. I'm a little confused with the info that you did provide. What is sda1 used for? 18.04? Did it ever boot to 18.04? Have you been playing with partitions, or editing /etc/fstab? Do you know how you got to this point? Do you have a Ubuntu Live DVD/USB 18.xx? – heynnema Jan 7 '19 at 20:17
  • @heynnema sda1=ubuntu18.04 , sda2=ubuntu16.04. Both worked for a long time, but suddenly sda1 will not boot anymore. blkid /dev/sda1 => no info. blkid /dev/sda2 => expected info (type,uuid, label) – Rob Frohwein Jan 7 '19 at 20:44

You MUST have good backups before proceeding!

  • boot to a Ubuntu Live DVD/USB 18.xx
  • /dev/sda1 should not be mounted
  • open a terminal and type:

    sudo fsck -f /dev/sda1

If you have any problems at this point, then STOP, ping @heynnema with info.

  • in terminal type:

    sudo tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1

  • run Boot-Repair

  • boot to the GRUB menu and see if 18.04 appears and if you can now boot to it

| improve this answer | | | | |
  • I'm certainly not going to do anything when you put up a banner like that. – karel Jan 8 '19 at 14:14
  • @karel that's good. I don't want the OP to use it, yet, either... until they complete my request for additional info (sudo blkid) that would support my answer completely :-) – heynnema Jan 8 '19 at 14:24
  • @karel oh well, the OP didn't give me sudo blkid, AND went and did my answer anyway... – heynnema Jan 8 '19 at 14:39

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.