Ubuntu 18.04 boot problems
0
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,
4096000
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.
lsblk:
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
- fsck -f /dev/sda1 => OK no errors
- tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1 => OK
- 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.
boot grub2 18.04 boot-repair
edited 2 days ago
karel
57.6k12128146
asked Jan 7 at 12:42
RobFRobF
13
|
show 3 more comments
0
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,
4096000
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.
lsblk:
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
- fsck -f /dev/sda1 => OK no errors
- tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1 => OK
- 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.
boot grub2 18.04 boot-repair
edited 2 days ago
karel
57.6k12128146
asked Jan 7 at 12:42
RobFRobF
13
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/fstabfrom sda1? Report back to @heynnema
– heynnema
Jan 7 at 16:03
@heynnema, see the extra info in the original question.
– RobF
Jan 7 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 at 18:17
@RobF thanks for the info. You forgotsudo 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 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)
– RobF
Jan 7 at 20:44
|
show 3 more comments
0
0
0
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,
4096000
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.
lsblk:
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
- fsck -f /dev/sda1 => OK no errors
- tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1 => OK
- 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.
boot grub2 18.04 boot-repair
edited 2 days ago
karel
57.6k12128146
asked Jan 7 at 12:42
RobFRobF
13
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,
4096000
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.
lsblk:
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
- fsck -f /dev/sda1 => OK no errors
- tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1 => OK
- 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.
boot grub2 18.04 boot-repair
boot grub2 18.04 boot-repair
edited 2 days ago
karel
57.6k12128146
asked Jan 7 at 12:42
RobFRobF
13
edited 2 days ago
karel
57.6k12128146
asked Jan 7 at 12:42
RobFRobF
13
edited 2 days ago
karel
57.6k12128146
edited 2 days ago
karel
57.6k12128146
edited 2 days ago
karel
57.6k12128146
57.6k12128146
asked Jan 7 at 12:42
RobFRobF
13
asked Jan 7 at 12:42
RobFRobF
13
asked Jan 7 at 12:42
RobFRobF
13
13
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/fstabfrom sda1? Report back to @heynnema
– heynnema
Jan 7 at 16:03
@heynnema, see the extra info in the original question.
– RobF
Jan 7 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 at 18:17
@RobF thanks for the info. You forgotsudo 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 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)
– RobF
Jan 7 at 20:44
|
show 3 more comments
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/fstabfrom sda1? Report back to @heynnema
– heynnema
Jan 7 at 16:03
@heynnema, see the extra info in the original question.
– RobF
Jan 7 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 at 18:17
@RobF thanks for the info. You forgotsudo 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 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)
– RobF
Jan 7 at 20:44
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 at 16:03
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 at 16:03
@heynnema, see the extra info in the original question.
– RobF
Jan 7 at 18:06
@heynnema, see the extra info in the original question.
– RobF
Jan 7 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 at 18:17
Best is to run boot-repair to create boot-info-summary and provide link, this will give us better overview.
– mook765
Jan 7 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 at 20: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 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)
– RobF
Jan 7 at 20:44
@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)
– RobF
Jan 7 at 20:44
|
show 3 more comments
1 Answer
1
active
oldest
votes
0
You MUST have good backups before proceeding!
- boot to a Ubuntu Live DVD/USB 18.xx
- /dev/sda1 should not be mounted
open a
terminaland type:
sudo fsck -f /dev/sda1
If you have any problems at this point, then STOP, ping @heynnema with info.
in
terminaltype:
sudo tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1
run
Boot-Repairboot to the GRUB menu and see if 18.04 appears and if you can now boot to it
answered Jan 7 at 21:00
heynnemaheynnema
18.2k22054
I'm certainly not going to do anything when you put up a banner like that.
– karel
2 days ago
@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
2 days ago
@karel oh well, the OP didn't give mesudo blkid, AND went and did my answer anyway...
– heynnema
2 days ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1107715%2fubuntu-18-04-boot-problems%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
0
You MUST have good backups before proceeding!
- boot to a Ubuntu Live DVD/USB 18.xx
- /dev/sda1 should not be mounted
open a
terminaland type:
sudo fsck -f /dev/sda1
If you have any problems at this point, then STOP, ping @heynnema with info.
in
terminaltype:
sudo tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1
run
Boot-Repairboot to the GRUB menu and see if 18.04 appears and if you can now boot to it
answered Jan 7 at 21:00
heynnemaheynnema
18.2k22054
I'm certainly not going to do anything when you put up a banner like that.
– karel
2 days ago
@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
2 days ago
@karel oh well, the OP didn't give mesudo blkid, AND went and did my answer anyway...
– heynnema
2 days ago
add a comment |
0
You MUST have good backups before proceeding!
- boot to a Ubuntu Live DVD/USB 18.xx
- /dev/sda1 should not be mounted
open a
terminaland type:
sudo fsck -f /dev/sda1
If you have any problems at this point, then STOP, ping @heynnema with info.
in
terminaltype:
sudo tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1
run
Boot-Repairboot to the GRUB menu and see if 18.04 appears and if you can now boot to it
answered Jan 7 at 21:00
heynnemaheynnema
18.2k22054
I'm certainly not going to do anything when you put up a banner like that.
– karel
2 days ago
@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
2 days ago
@karel oh well, the OP didn't give mesudo blkid, AND went and did my answer anyway...
– heynnema
2 days ago
add a comment |
0
0
0
You MUST have good backups before proceeding!
- boot to a Ubuntu Live DVD/USB 18.xx
- /dev/sda1 should not be mounted
open a
terminaland type:
sudo fsck -f /dev/sda1
If you have any problems at this point, then STOP, ping @heynnema with info.
in
terminaltype:
sudo tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1
run
Boot-Repairboot to the GRUB menu and see if 18.04 appears and if you can now boot to it
answered Jan 7 at 21:00
heynnemaheynnema
18.2k22054
You MUST have good backups before proceeding!
- boot to a Ubuntu Live DVD/USB 18.xx
- /dev/sda1 should not be mounted
open a
terminaland type:
sudo fsck -f /dev/sda1
If you have any problems at this point, then STOP, ping @heynnema with info.
in
terminaltype:
sudo tune2fs -U 5fa5fa5f-dbb5-4986-991d-49a793bb5711 /dev/sda1
run
Boot-Repairboot to the GRUB menu and see if 18.04 appears and if you can now boot to it
answered Jan 7 at 21:00
heynnemaheynnema
18.2k22054
edited 2 days ago
answered Jan 7 at 21:00
heynnemaheynnema
18.2k22054
answered Jan 7 at 21:00
heynnemaheynnema
18.2k22054
answered Jan 7 at 21:00
heynnemaheynnema
18.2k22054
18.2k22054
I'm certainly not going to do anything when you put up a banner like that.
– karel
2 days ago
@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
2 days ago
@karel oh well, the OP didn't give mesudo blkid, AND went and did my answer anyway...
– heynnema
2 days ago
add a comment |
I'm certainly not going to do anything when you put up a banner like that.
– karel
2 days ago
@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
2 days ago
@karel oh well, the OP didn't give mesudo blkid, AND went and did my answer anyway...
– heynnema
2 days ago
I'm certainly not going to do anything when you put up a banner like that.
– karel
2 days ago
I'm certainly not going to do anything when you put up a banner like that.
– karel
2 days ago
@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
2 days ago
@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
2 days ago
@karel oh well, the OP didn't give me
sudo blkid, AND went and did my answer anyway...– heynnema
2 days ago
@karel oh well, the OP didn't give me
sudo blkid, AND went and did my answer anyway...– heynnema
2 days ago
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1107715%2fubuntu-18-04-boot-problems%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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/fstabfrom sda1? Report back to @heynnema– heynnema
Jan 7 at 16:03
@heynnema, see the extra info in the original question.
– RobF
Jan 7 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 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 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)
– RobF
Jan 7 at 20:44