SOS = just can't install StartOS on Optiplex 7040 - systematic "No Bootable Devices found" error

StartOS Support
3

thanks a lot. I am not that technical but I will give it a try today.

How do I access Terminal ? (because once I reboot with USB stick in, it will propose to re-download the flashed OS on the SSD)

thx again

4

After installation of StartOS, he’s booting into live Linux Mint, and using the terminal there. You can find it in the Mint menu.

1 Like
5

The process is to flash a new USB thumb drive with Linux Mint, Ubuntu, or any other Linux distro that you fancy (I prefer Mint). After you complete the StartOS installation using the StartOS USB thumb drive, it will tell you to remove the thumb drive and reboot. At this point, remove the StartOS thumb drive and insert the Linux USB thumb drive (plus a keyboard, mouse, and monitor if you don’t have them hooked up yet). Then reboot, which will load up a Linux desktop. From there, you can run the Terminal. If you use Linux Mint, simply click on the “lm” logo at the bottom-left of the screen and search for “terminal”.

2 Likes
6

Hello StartOS Community,

I’m having a persistent issue installing StartOS on my Dell OptiPlex 7040 SFF and consistently getting “No Bootable Devices found” after installation completes. I’ve tried reinstalling multiple times, and many hours of trouble shooting with no success. the problem persists. I bought the hardware for nothing it seems.

My Hardware & BIOS:

  • System: Dell OptiPlex 7040 SFF
  • SSD: Samsung SSD 870 4TB (/dev/sda )
  • BIOS Version: 1.24.0 (latest)
  • BIOS Settings: UEFI mode enabled, Secure Boot disabled. (Note: My Dell BIOS initially only recognized my USB installer when in “Legacy” mode, even for UEFI-formatted media. I’d switch back to UEFI after booting the installer).

Problem Description:

The StartOS automated installer consistently reports a successful installation to the SSD. However, upon rebooting, the system fails to find a bootable device, leading to the “No Bootable Devices found” error.

Detailed Troubleshooting Steps & Observations (using GParted Live):

  1. Disk Preparation:
  • The 4TB SSD (/dev/sda ) was completely wiped with a GPT partition table.
  1. Automated StartOS Installation:
  • I’ve tried numerous automated installations, selecting the entire SSD for StartOS. Each time, the installer finished without apparent errors, but the system wouldn’t boot.
  1. Partition Layout After Installation (Observed via GParted Live):
  • /dev/sda1 : FAT16 (around 100MB-512MB), with boot and esp flags correctly set. (Note: FAT16 is unusual for ESP, typically FAT32 is expected).
  • /dev/sda2 : FAT32 (around 1GB), with msftdata flag. (Note: This seems to be acting as the /boot partition, but is FAT32 instead of the more common ext4 for /boot ). GParted refused to set only the boot flag without also setting esp on this partition, so I left it with msftdata .
  • /dev/sda3 : BTRFS, occupying the majority of the disk, sometimes showing lvm flags.
  1. EFI Bootloader Files Inspection (/dev/sda1 ):
  • Booted into GParted Live.
  • Mounted /dev/sda1 (EFI partition) to /mnt/efi .
  • Ran ls -l /mnt/efi/EFI/startos/ .
  • Result: Confirmed presence of essential bootloader files: BOOTX64.CSV , fbx64.efi , grub.cfg , grubx64.efi , mmx64.efi , shimx64.efi .
  • Conclusion: The bootloader binaries are indeed being placed on the EFI partition.
  1. Attempted Chroot for GRUB Repair (Failure):
  • After mounting /dev/sda3 to /mnt , /dev/sda2 to /mnt/boot , /dev/sda1 to /mnt/boot/efi , and binding /dev , /proc , /sys , /run . (Confirmed all these mounts via mount | grep "/mnt" were successful).
  • Attempted sudo chroot /mnt /bin/bash .
  • Error: chroot: failed to run command '/bin/bash': No such file or directory
  • Further checks: ls -l /mnt/bin/bash and ls -l /mnt/usr/bin/bash both reported “No such file or directory”. Even ls -l /mnt/bin/sh or /mnt/usr/bin/sh failed.
  1. Core OS Files Missing/Inaccessible:
  • Ran ls -F /mnt/ to inspect the contents of what should be the StartOS root filesystem (/dev/sda3 ).
  • Observed Directories: boot/ , config/ , current/ , dev/ , efi/ , next/ , proc/ , run/ , sys/ .
  • Critical finding: Missing crucial Linux root directories like bin/ , etc/ , lib/ , sbin/ , usr/ , var/ . This suggests the core OS files are either not being fully installed to /dev/sda3 or are placed within a BTRFS subvolume that’s not being mounted as the root.
  1. Live Environment sudo/PTY Issues:
  • I’ve also encountered sudo: unable to allocate pty: No such device errors when trying sudo umount /mnt/dev/pts or sudo -i in the GParted Live environment. This required rebooting GParted Live to clear.

