dolphin_oracle wrote: Fri Nov 22, 2024 8:37 am
Ok what's happening is that the blkdiscard command we use to clear partition tables is failing. why I do not know.
The wrongly reported TRIM supported of the attached device, is misleading and makes blkdiscard fail.
The currently detection of running in VirtualBox for known wrongly reported trim-support is not sufficient,
but with adding a catch all.
So instead of a big Failure popup:
Code: Select all
2024-11-22 16:38:40.977 DBG default: SErr #32: "blkdiscard: Operation forced, data will be lost!\nblkdiscard: /dev/sdb: BLKDISCARD ioctl failed: Operation not supported\n"
2024-11-22 16:38:40.977 DBG default: Exit #32: 1
2024-11-22 16:38:40.977 DBG default: -- FAILED Phase 2 - Failed to prepare required partitions. --
it uses catch all which looks within the log like this:
Code: Select all
2024-11-22 16:42:48.948 DBG default: Exec #30: blkdiscard -fv -l 4194304 /dev/sdb
2024-11-22 16:42:48.951 DBG default: SErr #30: "blkdiscard: Operation forced, data will be lost!\nblkdiscard: /dev/sdb: BLKDISCARD ioctl failed: Operation not supported\n"
2024-11-22 16:42:48.951 DBG default: Exit #30: 1
2024-11-22 16:42:48.951 DBG default: Exec #31: blkdiscard -fvz -l 4194304 /dev/sdb
2024-11-22 16:42:49.139 DBG default: SOut #31: "/dev/sdb: Zero-filled 4194304 bytes from the offset 0\n"
2024-11-22 16:42:49.140 DBG default: SErr #31: "blkdiscard: Operation forced, data will be lost!\n"
2024-11-22 16:42:49.140 DBG default: Exit #31: 0
when it fails due to wrongly reported trim-support, it retreis w/o trim but dump-zeros.
I do rather ask first, in case you have already fixed it in another way, otherwise
let me send a PR to the installer (gazelle-installer) on github.
The fix was tested where the original install fail on an attached USB-device (64Gb Sandisk stick),
and fix worked also to install on entire drive, probably also with manually partitioning within the Installer.