There are a few aspects which are unclear to me from post #1 and #3.
It's unclear what the following quote means in the contest of installing from an .iso file:
Usually when one boots an .iso file from a menu, it's the boot menu of the BIOS/UEFI that has been accessed, not the grub menu, since grub would only be installed much later in the installation process. I guess then the reference is to the boot menu, but I may be mistaken.
Since you have already installed a distro which may have actually been booted from grub resulting in a kernel panic, the situation may be quite different to what one imagines. The situation is best clarified, for me anyway.
In post #3 it's mentioned that a distro has been installed, which I presume is a linux distro, but it also fails with "the same error", which presumably is the kernel panic.
It was mentioned that fast boot is not present, nor sata mode for selecting AHCI. On reading about this HP model Victus Gaming Laptop 15-fb1013dx (845A2UA), it appears that it runs an AMI BIOS/UEFI and that HP may actually modify it to remove the option, and they may do other modifications as well. One way of telling is by a meticulous navigation through all menu options. A laborious task without promise of success. On secure booting, that menu option does exist. On AHCI I can't say.
The following states usually enable a successful installation:
If the hardware is known to be good, for example, it all worked as intended when MS was installed, then that variable can be discounted and linux drivers will usually run the hardware just fine for machines like this laptop apparently released in 2023.
If the .iso files have been checksummed with the sha256sum command and are shown to be "OK" or pass, then that variable can be discounted as well.
Therefore, at the point at which one is sure of a good .iso and good hardware, then installation normally has no issues.
The following are some observations which occur.
Commonly kernel panics on installing from .iso files are caused by corrupted media, or problems with the drive. There are other causes too, such as the kernel being unable to find the root filesystem, but no details of the screen output from a kernel panic have been provided so readers are not aware of any error messages.
Since failures are continually occurring, one might speculate that they may be due to code that has been left over on the drive from all the activity of removing and installing that has occurred, as described in post #1 and #3. MS installations in particular are known to have sectors or blocks on drives are that are not so readily accessible to operating systems.
If it is indeed that left over code on the drive which is interfering, then one can clean the drive from a live disk. The drive appears to be an nvme disk according to specs here:
https://support.hp.com/rs-en/produc...laptop-15-fb1000/model/2101704034?sku=845A2UA.
To wipe an nvme drive one can use the relevant nvme commands from the package: nvme-cli, which is available on a number of live disks, including the live disk: SystemRescue, which one would need to download and write to a usb and run from there. In particular one could check out the
nvme sanitize command from its manpage. There's a learning curve and it's best to learn how these things work before implementing them.
After the drive has been cleaned, one can try a new installation.
-------
As it happens, I had a recent experience of verifying a fedora workstation .iso file with the checksum, described as follows.
The checksum is in the same directory as the .iso file in the repository from which the .iso file is downloaded, for example, both the .iso file and the checksum file were present here:
https://mirror.aarnet.edu.au/pub/fedora/linux/releases/43/Workstation/x86_64/iso/ and both downloaded into the same directory on the machine here.
There are many mirrors holding the same files around the world.
To verify the .iso file, both the checksum file and .iso file, located in the same directory, saw the following command run:
Code:
$ sha256sum -c Fedora-Workstation-43-1.6-x86_64-CHECKSUM | grep -i OK
sha256sum: WARNING: 17 lines are improperly formatted
Fedora-Workstation-Live-43-1.6.x86_64.iso: OK
The "OK" means the .iso file is verified. The WARNING here can be ignored because it refers to the gpg check data. Some details here:
https://discussion.fedoraproject.org/t/issues-with-verifying-the-iso/118690/3.
When the .iso file was installed on a machine here, it ran flawlessly on a clean drive. I can't say anything about the laptop drive, but perhaps some observations here give pause for thought.
Or maybe I'm just ignorant about the steps. A practical and understandable solution is within my capabilities, haha.
