Fresh install of latest endeavouros

Decided to install using latest iso, to replace older endeavouros install, in offline mode, and got

“Install failed to create a partition table”

just after putting in user details etc.

Tried to reinitialise the whole disk with gparted, and same problem.

It’s an old thinkpad R61 with a 150GB disk and no fancy partitions.

It’s a learning opportunity!

what did you have as distribution on 64 bits or not

64 bit last time, around Sept, and again 64 bits:

linuxmint-19.3-cinnamon-64bit.iso

oops, meant:

endeavouros-2019.12.22-x86_64.iso

Are you installing on the whole disk? I would start the live usb and then run gparted. Create a new Gpt partion of the whole disc you are wanting to install to. Then close gparted and run the installer. Choose erase disc and install with or without swap. It should work then. Sometime Calamres just has an issue…it happens.

1 Like

Before changing the disk, can you show the output of commands:

sudo fdisk -l
lsblk -fm

I guess the machine uses BIOS legacy boot instead of UEFI?

Pretty sure it’s BIOS legacy boot - is there a way to confirm?

Whole disk install.

Tried gparted and it looked like the whole disk was ready but same error during install.

Installed without swap partition because it can be added as a file later.

I then decided to swap out the hard disk for another hard disk, and everything installed ok, so am very suspicious about the original hard disk, and will come back to this, as I do want to understand how to diagnose this if it is a bad disk.

I have just found my docking station so should be able to plug in the suspicious 2.5 inch hard drive and connect via usb to provide output for commands.

 lsblk -fm
NAME   FSTYPE LABEL UUID                                 MOUNTPOINT                SIZE OWNER GROUP MODE
sda                                                                              149.1G root  disk  brw-rw----
└─sda1 ext4         fe11ebb0-e509-4634-aa20-71e6c833a917 /                       149.1G root  disk  brw-rw----
sdb                                                                              149.1G root  disk  brw-rw----
└─sdb1 ext4         41052c97-378c-4ec1-b0b3-ed170cf62835 /media/[userid]/41052c97-3 149.1G root  disk  brw-rw----
sr0                                                                               1024M root  cdrom brw-rw----
Disk /dev/sdb: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc51908d6

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1        2048 312580095 312578048 149.1G 83 Linux

You could check the status of the /dev/sdb1 usb disk with gnome-disk-utility, it makes it easy.

1 Like

have found disks, and additional options on /dev/sdb1 to select “check filesystem” but …

error unmounting filesystem
device /dev/sdb1 is not mounted(udisks-error-quark,7)

So selected mount then check… then very quickly “filesystem intact - filesystem ext4 on ST… is undamaged”

or is there something else…

Disks shows hard disk as Partitioning Master Boot record…

SMART data and testing…
by clicking on the 3 points above

short smart data and self test completed successfully.
Overall assessment: Disk is OK

Is it possible to install on to sdb1 perhaps or. try something else…

If command

    ls /sys/firmware/efi/efivars

finds something, you have UEFI, otherwise BIOS.

But as none of the disks show an fat32 partition, it is most likely BIOS legacy and not UEFI.

So, sdb is a dos disk, and it is suitable for your machine. No need nor reason to make it a gpt disk.
For new machines gpt disk would be better, and usually is already like that.

Yes it is possible, you can do as you like.

What would you like to do?
Does sda1 or sdb1 already contain something you wish to keep?

The ls command does not find anything, and with the other evidence, it seems reasonable to say it is BIOS legacy.

decided to try dd on the suspect disk
have never used dd before

sudo mount /dev/sdb1 /mnt
cd /mnt
dd if=/dev/zero of=zero bs=1024k count=1024
dd: failed to open 'zero': Permission denied
# don't know why permission denied
sudo dd if=/dev/zero of=zero bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1,0 GiB) copied, 35.9016 s, 29.9 MB/s

That all looks like good news for the partitioning of the disk, but not sure why permission denied…

Carried on today with an attempt to copy the working disk to the suspect disk using dd with the suspect disk attached via usb docking station.

sudo dd if=/dev/sda of=/dev/sdb

Not sure if sudo dd if=/dev/sda/sda1 of=/dev/sdb/sdb1 should have been used. It has been running for about 8 hours and should finish in the next 2. I found the “status=progress” option could have been added, but in the meantime, have used “sudo pkill -usr1 dd” to request a status from the dd command.

If this works, should it be possible to do a usb boot from the suspect disk?

This old R61 and the two disks are for experimenting and learning.

I am open to suggestions and will certainly want to try out ddrescue, testdisk and dcfldd which came up during research, and also creating an endeavouros on the suspect disk via usb if possible, because that would be a useful thing to be able to do.

Hope that makes sense.

p.s. wanted to check understanding on dd - the up side to dd is that it just writes blocks to the disk, so partitioning table, and any partitions, to mirror the input, but the downside is that everything gets copied even if it is “empty” space. Presumably there isn’t a magic option that only copies the good stuff…

Maybe this helps?

1 Like

Thanks for the dd link - very useful.

1 Like

With the dd completed from working hard disk to “suspect” hard disk in a usb docking station, then tried to close down and start up again with the boot device as usb.

error: file ''/boot/grub/i386-pc/normal.mod not found.
Entering rescue mode ...
grub rescue >

So off to learn more about this and whether this is fixable or something can be learned from it.

According to the dd the two disks should be exactly the same, so there is much to learn.