Image | UEFI compatible x86_64 image

[Fourdee]

Stable:

https://dietpi.com/downloads/images/DietPi_NativePC-UEFI-x86_64-Bullseye.7z

• Install instructions are included in this archive.

---

https://twitter.com/DietPi_/status/915396664013312000

Our current Native PC image is MBR based and relies on CSM mode for UEFI. CSM not available on some devices.

[Fourdee]

Z83:

[Fourdee]

Method 1: Install any Debian OS onto device, then run DietPi PREP:

• https://github.com/Fourdee/DietPi/issues/1285#issue-280771944

---

Method 2: UEFI x86_64 image:

• Based on @sal666 excellent Clonezilla install method 👍 https://github.com/Fourdee/DietPi/issues/1007#issuecomment-328102850

Step 1: Download Rufus and DietPi

• Download Rufus
• Download the DietPi ISO image (with CloneZilla bundled)

EDIT: Updated install instructions are now added as text file in the download archive, please follow those instead!

#### Step 2: Use Rufus to write the ISO | @sal666 Clonezilla installer - Run Rufus - Under ```Partition scheme```, select ```GPT partition scheme for UEFI``` - Select the DietPi ```.iso``` image - Click start to write the DietPi image

Step 3: Install DietPi image onto device

• Power on the device with USB pen drive attached
• Enter BIOS and select USB pen drive as the 1st boot device, then save and exit BIOS.
  -- Select "Install DietPi mmcblk0" (if you have an onboard EMMC chip)
  -- Select "Install DietPi sda" (to install on the 1st HDD as detected by BIOS/clonezilla, unfortunately, we have no way of providing this info on screen, use with caution)
  -- Please note, this will overwrite and replace any OS installed on the target device.
• Once completed, the system will power off.
• Unplug the USB drive, and power on system.

[Fourdee]

Rufus install process confirmed working by one of our users:
https://dietpi.com/phpbb/viewtopic.php?p=9501#p9501

---

Outstanding issues:

• User reports no audio on device.
• Implement GPU driver install?

[georgecarstoiu]

Tried installing it on an Intel NUC NUC6CAYH - no emmc, just one normal ssd.

Followed the steps described above, but it didn't work. Was unable to install it in the end. Still would be nice to have a normal ISO.

[nwcatalyst]