My Hypothesis:

It appears the StartOS installer is correctly placing the EFI bootloader files, but it’s consistently failing to install the full core operating system files onto the /dev/sda3 (BTRFS) partition, or it’s installing them into a BTRFS subvolume that isn’t properly detected/mounted as the system root by the boot process. This means even if GRUB were to start, there’s no complete OS for it to load.

Request for Assistance:

Has anyone encountered this specific issue with Dell OptiPlex 7040 SFF systems or similar scenarios where the core OS files are seemingly incomplete after an automated StartOS installation (especially with BTRFS)?

Any guidance on how to properly identify and mount the correct BTRFS subvolume as root, or alternative methods to get a full StartOS installation working on this hardware, would be greatly appreciated.

Thank you for your time and help!

7

Given all the troubleshooting we’ve done, including multiple attempts to reinstall StartOS and manually configure the boot environment, here’s a summary of the persistent problem preventing your Dell OptiPlex 7040 SFF from booting from the SSD:

Summary of the Boot Problem

The core issue is a “No Bootable Devices found” error when trying to start StartOS from your SSD. This is a complex problem with several layers:

  1. Initial UEFI USB Boot Issues: Your Dell OptiPlex’s BIOS initially had trouble recognizing or booting from UEFI-formatted USB drives, forcing you to use “Legacy” mode to even start the GParted Live environment. This hinted at firmware-level difficulties with UEFI booting, even though your BIOS is updated.
  2. StartOS Installer Inconsistencies & Failures:
  • Automated Installation Failure: The StartOS automated installer consistently reports success, but the system still won’t boot. This indicates the installer isn’t properly registering the boot entry with your UEFI firmware or correctly setting up all boot components.
  • Unexpected Partitioning: We observed the installer created an EFI System Partition (/dev/sda1) as FAT16 (instead of the standard FAT32) and a /boot partition (/dev/sda2) as FAT32 (instead of the expected ext4). While these aren’t always fatal, they are non-standard.
  • BTRFS Root & LVM: The main operating system partition (/dev/sda3) uses BTRFS, and there’s a separate LVM data partition (/dev/sda4). This is a more complex setup that requires precise GRUB configuration to locate the kernel within these file systems.
  1. Bootloader Files Present, But Not Executable/Found:
  • Crucially, we successfully located the necessary EFI bootloader files (shimx64.efi, grubx64.efi, grub.cfg) in /mnt/efi/EFI/startos/ on your /dev/sda1 (EFI System Partition). This means the files themselves are physically on the disk.
  • The /dev/sda1 (EFI) partition also has the correct boot and esp flags, which are essential for UEFI to find it.
  1. The Core Problem: Incomplete StartOS Installation on the SSD:
  • Despite the bootloader files being present, our attempts to chroot into your installed StartOS system consistently failed with “No such file or directory” errors for /bin/bash or /usr/bin/bash.
  • Further investigation (ls -F /mnt/) revealed that the /mnt directory (where your /dev/sda3 StartOS root partition is mounted) does not contain a complete Linux root filesystem. It’s missing fundamental directories like bin/, etc/, lib/, sbin/, usr/, and var/. Instead, it shows directories like boot/, config/, current/, efi/, next/, proc/, run/, and sys/, which are more indicative of a minimal boot environment or a specific BTRFS subvolume, rather than the full OS.

Why It Prevents Booting

