Hello, I’m trying to install Fedora 39 on my computer.
I downloaded the Fedora 39 x86_64 ISO image (for Intel and AMD systems).
I used the Rufus program to copy the ISO image to a USB drive. I disabled secure boot in the BIOS and connected the USB drive.
When I turned on the computer, a menu called GRUB appeared. I selected the “Start Fedora-Workstation-Live 39” option to start Fedora from the USB drive.
I started the Fedora live version and then installed the system on an empty hard drive. At the end of the installation, it told me to restart the computer to start using Fedora.
However, when I restarted, the GRUB menu appeared again. Also, if I disconnect the USB drive, it gives me an error saying it can’t detect any boot drive. (ERROR: No boot disk has been detected or the disk has failed)
What I want to achieve is for the system installed on the hard drive to start directly when turning on the computer, without the GRUB menu appearing. I also want to be able to use Fedora without needing the USB drive connected.
I hope this better explains my situation. The idea is to configure the boot to allow normal Fedora use without depending on the USB drive.
The live system is to check your hardware … if it works you can direct in the live system install fedora and writing a new grub2 configuration to your new installed hard-drive.
You probably just made something wrong while install Fedora Linux to your hard-drive.
It could be that you made a legacy installation and the system searches for an EFI installation or viz versa.
Start again with the USB and use lsblk to share the disk information with us. inxi -Fzxx could also be interesting to see.
Did you copy the image or write it to the usb in iso mode?
If written in iso mode then booted it should open a live system desktop and one of the icons will be to install to hard disk. The grub menu should not display when booting from the usb. You may need to confirm that you booted the usb in uefi mode if you wish the installed system to boot in uefi mode.
Selecting to install, then under the disk config selecting the drive to install to and automatic partitioning should be all that is needed for a full installation. Once installed the usb drive is not normally required for anything else.
If this is the only OS on the machine the grub menu is normally hidden for booting. If it is a dual boot system the grub menu is normally displayed.
If the Rufus generated USB stick works, does it really matter? The OP already booted and already installed the the Fedora OS onto the hard disk.
The problem is more likely to be the type of the hard disk and how it is connected to the computer. For example, I have a desktop computer which refused to boot from a USB connected spinning hard disk.
Or as i mentioned, somehow the grub2 configuration is not pushed by the boot process.
Because booting from an externel USB SDD works if you configure correctly the bios.
I find it VERY hard to believe that anything done wrong in creation of the USB could give the described symptoms. So I think all that discussion above is just noise.
I don’t see (or don’t understand) any hints so far in this thread about what did cause the symptoms, so more information is needed. I agree with the above suggestion that lsblk is the most basic extra information we need to start diagnosing the problem. BUT I always find the default columns of lsblk leave out too much (especially FSTYPE) that is important to understanding such problems. It would be better if you copy/paste the following command to a terminal and then post (using the </> button for preformatted text) the results:
If I were to wild guess, I would say “empty hard drive” above was a misunderstanding and the USB was large enough that the install went to empty space on the same USB as the installer and Linux didn’t see unpartitioned space on any other drive. Of course lsblk would show all that. But if I jump ahead to assume that and guess the next step of diagnosis, a further guess would be a BIOS raid problem, which I think would be revealed by:
I checked this too but i found it the info is to much you have to copy and past … and specially to remember so @vekruse s lsblk -fp is much easier to remember is very convenient.
A pony for that would be -filesystem properties
lsblk --help reveals:
-f, --fs output info about filesystems
-p, --paths print complete device path
But I expect it gets its drive info redundantly with lsblk so any reason (such as BIOS RAID) that makes the drive invisible in lsblk would make it invisible there as well. Maybe some of the other info in inxi might help diagnose. But I expect the key will be what is missing from the lsblk output, leading to trying to diagnose WHY it is missing, using info from lspci and/or journalctl. But I haven’t fully thought through what to try to get from those (even assuming, as I expect, that lsblk indicates the basic problem).
I’ll keep that in mind in the future when I suggest copy/paste of a long lsblk command. In this situation, that is easier and very likely as informative as the command I suggested (in other situations of boot problems you also need UUID)
In addition, since there are problems with booting, the information from efibootmgr will probably be very relevant. Here the information from lsblk -fp -o +PARTUUID can be useful as it shows the partition UUID as well, and that is what you will find in the efibootmgr listing.
q -f, --fs
Output info about filesystems. This option is equivalent to -o NAME,FSTYPE,FSVER,LABEL,UUID,FSAVAIL,FSUSE%,MOUNTPOINTS. The
authoritative information about filesystems and raids is provided by the blkid(8) command.
-p, --paths
Print full device paths.
and lsblk -h gives all the available column names so it can be tailored as desired.
Your listing was great, but I agree that simpler seems better since the ‘-f’ option provides a mostly useful grouping of the data.
You might run that as lsblk -fp to show more detail.
The inxi command probably did not work because it may need installed before it can be used. The system should have offered to install inxi for you, and if you chose to not do so that may be done with sudo dnf install inxi.
From the looks of that lsblk output I see that sda appears to (maybe) be partitioned for an os, but sdc appears to have no partitions created.
Which device did you actually install fedora onto?
Edit: More info was provided later making the guess I made in this post very likely wrong. So ignore the rest of this post.
Just to be clear, you are saying you rebooted without the USB (as opposed to taking the USB out while the system was on with the grub menu displayed) and the BIOS displayed that message?
We know (from your lsblk output that the BIOS did see the drive. But if it doesn’t see the drive soon enough to boot from it, that is what needs to be corrected.
First, to really verify that the BIOS sees the drive, go into BIOS settings and try to find the page where it gives info about SATA drives and see if that looks correct.
At the same time look at any BIOS setting mentioning fast boot or similar things and see if any will get the BIOS to wait long enough for the SATA drive to be ready (assuming my current guess at the problem is correct).
What jumps out is the fact that sda1 is not identified as FAT32 EFI_SSD
That tends to indicate my second guess at the problem (my post above about BIOS timing) is as wrong as my first guess.
I see the output format of lsblk -fp on my own Fedora 38 is very different from my Fedora 39 and each very different from Mike’s Fedora 39. So maybe this is just a formatting issue, but I think it is actually the main problem.
I have seen several times that Anaconda says the install is done and the system is ready for reboot, but it actually isn’t done (due to write back caching happening somewhere). So it is necessary to wait another minute when it says it is done before rebooting. My third guess is that problem.
I assume Jeff and others know the command to redo that last part of the install AKA repair the EFI partition. I only know how to do that with a bunch of manual steps, rather than the correct command. It takes more time, but less thought to wipe out the entire install and do it all over and wait longer when it says it is done and ready to be rebooted.
I assumed that and simply pointed out the capital I to help Mike. But I’m pretty sure we are past caring about the info from inxi. At this point, I think what is needed is rebuilding the EFI partition.
