Creating a bug report/issue
I have searched the existing open and closed issues
Required Information
- DietPi version | Latest Native PC Image
- Distro version | Native PC for UEFI
- Kernel version |
uname --all
- Architecture |
x86_64
- SBC model |
Dell Wyse 3040
- Power supply used | OEM
- SD card used | Internal EMMC
Steps to reproduce
- Insert the flash drive with Dietpi installer image, boot into the user selection screen. Select ‘Install DietPi’.
Expected behaviour
- The installer should present with the storage devices available including the internal EMMC.
Actual behaviour
- The only installation target available is the external bootable USB flash drive.
Extra details
-
I have with the help of the forum members successfully installed both Bookworm and Trixie versions of Dietpi back in 2025. I wanted to start from scratch. This time however, the internal media (EMMC) is not available as an installation target.
Appreciate any help or guidance in this matter.
paste lines of logs or code into such code fences here
Please enter the Clonezilla Live submenu from the initial installer screen. There should be a way to enter a shell, from where you can check for detected drives and in case errors. Run these commanda there to see which block devices the system detected and whether the kernel was throwing errors:
lsblk
dmesg -l 1,2,3,4
The Clonzilla Live images are based on latest Debian testing, possible that something changed in Linux so that the eMMC is not detected anymore OOTB. If it cannot be changed from within Clonezilla Live itself, you could flash our non-installer image to boot DietPi directly from the USB drive, check whether the eMMC is detected there, and in case manually download and flash a DietPi image from there. Then we’d also have another hint that recent Linux is the issue.
Thank you for the response! I ran the suggested commands and got the following output:
loop0 7:0
sda
|-sda1
|-sda2
There is no mention of mmc or anything
The second command returned an error: read kernel buffer failed: operation not permitted
EDIT:
PS: Launched the live Dietpi image and it errors out at Missing modules (ca /proc/modules; ls /dev)
Dropping to a shell
(initramfs)
and hangs there.
Try sudo dmesg -l 1,2,3,4 instead, or with su or whichever method is available. Looks like it is not a root session.
Can you see whether it attempts to mount the rootfs on the USB drive? The output of the two suggested commands might indeed give a hint:
cat /proc/modules
ls /dev
For the USB drive, there shouldn’t be any special drivers needed, hence you should also see /dev/sda1 or /dev/hda1 or something. The initramfs is also built as generic image, hence contains all filesystem and controller drivers available. The eMMC however might require an additional driver which is maybe not available/compatible anymore in recent Linux. If it somehow attempts to mount the eMMC, that would explain the “missing modules (driver)” error message.
You could also try our Bookworm (live) image, which has older Linux 6.1: https://dietpi.com/downloads/images/DietPi_NativePC-UEFI-x86_64-Bookworm.img.xz
I would like to share an update. I have not tried the suggestion yet.
Initially I was booting the images from ventoy. Later, I decided to write the images to flash drive. I tried Balena Etcher and it warns that the installer does not have a boot partition. It writes it anyway, but the USB wont boot. I re-downloaded the image and tried with Rufus, the machine boots, but drops at an error:
Disk number: 0
Error!, No Existing or mounted disks were found.
I also tried the live image and it boots just fine after writing to the USB via Rufus. Also, it detects the onboard eMMC when checked through lsblk.
I believe these inputs may be helpful in diagnosing the issue. Please let me know if I need to continue with the suggested commands, or the course of action has changed.
Thanks.
EDIT: The dmesg errors are about:
wmi_bus wmi_bus-PNP0C14
Intel_sst_acpi
faux_driver regulatory
mwifiex_sdio
btmrvel_sdio
Bluetooth
You mean the Bookworm image I linked above? That would basically prove that Debian’s Linux lost support for this eMMC somewhere between v6.1 and v6.12.
The most recent Trixie image available for download
Ah okay, so Debian Linux 6.12 does detect the eMMC as well. This means you can flash an image to eMMC from there, using e.g. simply dd. Guess that solves your issue for now.
If you want to help narrowing things down, you could first upgrade to Linux 7.1 from backports, to check whether this breaks eMMC detection:
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot
This is not exactly the same build as the one the Clonezilla installer image, and even a subversion newer in the meantime, but would show whether newer Linux is the issue, or whether there is something else in the Clonezilla system causing the eMMC detection failure.
These are all related to WiFi/Bluetooth, the Intel_sst_acpi one audio. So it doesn’t look like some eMMC-related driver fails at least.
Yeah, Etcher had and maybe still has quite a number of issues. I don’t know Ventoy, but is looks like it might attempt to do some more magic for multi-boot. For our raw/live images, tools shouldn’t attempt to do anything but just flash it as is. (On Windows) Rufus is indeed my to-go flashing app for everything. Always reliable, never does anything unintended that would break things, but still has the optional features to deal with ISOs, UEFI, updating older binaries, etc, if really needed, and even some Windows image adjustments, IIRC. Just the best tool, sadly Windows-only 
.
Ah! ok, i would, but the live image boots, it’s the Clonezilla installer where things take a different turn. I have, as you suggested, written the live image to the internal eMMC via the dd command. And it works perfectly fine. And while I was experimenting with that, I also downloaded the Forky iteration of Dietpi, and the Clonezilla installer ends with the same error:
Disk number: 0
Error!, No Existing or mounted disks were found.
Here I would like to emphasize that the live forky version however does not recognize any internal eMMC drive unlike Trixie live. Still, i went ahead with the Trixie live image and used dd to flash the Forky live image onto the eMMC, rebooted and met with the OS stating "gave up waiting for root file system device. Missing modules (cat /proc/modules; ls /dev). Followed by Dropping to a shell! (initramfs).
I believe it is still in development. If not, I request if the issue can be resolved before it is released as stable.
I too prefer Rufus, however, the official document for Dietpi suggests Etcher, so I went with it, minimizing the introduction of variables.
Okay, so Debian Forky’s kernel does not recognize the eMMC either. Then I guess, installing the backports kernel on Trixie will cause the same error:
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot
We do use the official Debian kernel builds, so does Clonezilla. And that is basically mainline Linux. If Linux dropped support for this eMMC, there wouldn’t be anything we could do about it.
But there is a small chance it is due to a Linux build config change. What could be done is to find out which kernel module is loaded for the eMMC:
lsmod
Compare this command between a Trixie system, and a Forky system e.g. booted as live image from USB. Maybe we see a relevant driver missing on Forky, and maybe that can be re-enabled at built time. In that case, we could open a bug report with Debian, and/or open an MR to toggle the respective config switch.
Ok, i figured out that out. Seems like Forky is not loading the emmc/sdhci drivers during boot. Loading them manually allows lsblk to list mmcblk0 (7.3G) eMMC. However, the kernel needs to be compiled as well before the image can be flashed to the drive. As for now, it works on the live Forky image. The following commands were used:
sudo modprobe sdhci
sudo modprobe sdhci_acpi
sudo modprobe mmc_block
Hope this is helpful in tracing the issue.
Thanks.
Maybe some driver alias does not match anymore. Could be check with:
apt install pciutils
lspci
This print a list of PCI devices with some bus address. With the ID of the eMMC, check
cat /sys/bus/pci/devices/0000:<address>/modalias
And with the returned alias check
modprobe -R <alias>
If it prints an error, it means no driver matches the alias of this device.
We could check whether the device alias changed between the Linux version (unlikely), or whether the driver does not expose/support that alias anymore (more likely).
Sorry for the late replay, I have not tested with the suggestions yet, but I can confirm that the official Debian 14 testing release (Forky) does not detect the emmc out of the box, unless the commands are not executed by dropping into a shell (Ctrl+F2) in the setup and then continuing from the disk detection stage.
Then rebuilding initramfs. At the screen when the installer asks to reboot. Press Ctrl+F2. At the shell follow the sequence:
printf '%s\n' mmc_block sdhci sdhci_acpi >> /target/etc/initramfs-tools/modules
mount --bind /dev /target/dev
mount --bind /dev/pts /target/dev/pts
mount --bind /proc /target/proc
mount --bind /sys /target/sys
mount --bind /run /target/run
chroot /target update-initramfs -u -k all
Now we can reboot by returning to the installer and pressing Ctrl+F1.
Having a closer look at another possibly relevant change in Forky:
- Debian Forky switched to Dracut as default initramfs implementation.
- By default, Dracut is configured with
hostonly="yes", so that it reduces the kernel modules included in the initramfs to those really needed for the host where it runs. This does not mean that small changes break boot, but larger changes, like an entirely different type of boot media (like eMMC), might break it.
Clonezilla Live however still explicitly uses initramfs-tools (so does DietPi), and I just verified that the initramfs which is loaded by the UEFI GRUB config as well as BIOS syslinux config, does contain the 3 kernel modules mmc_block, sdhci, and sdhci_acpi. But … having a closer look into the init script, it seems it explicitly loads only this list:
atl1
atl1c
atl2
bnx2
bnx2x
crc32c
phram
mtdblock
loop
aqc111
asix
ax88179_178a
catc
cdc-phonet
cdc_eem
cdc_ether
cdc_mbim
cdc_ncm
cdc_subset
ch9200
cx82310_eth
dm9601
gl620a
hso
huawei_cdc_ncm
int51x1
ipheth
kalmia
kaweth
lan78xx
lg-vl600
mcs7830
net1080
pegasus
plusb
qmi_wwan
r8152
r8153_ecm
rndis_host
rtl8150
sierra_net
smsc75xx
smsc95xx
sr9700
sr9800
usbnet
zaurus
linear
multipath
raid0
raid1
raid456
raid5
raid6
raid10
efivarfs
If I load all those modules on a Forky system, none of mmc_block, sdhci, and sdhci_acpi is actually loaded.
So we are back at the fact that those 3 modules needed to detect the eMMC are not automatically loaded by udev. The commands I mentioned above are the only way to check why the respective device aliases do not match anymore.
).