The combination of these issues leads to the “No Bootable Devices found” error because:

  • Missing OS Core: Even if GRUB could start, it has no complete operating system to hand off to. The essential programs (bash, system libraries, configuration files) that make up StartOS are simply not present in their expected locations on /dev/sda3.
  • GRUB’s Confusion: GRUB relies on update-grub to scan the installed OS and generate its configuration (grub.cfg). If the core OS files are missing or in an unusual BTRFS subvolume not properly detected, update-grub cannot correctly build the boot menu entries to load your kernel and initramfs from /dev/sda2 and the root filesystem from /dev/sda3 (especially if it’s within LVM).
  • UEFI Firmware Not Registering/Prioritizing: Even if GRUB files are there, the UEFI firmware on your Dell OptiPlex might not be correctly discovering and registering the “StartOS” boot entry, or it might be prioritizing other (non-existent) boot entries. However, this is secondary to the missing OS files.

In essence, you have the bootloader (GRUB) files ready on the EFI partition, but the actual StartOS installation that GRUB is supposed to load is incomplete or fundamentally corrupted on your main SSD partitions. Without a complete operating system, nothing can boot.

Given that repeated reinstallations haven’t resolved this, it suggests a persistent issue with how the StartOS installer writes files to your specific hardware configuration, or perhaps an underlying issue with the StartOS installation media itself.

8

update to my problem.

Thanks to @ [paulscode] (Profile - paulscode - Start9 Community) (you rock !!!) I adapted his solution to the Dell Optiplex 7040 , and StartOS is finally installed and booting easily.

