Cannot install Leap 42.1 after disk issues

Yesterday I saved the data from a friend’s disk, of which the partition info had gone. With testdisk I could repair that, and make a backup of the user data, but the system would not boot from the disk.
Setting the root partition as bootable, and, as last resort, letting testdisk write a new MBR, didn’t help.

The disk has three partitions, on swap, root and home. When connected to my Tumbleweed system, I see the original data in both root and home (well, otherwise I couldn’t have made a back-up ;))

So I decided to install leap 42.1 on it, but the install program sees a complete different partition scheme. Three partitions, but no swap seen, much smaller, and the main part of the disk as unpartitioned.
And it finds no fstab to grab a partitioning scheme from.

Of course I could simply repartition the disk, having a backup, but I’m curious to what goes wrong here…

Any thoughts?

Show us the relevant info of

fdisk -l

and

gdisk -l

-l does not work with gdisk point it to the drive to show ie something like gdisk /dev/sda

fdisk -l /dev/sdg
Schijf /dev/sdg: 931,5 GiB, 1000204886016 bytes, 244190646 sectoren
Eenheid: sectoren van 1 * 4096 = 4096 bytes
Sectorgrootte (logisch/fysiek): 4096 bytes / 4096 bytes
In-/uitvoergrootte (minimaal/optimaal): 4096 bytes / 4096 bytes
Schijflabeltype: dos
Schijf-ID: 0x00000000

Apparaat   Op.   Begin     Einde  Sectoren Grootte ID Type
/dev/sdg1        40192    566271    526080      2G 82 Linux wisselgeheugen
/dev/sdg2  *    566272   5809151   5242880     20G 83 Linux
/dev/sdg3      5809408 244190463 238381056  909,4G 83 Linux

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

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


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************

Disk /dev/sdg: 244190646 sectors, 931.5 GiB
Logical sector size: 4096 bytes
Disk identifier (GUID): 3A11D696-D398-4311-BF3F-27D9A36955C9
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 244190640
Partitions will be aligned on 256-sector boundaries
Total free space is 40619 sectors (158.7 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           40192          566271   2.0 GiB     8200  Linux swap
   2          566272         5809151   20.0 GiB    8300  Linux filesystem
   3         5809408       244190463   909.4 GiB   8300  Linux filesystem

Right, I was too fast.

Would write the partition data to disk with gdisk be a good idea?

But gdisk does not complain about -l, and gives more data.

Without -l:

gdisk /dev/sdg
GPT fdisk (gdisk) version 1.0.1

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


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************


Why is it wrong?

The -l option works without further parameters for fdisk, not for gdisk, which needs a device parameter

Could you post the same, when booted from the Leap install medium? BTW does that boot in EFI mode or non-EFI?

Hmmm… How do I know whether it boots in EFI- or non-EFI mode?

Visible in GRUB.

Did you already attempt to fsck the entire disk?

What you didn’t tell us is how the issues with the disk arose? On some update? On some attempt to upgrade?

It seems to be MBR boot on a DOS partitioned disk The gdisk and fdisk agree on partitioning and size.

If you boot the install in EFI mode (assuming an UEFI BIOS) things may look different since it may be wanting to change the partitioning to GPT from DOS to accommodate the EFI boot

I don’t know how to issue that commands when booted from the install medium. From the install menu, I can escape to a shell, but fdisk nor gdisk are available.

I suspect the cause was that the CPU-fan was not reconnected when the system was cleaned by a computer firm. Or maybe the fact that the mains socket was not earthed.
She did not do anything special, was downloading MuseScore from its website when the system stopped and wouldn’t reboot. She hasn’t got the root password, so she can’t do updates.

fsck /dev/sdg                                                                                                                                                                                                                                           
'fsck' uit util-linux 2.28.2                                                                                                                                                                                                                                                   
e2fsck 1.43.3 (04-Sep-2016)
ext2fs_open2(): Ongeldig magisch getal in superblok
fsck.ext2: Superblok is ongeldig -- reservekopieblokken worden bekeken...
fsck.ext2: Ongeldig magisch getal in superblok tijdens openen van /dev/sdg

Het superblok is onleesbaar of omschrijft geen geldig ext2/3/4-bestandssysteem.
Als het apparaat juist is en werkelijk een ext2-, ext3- of ext4-bestandssysteem
bevat (en niet swap of UFS of iets anders), dan is het superblok beschadigd.
U kunt dan proberen een ander superblok te gebruiken, bijvoorbeeld:
    e2fsck -b 8193 <apparaat>
of:
    e2fsck -b 32768 <apparaat>

Er is een dos-partitietabel gevonden in /dev/sdg
fsck /dev/sdg1
'fsck' uit util-linux 2.28.2
fsck /dev/sdg2
'fsck' uit util-linux 2.28.2
e2fsck 1.43.3 (04-Sep-2016)
/dev/sdg2: schoon, 283237/1313280 bestanden, 2297651/5242880 blokken
fsck /dev/sdg3
'fsck' uit util-linux 2.28.2
e2fsck 1.43.3 (04-Sep-2016)
/dev/sdg3: schoon, 65161/59596800 bestanden, 14981324/238381056 blokken

(I know Knurpht can read Dutch, should I translate this for gogalthorp?)

e2fsck -b 8193 /dev/sdg

or

e2fsck -b 32768 /dev/sdg

give the same result.

You don’t run fsck or related commands against the drive only against partitions. A drive has no file system all file systems are in partitions.

Any partition you run against must not be mounted. No repair happens on mounted drives

I got the gist

I misunderstood the question of Knurpht:

Did you already attempt to fsck the entire disk?

But as you saw, I also fsck’ed the filesystems. They were not mounted at the time.

Would write the partition data to disk with gdisk be a good idea?

Run smarctl against that disk to see how broken it is.

Also this drive shows as sdG so are you sure you look at the right drive in the installer???