I know that this is an old post but I am not sure if hard coding /dev/sda is a good idea. Instead, I'd use something similar to
d-i partman/early_command string \
USBDEV=$(list-devices usb-partition | sed "s/\(.*\)./\1/");\
if [ ! -z "$USBDEV" ]; then \
BOOTDEV=$(list-devices disk | grep -v "$USBDEV" | head -1);\
Have you tried to install a current distribution on a uefi partition ?
I had the same problem until I discovered UEFI in the BIOS options so I installed linux using uefi partition. Then, all modules were detected and the system worked fine. I tried with ubuntu 18.04 and openSuse. No problems till now.
made using Rufus 3.8
Is it officially known to work? Rufus has been known to cripple hybrid ISOs for quite some time around me (like UltraISO or UNetBootin), so we ended up recommending plain dd or imagewriter-- maybe try writing ALT Rescue this way and if it works, you at least know the path :-)
Another source of trouble might be 32-bit UEFI firmware ...
while you still have the HDD with Mint, use it to make a bootable installation USB with the new Linux (ie, download iso, create USB from ISO (it's not a mere copy, but there are utilities to help).
With the HDD still in boot on the USB. There is normally a "Live" option where you use the OS on the USB (your HDD is there, but read-only). Use this to assert ...
https://forums.linuxmint.com/viewtopic.php?t=290781 explains the options available to you, but were it me, I could just
1) Make a LiveUSB using the version of Mint you want
2) Remove the HDD from the PC
3) Install the SSD into the PC
4) Reinstall Linux Mint to the SSD
5) Attach the HDD through a USB external drive adapter and
6) copy the ...
In Dell's system BIOS (accessed by tapping F2 repeatedly on boot up), I had to change the "SATA" setting to AHCI. The RAID option was selected instead, somehow. I rebooted and the installer found a place large enough to install.
@oldfred pointed me in the direction of this Dell support article that made that recommendation.
I ran into similar problem before when installing Centos7 using dd for writing USB. Downloading .iso file again and using Fedora Media Writer on Windows to prepare USB solved it. I think it may because that some bytes changed when downloading the image from network the first time. Have you verified checksum after downloading?
Dealing with virtual machines, some of the file system etc were created when the image was created, can be long before the instance was created.
The time stamp on /etc/locale.conf seems modified when the instance is boot up during instance creation. This might be a good time to use unless the locale is modified later on.
The /etc/hostname is similar, ...
I had this issue as well, but underneath it was actually a problem with graphics drivers. I added nomodeset to boot options and booted successfully. For more information see https://askubuntu.com/questions/947830/errors-from-nouveau-when-installing-or-booting-from-live-usb
Thanks for all the replies.
I was able to get rid of the nfs problems, but now i'm stuck with some step.
The nfs part is running fine, and i'm also able to mount the squashfs file.
Unfortunately i get this kernel panic, does someone know what the problem can be?
Ahoy friends. I was able to get it running.
I'm that happy friends, you cannot believe.
The answer is, surprisingly, "it depends on how exactly you're booting".
By pressing TAB or ESCAPE when the first message that speaks about CentOS appears, you're going to access the bootloader, and have the opportunity to add various boot options if necessary. This will result in the boot: prompt.
If you're booting in legacy BIOS style from optical media, ...