Gratitude (:slight_smile:

here is the version of the procedure adapted to DELL machines for people who will encounter the same issue :

Based on the provided information about your OptiPlex partitions, here is an adapted version of the tutorial with the bash commands separated.

Adapted Tutorial for Your OptiPlex

Please note: This tutorial assumes your OptiPlex has a similar boot issue where it doesn’t recognize the bootloader after installation. The key difference in your setup is the split EFI System Partition (/dev/sda1) and a separate boot partition (/dev/sda2). This tutorial will focus on the EFI partition, as that’s where the bootloader files need to be.

You’ll need a keyboard, mouse, and monitor temporarily, along with a bootable Linux USB thumb drive (like Ubuntu).

Step 1:

Complete the initial StartOS installation process. When the OptiPlex reboots, it won’t launch StartOS. We’ll fix this in the following steps.

Step 2:

Attach the keyboard, mouse, and monitor, insert the Linux USB drive, and power on the OptiPlex. Boot from the USB drive.

Step 3:

Open a terminal and enter the following commands one by one. Adjust the device paths if your partitions are different than /dev/sda1 and /dev/sda2.

# Mount the EFI System Partition (/dev/sda1)
sudo mount /dev/sda1 /mnt

# Make a folder under EFI called "BOOT"
sudo mkdir /mnt/EFI/BOOT

# Copy shimx64.efi as BOOTX64.EFI
sudo cp /mnt/EFI/startos/shimx64.efi /mnt/EFI/BOOT/BOOTX64.EFI

# Copy mmx64.efi
sudo cp /mnt/EFI/startos/mmx64.efi /mnt/EFI/BOOT/

# Copy grubx64.efi
sudo cp /mnt/EFI/startos/grubx64.efi /mnt/EFI/BOOT/

# Create grub.cfg
sudo nano /mnt/EFI/BOOT/grub.cfg

Enter just the following two lines into the nano editor:

search --no-floppy --file /EFI/startos/grub.cfg --set=esp
configfile ($esp)/EFI/startos/grub.cfg

Then save the file by pressing Ctrl+X, then Y, and then Enter.

# Make sure writes are finished
sync

# Unmount the EFI partition
sudo umount /mnt

Step 4:

Reboot the computer. StartOS should now launch.

3 Likes
9

Excellent. Glad it worked out for you.

BTW, that LLM’s summary of the problem was a bit off, eh? :laughing:

At least it did identify the problem (though it is buried in there):

In short, the “fix” (hack?) is to place your bootloader at /EFI/BOOT/BOOTX64.EFI – that path is hard‑coded in the UEFI spec as the “removable‑media fallback,” so virtually every firmware will look there automatically when no explicit boot entry is found.

2 Likes
10

Thank you for this thorough report! I’ve added the 7040 to the known working hardware list.

2 Likes
11

Spent a whole day debugging and troubleshooting. Then installed umbrel within (no kidding) 5 minutes. And it just worked out of the gate!

12

Did you follow the process outlined by BlissHodl 4 posts back in this thread? If so, what step did you run into issues with?

I can understand giving up on troubleshooting and taking a different path, but IMO pointing users to Umbrel isn’t relaly the point of this thread. This thread is about getting StartOS to boot after install on the Dell OptiPlex 7040 with a SATA SSD.

1 Like
13

if you follow the tutorial to troubleshoot from the terminal (I posted lqst week) , then it works very nice and damn fassttttttt with no issue :innocent:

1 Like
14

I can confirm the creation of the \EFI\BOOT\BOOTX64.EFI (pseudo file) worked for me as well. Only difference is I just used the grubx64.efi file (renamed it) and no editing of the grub.cfg was required. (all other files copied from EFI/startos/ to EFI/BOOT/ as-is). I don’t have secure boot enabled.

@paulscode has the most succinct explanation… The Bios only accepts the \EFI\BOOT\BOOTX64.EFI location/filename… Even though it gives you the illusion that you can customize or choose something else.
Very frustrating indeed. I spent 5 hours on this, figured it out through trial and error, just now found this. I shoulda done a quick search here first. Lesson learned.

I just reeeeeeally wish start9 devs could add a popup or note or something in the description to warn about this issue.

1 Like
15

Or they could preempt the problem by adding something like the following during installation to create the fallback entry:

sudo grub-install --target=x86_64-efi --removable

or dpkg-reconfigure grub-efi-amd64 and enable “install to removable‑media path”. After that, Debian will keep both copies up‑to‑date during future grub-efi package upgrades.

1 Like
16

I’d be curious as to if the problem simply doesn’t exist on 0.4.0. If one of you would be so kind as to test this, and if it’s still a problem, I’ll pass this suggestion along. Please don’t put real money on Alpha software though!

17

Sure, I’ll test it this evening when I get home from work. I hadn’t noticed the pre-release before. Looking forward to experimenting with it.

1 Like
18

The same post-install issue is present in v0.4.0-alpha.9. Adding the removable media fallback fixes it, as with v0.3.5.1.

1 Like
19

Thank you for post, this fixed my boot problem on Mini PC i5-1335U

20

I’m trying this right now and I’m stuck at the 2. command.
" mkdir: cannot create directory ’ /mnt/EFI/BOOT’: no such file or directory"
I have legacy BIOS. I this the reason? Do I have to use something else for “EFI”?

21

Those instructions would only apply to UEFI. I assume you are in the context of CSM or the classic BIOS behavior which boots from MBR.

But you can confirm that if you want. I would start by making sure you are referencing the correct storage device:

lsblk -d -o NAME,SIZE,MODEL,TRAN

Find the device you have installed StartOS onto, and take note of its “NAME”. Typically it will be either “sda” or “nvme0n1”, but it can vary depending on the configuration of the drives and their technology. BTW, you will probably also see your USB thumb drive in the list (typically “sdc”), so make sure you identify the correct one (note the “SIZE”, “MODEL”, and “TRAN” values to help you properly identify it)

Once you have identified the device where you have installed StartOS to, then run the following command (replace “DEVICE” with your device – typically “sda” or “nvme0n1”):

sudo fdisk -l /dev/DEVICE

You should get an output something like:

Disk /dev/nvme0n1: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: FOOBAR BAZ 4TB                       
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 12345678-90AB-CDEF-1234-567890ABCDEF
                 

Device            Start        End    Sectors  Size Type
/dev/nvme0n1p1       34     204833     204800  100M EFI System
/dev/nvme0n1p2   204834    2301985    2097152    1G Linux filesystem
/dev/nvme0n1p3  2301986   33759265   31457280   15G Linux root (x86-64)
/dev/nvme0n1p4 33759266 7814037133 7780277868  3.6T Linux LVM

(the device names may be different). If the “Disklabel type” shows “dos”, then the EFI process mentioned earlier in this thread by BlissHodl is not applicable. If instead it shows “gpt” and first row in the table says it is type “EFI System” like in my example above, then the process is applicable, and you may just need to adjust the paths that you are using.

22

Thank you!
I have a classic BIOS and created an UBUNTU Live USB-Stick, using MBR to access terminal.
My device is sda (without a number, as in the guide) I’m going to try that.
Disklabel type is gpt and EFI System.