Tried a few times now to install Tumbleweed on my PC with no success. It gets stuck at “Loading basic drivers” during the green progress bar. I already tried “nomodeset” and disabling Secure Boot. ISO is openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230501-Media.iso and checksum is ed1ecfc6a4e22f4741b79faa2b251e12253dec7cd3b24c478f01306ed29482cb. Re-downloaded 3 times. Used dd to make my USB bootable, also 3 times. My USB boots into other distros’ installation without issues.
Any help would be appreciated.
Specs: Intel 6600K @ 4.6 GHz, NVIDIA GTX 970, 16 GB RAM. Currently 220 GB free on my SSD, on Debian. Not dualbooting or anything weird.
When you installed Tumbleweed onto the USB drive, before you began the installation, did you either disable or, remove, the machine’s internal system disk?
So, I decided to give the “Loading basic drivers” step some patience and after 56 minutes, it finally proceeded to the installation. I don’t know what that was about, but do you think it has affected my install in any way? I’m up and running fine now, though yesterday I made a new post with a slight “issue” concerning GRUB where my previous OS (Debian) was, and still is an entry in my boot options. Since I don’t have the “Loading basic drivers” problem anymore, I want to close this thread and mark is as resolved. Even though I would be thankful to know why it took 56 minutes haha.
As for your question, I don’t fully understand. Before I used dd to put the .iso on the USB, I umounted the USB and did mkfs.vfat to make it FAT32.
That is a complete superfluous action. the dd will overwrite that file system (and also the partition table if you created one before you created the FAT32 file system).
where /dev/sdc represents the mass-storage device (USB stick in this case). When that is the done, the device is written over from the first byte either until the last byte or until there are no more bytes left in if.
That mans that the partition table (also starting at the first byte) and the following first partition (with the file system) is overwritten. It is gone. It is dead. It is no more…
And when it is literally true as he says " did mkfs.vfat to make it FAT32" and “it” there is the device, then there was no partition table, but the file system on the device will have be overwritten by the following dd nevertheless.
Please, please try to understand what dd is doing.
I had a very similar experience with a very different setup. I use QEMU to emulate a aarch64 system.
However it also took very long after the line:
Loading basic drivers…Loading basic drivers
In my case adding -accel kvm to the qemu parameters helped. The installation up to that point felt to be about the same speed, but then after a while it moved on with the installation.
So my guess is that it is some sort of performance issue. Maybe some checks that are run and all need to time-out or so?
Installing to a USB drive is reliable if, the machine’s “normal” system disk is not visible to the openSUSE installation routines.
Therefore, the machine’s default hard drive has to be either, disabled in UEFI/BIOS or, physically removed –
Before the installation (to a USB drive) is started.
I suspect that, the SUSE (not openSUSE) instruction sheet describes a fail-safe method for those folks who are not so trained up on “expert” procedures and methods …
The OP stated that he was trying to install openSUSE from a USB drive, not to one. One thing he did not specify was the hardware involved. I have personally found that there can often be a delay at “loading basic drivers” that I attribute to specific hardware differences. I have a long delay during install from my 2005 era machines, and very little delay with my Ryzen machines.