Tried on NUC NUC6CAYS (with 32GB eMMC) and the install process did not work the first time (odd error about not being able to find mmcblk0 though it had just returned messages saying it was located...

Tried again immediately and it seemed to work.

I did see a bunch of I/O errors for the eMMC during install, which was a major reason I came to dietpi from trying to run Mint on it. I will get it up and running and report back if I am having the same issues.

Thanks for all the efforts...

Would love to have audio support.

EDIT***

The system is also crashing the eMMC - causing it to revert to read only after bunch of I/O errors on the eMMC.

[Fourdee]

@nwcatalyst

Thanks for testing 👍

This may be a hardware/EMMC issue (may also be related to discard fstab disabled in v6.0). Do you experience EMMC I/O errors with other OS?

It may also be worth trying our new PREP system, requires a debian installation on EMMC:
https://github.com/Fourdee/DietPi/issues/1285

[nwcatalyst]

I had no issues with default W10 installation before trying various Linux distros. I will try again.

…

-------- Original Message --------

On Jan 11, 2018, 2:58 AM, Dan wrote: ***@***.***(https://github.com/nwcatalyst) Thanks for testing 👍 This may be a hardware/EMMC issue (may also be related to discard fstab). Do you experience EMMC I/O errors with other OS? It may also be worth trying our new PREP system, requires a debian installation on EMMC: [#1285](https://github.com/Fourdee/DietPi/issues/1285) — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](https://github.com/Fourdee/DietPi/issues/1171#issuecomment-356900217), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AOR0F8Bq0HGo5i6Zj4nv7uKeYJCnB4zgks5tJelMgaJpZM4PuAso).

[Fourdee]

Notes to prep:

• Run prep, install both microcodes (intel/amd)
• LXDE live, resize partition + zerofree
• Clonezilla

[MichaIng]

v6.0 EFI image for testing is there btw: https://dietpi.com/downloads/images/

@Fourdee
Is it wanted that this is in releases instead of testing?

[Fourdee]

@MichaIng

Is it wanted that this is in releases instead of testing?

Yep tested it personally and ready for use (- any patching during v6.0 update), however, dietpi.com links are not updated yet (still using old <v159 image). I'll do the dietpi.com links prior to v6.0 completion.

Links to v6.0 image, as above, its fine.

[Fourdee]

Marking as completed, image is now available, and, PREP method also:
https://github.com/Fourdee/DietPi/issues/1171#issuecomment-336522021

[Fourdee]

https://dietpi.com/phpbb/viewtopic.php?p=10773#p10773

[sal666]

@MichaIng
You'r welcome.
Regarding the OS image, I've found gpt errors that needed to be fixed with gdisk. I see that DietPi-Imager already runs gdisk after shrinking, maybe it should be run again after truncating the image file?
I think that DietPi-Imager can be extended to also generating a Clonezilla image. Let me make some test and I can PR extra code to it

[MichaIng]

@sal666

I see that DietPi-Imager already runs gdisk after shrinking, maybe it should be run again after truncating the image file?

The second gdisk in the script seems to be not required at that place, parted just ran into that error once at the start during my test, which is strange since partition-wise this is a fresh Debian install then, DietPi-PREP does not touch anything about the partition table, as long as there are no APT installs that do that outside of our control.
For this image, I did not truncate the final file, but dd stopped writing it (from raw disk) after that last partition end + some failsafe KiBs have been reached.

On next GPT image creation I will verify, but I think the error is not present after writing or truncating the image file, but introduced when writing the image to a disk afterwards. The same error is also produced by our old installer (OUTDATED LINK REMOVED), but it is fixed (or at least ignored) there automatically as well.

Btw I was attaching the old installer image as virtual ROM to a VM (VirtualBox with EFI enabled) and tried to install on that main drive. When trying to boot after install has finished, it just shows something like "Error EFI partition". You did not try those on VM once, did you? Would make things much easier for me to review/test/debug EFI-specific issues.

I will re-try with this new image and additional, in case of same failure, run some fsck from another VM, who knows...

[sal666]

Sorry, previous uploaded file had errors. I have updated the link with a new one.
It's tested to be working with Apollo Lake.

[sal666]

@MichaIng

Btw I was attaching the old installer image as virtual ROM to a VM (VirtualBox with EFI enabled) and tried to install on that main drive. When trying to boot after install has finished, it just shows something like "Error EFI partition". You did not try those on VM once, did you? Would make things much easier for me to review/test/debug EFI-specific issues.

I think I also run into this same error with the old installer, but I'm not sure. Should try again and see what happens.

[sal666]

@MichaIng
I'm trying to generate a fresh installation on a VM following your guide: https://github.com/MichaIng/DietPi/wiki/How-to-create-a-DietPi-image-for-x86_64-PCs-(UEFI).
I found that this VM won't boot unless I answer 'yes' to 'Force GRUB installation to the EFI removable media path?', witch your guide says should be a 'No'. Is this normal?

Btw, I completed the guide with a more detailed list of the steps as they are shown by the Debian installer.

[MichaIng]

@sal666
In my case on PC it boots fine without this. The installer itself was loaded in EFI mode and I created according to the howto a 100M EFI partition. AFAIK this option is only required if the system somehow is not able to start the bootloader from the internal EFI partition.
However yeah perhaps indeed the VM exactly can't do that, for whatever reason.
I never tried this option. Where exactly is the bootloader installed to then? You need an additional drive for this "removable media path", right? How is it formatted and which file system?

Btw, I completed the guide with a more detailed list of the steps as they are show by the Debian installer.

Many thanks for this!

[sal666]

@MichaIng

I never tried this option. Where exactly is the bootloader installed to then? You need an additional drive for this "removable media path", right? How is it formatted and which file system?

It's installed to the NVRAM of the VM:

Well, EFI itself is installed to sda1, but then a 'hook' is installed to NVRAM.
For me it also should have worked the other way. Sounds like a bug in VirtualBox.

[MichaIng]

@sal666
Okay I read some more info about this, especially the initial bug report on Debian that led to the option to move the bootloader to the removable media path: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746662

The "removable media path" seem to be the default location for EFI bootloaders, on x86_64 systems: /EFI/boot/bootx64.efi on the ESP (EFI system partition)
On our UEFI image, only /EFI/debian/*.efi files exist.
Usually proper UEFI implementations are able to scan all EFI partitions for EFI bootloaders, also on non-default paths, so was the system I created the image on, obviously. However some (in the bug report called "broken") implementations seem to require a bootloader at the default path.

In case of OS installers (e.g. the Debian mini.iso), it makes sense to not copy the bootloader to this path by default, if other OSes are installed already, to not override the existing default bootloader that worked before, e.g. created during an earlier OS install. Windows installs its bootloader to this path by default, which is why usually when one installs Windows besides some Linux dist, the bootloader will not list the Linux distro to boot at first anymore.
Actually best would be, on GRUB install, to check if a bootloader is already stored on that path and, if not, copy it there by default. On the other hand not all systems require this, so this could be further checked, as suggested in the bug report above as well. However currently there is not even checked if the installer was even booted via EFI, before offering to install GRUB to the removable media path 😉.

But as we create whole drive images, including the ESP, it indeed makes sense to copy the bootloader there as well, for compatibility reasons. The 100M partition is much larger than required anyway.
And for VirtualBox it simply seems to be required. I will try to install the UEFI image onto the VM again, but before booting renaming or copying /EFI/debian to /EFI/boot + shimx64.efi to bootx64.efi, which is the secure boot capable loader of GRUB (although not required for VM most likely).

Just a quick question:
The image you uploaded has .7z format, but to be able to flash it via usual tools (e.g. Rufus) it should be either .img or .iso. This also allows us to wrap that image file with hashes and readme into a .7z. Perhaps you can do that faster from the original drive, however I am now doing this by extracting to GPT FAT partition, setting boot flag and creating .img via dd on VM. Lets see if this works.

[sal666]

@MichaIng

Just a quick question:
The image you uploaded has .7z format, but to be able to flash it via usual tools (e.g. Rufus) it should be either .img or .iso.

My .7z is not an image. It's a compilation of Clonezilla Live + a system image taken with Clonezilla.
To create the bootable media you just need to uncompress it to an empty FAT32 pendrive.

[MichaIng]

@sal666
Yeah this is what I thought. However to make it easier for end users and keep the above guide valid, an image file is more familiar?

[sal666]

@MichaIng
Yes it can be distributed as an .iso file. Then it can be dumped with Rufus (to an empty pendrive) or extracted with 7zip (does not format the pendrive).

[MichaIng]

@sal666
Another benefit is that an iso can be easily mounted to any VM while e.g. I cannot see a possibility to boot from a physical pen drive on VirtualBox.

And btw, you were right, after creating the image via dd (and stopping after partition end has been reached) or truncating an existing image file, the GPT partition table needs to be fixed via gdisk. I will adjust DietPi-Imager accordingly to run gdisk as very last step right before hashing.

[sal666]

@MichaIng
ISO files are way easier to mount on a VM, but you can also mount physical devices. Try:
VBoxManage internalcommands createrawvmdk -filename "</path/to/file>.vmdk" -rawdisk /dev/sdb

[MichaIng]

@sal666
Ah yeah that's true, I use the same to mount SDcards to the VMs.

However I created now an iso from it and wrap it together with hashes, the DietPi README.md and install instructions. So we don't need to link users to this issue anymore as all required info is contained in the download archive.

The new installer btw works like a charm 👍. That one can choose the target drive is a great enhancement.
Language and keyboard layout selection is perhaps a bid overkill, where only up+down+return is required 😉, however I guess this is fix part of Clonezilla.

I also managed to boot it on VM now. Indeed copying the grub bootloader to the removable media path (cp -a EFI/debian EFI/boot && cp -a EFI/boot/shimx64.efi EFI/boot/bootx64.efi) was the solution. I will change the HowTo for UEFI image creation, to let the Debian installer do this. However the image is not aimed for VMs, IMO there is really no point in using UEFI on VMs, besides for testing/dev reasons.

[MichaIng]

Okay installer + system tested on two PCs and one VM and works pretty well. Nice job!
Uploaded to server: https://dietpi.com/downloads/images/DietPi_NativePC-UEFI-x86_64-Bullseye.7z
Linked as default download for Native PC UEFI: https://dietpi.com/#download

[sal666]

@MichaIng

Language and keyboard layout selection is perhaps a bid overkill, where only up+down+return is required , however I guess this is fix part of Clonezilla.

In fact no, it could be fixed to one language and keyboard and thus avoid asking the user. It's pretty easy, I'll do it when I'll update dietpi-imager.

[MichaIng]

@sal666
Nice, but really not an issue. Can be simply remembered the next time an image update is required.

[MichaIng]

@sal666
Btw, it would be great if you could add the CloneZilla packaging steps to the HowTo, when you find time: https://github.com/MichaIng/DietPi/wiki/How-to-create-a-DietPi-image-for-x86_64-PCs-(UEFI)#packing-image-with-clonezilla-installer

Probably we could add those steps to DietPi-Imager to be done automatically for EFI images and skip archiving of the raw .img file instead.

For NanoPC T4 we currently offer an AndroidTool based method to write the image to the internal eMMC. But I guess using a CloneZilla bundle, writing to SDcard (or USB flash), booting it from NanoPi and flash to internal eMMC from there, should work as well? So we'd have a shared method for EFI images, also in case other ARMs start to require EFI boot.

[sal666]

@MichaIng
I'm already working on it. Here you'll find a modification to DietPi-Imager to add the generation of the Clonezilla based installer. It's almost finished, but I need to fix the command for the iso file generation and do some testing.
Regarding eMMC, yes Clonezilla can handle it, both for cloning and restoring. I've already done it with my Apollo Lake laptop, which uses eMMC as main storage device.

[sal666]

@MichaIng
I've completed my changes to dietpi-imager. Can you test it before I submit any PR?
Now the installer is only valid for UEFI machines, but it could be extended to also install the BIOS/CSM version.
The code is here.

[MichaIng]

@sal666
Btw. always do changes against the "dev" branch code. It contains some changes that might conflict. However we should be able to resolve.

indeed strange with the missing partimage on Buster. Bullseye again has it: https://packages.debian.org/bullseye/partimage

• Perhaps we can pull and install the Bullseye package, or the one from Stretch.

Currently you basically do all steps in a separate loop. Perhaps we can merge everything in a way that avoids doubled code. However most importantly it works.

Actually since GPT images require an Installer in general, we could go the Clonezilla path automatically if a GPT partition table is detected?

Optionally adding the option to create Clonzilla images as well for BIOS/CSM images is a nice idea as well, which allows easier deployment on eMMC, e.g. if user lacks an adapter.

However all of this is finetuning that can be done when we find time. I will run a test over the weekend.

[sal666]

Btw. always do changes against the "dev" branch code. It contains some changes that might conflict. However we should be able to resolve.

You're right. Will change branch.

indeed strange with the missing partimage on Buster. Bullseye again has it: https://packages.debian.org/bullseye/partimage

• Perhaps we can pull and install the Bullseye package, or the one from Stretch.

Doesn't worth the effort. Now it's working without it because Clonezilla uses partclone as first cloning method. Then partimage and then dd. I've already reported the missing package to the maintainer, hope it gets fixed soon.

Currently you basically do all steps in a separate loop. Perhaps we can merge everything in a way that avoids doubled code. However most importantly it works.

Since they don't share that much code, I was thinking of a separate script, something like dietpi-clonezilla-imager.

Actually since GPT images require an Installer in general, we could go the Clonezilla path automatically if a GPT partition table is detected?

Optionally adding the option to create Clonzilla images as well for BIOS/CSM images is a nice idea as well, which allows easier deployment on eMMC, e.g. if user lacks an adapter.

The resulting iso file is bootable both in UEFI and BIOS/CSM systems. Once completed the BIOS part of the script you'll be able to use it on any of these systems without further checks, just assign the proper name to the image.

[MichaIng]

@sal666

Doesn't worth the effort. Now it's working without it because Clonezilla uses partclone as first cloning method.

Okay indeed does not make sense then, we just pull partclone and good.

Since they don't share that much code, I was thinking of a separate script, something like dietpi-clonezilla-imager.

I will probably switch to shared code by times, where possible. But as said, nothing important. Good to have it in one script IMO to keep it simple.

The resulting iso file is bootable both in UEFI and BIOS/CSM systems. Once completed the BIOS part of the script you'll be able to use it on any of these systems without further checks, just assign the proper name to the image.

Ah okay, that is great. The only thing that limits this, is that the grub-efi needs to be installed for UEFI images, while grub-pc is required for BIOS/CSM images. But it looks like theoretically both can be installed in parallel, so we could create an installer that works on both. But as I like it lightweight, and would go with two separate installer images for now.

Btw I added you to the active contributors list, felt like your regular work on these images needs to be mentioned/honored somewhere: https://github.com/MichaIng/DietPi/blob/dev/README.md#sal666
Feel free to open a PR for the DietPi-Imager Clonezilla support.

[GvY85]

Hi, is it me or is the link for the Native PC (UEFI) link on dietpi.com -> download wrong?
Both Bios and UEFI seem to link to https://dietpi.com/downloads/images/DietPi_NativePC-BIOS-x86_64-Bullseye.7z.
In case of UEFI (Z83-II mini pc with emmc in my case) shoudnt it be https://dietpi.com/downloads/images/DietPi_NativePC-UEFI-x86_64-Bullseye_Installer.7z?

(ps. Great work on DietPi in general, absolutely love it so thank you for all the hard work)

[MichaIng]

@GvY85
You are right, something went wrong there. I just fixed it, many thanks for reporting!!

[MichaIng]

I mark this issue as closed now. New image works pretty well.
We'll handle the Clonezilla integration into DietPi-Imager in a separate issue or PR directly.