Dietpi: Need help with x86 install / boot

[GitHubGeek]

Required Information

• DietPi version | DietPi_NativePC-BIOS-x86_64-Buster.img DATE: Thu Aug 6 20:37:29 CEST 2020
• SBC model | Thecus N8800PRO - Core 2 Duo, 4GB RAM NAS device
• SDcard used | Lexar USB drive 16GB

Steps to reproduce

1. Flash dietpi on USB drive using Etcher
2. Remove existing DOM drive from Thecus
3. Insert USB on Thecus and boot (No change to dietpi.txt)
4. Successfully boot
5. Set up dietpi over SSH; Accept defaults and finish setup
6. Reboot when prompted by setup

Expected behaviour

• Reboot should work, boot into dietpi

Actual behaviour

• Failed to boot into dietpi

Extra details

• After reboot, there's lots of USB drive activitiy (LED on USB drive flashing continously)
• Serial console (COM port) on Thecus seems to have no output
• Thecus doesn't have VGA out, cannot see what's preventing boot
• Tried a different SanDisk USB drive, same result
• Re-flash dietpi on the same USB drive, and device can boot into setup again

[Joulinar]

Hi,

Many thanks for your message. Any error message on screen once reboot failed?

[GitHubGeek]

Thanks for the quick reply. Unfortunately the device doesn't have VGA out

[Joulinar]

Hmm hard to investigate as we don't know what's going on. Maybe you are impacted by this #3700 and #3703

Do you see any GRUB installation/ update during first run of DietPi?

[GitHubGeek]

Didn't pay attention to the messages during install 😆 I saw in #3700 the x86 images were updated few hours ago. I might give the new image a shot, thanks.

[Joulinar]

Pls watch messages during installation.

[GitHubGeek]

Just downloaded DietPi_NativePC-BIOS-x86_64-Buster.7z again. Still the old build from Thu Aug 6 20:37:29 CEST 2020.

[GitHubGeek]

Checked dietpi-firstrun-setup.log on the USB drive - No mention of grub.

After some googling, I suspect intel-microcode might be the culprit. Is there a way to disable microcode update altogether during dietpi setup?

[MichaIng]

Thu Aug 6 20:37:29 CEST 2020

Jep that is the current image that has the new grub already installed and debconf entry fixed for future grub updates (although Debian is working on the issue).

Hmm, the setup checks for AMD or Intel CPU and automatically installs the related microcode package. Your server is Intel definitely, hence would be bad if the "correct" microcode package breaks it. Something to report to Debian bug tracker then, although AFAIK the microcode is provided by Intel directly.

Before removing the part from the code that does the microcode install (/boot/dietpi/dietpi-software, search for intel-microcode), it's probably easier to manually purge the package before rebooting? If you do not select any software on the prompt but do a minimal setup first, no automated reboot should be triggered. If you do, during the "3 seconds" you can hit ctrl+c to exit the script and prevent reboot by this. Then apt purge intel-microcode.

[Joulinar]

what about to cancel the inital setup asap once login via SSH first time. Than run apt update && apt list --upgradable to check for available packages. Probably to set apt-mark hold intel-microcode if available

[MichaIng]

Those packages are not pre-installed, instead dietpi-software installs them explicitly at the end of firstrun setup, which overrides any package hold state. As long as one does not want to manipulate the code, the package needs to be purged afterwards: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-software#L14860-L14864

[GitHubGeek]

Used /boot/Automation_Custom_Script.sh and successfully removed intel-microcode. However, it's not the culprit...

Ran out of ideas. I'll park this for now as the device also have quite high idle power draw.

[MichaIng]

/boot/Automation_Custom_Script.sh

Totally forget about this one, jep much better solution for such a tast.

However, it's not the culprit...

Good on the one hand that those microcodes are fine, bad that we don't know whats breaking boot during firstrun setup. Since the image is new, there should be not many package upgrades involved.

One could have a look into the firstboot script: https://github.com/MichaIng/DietPi/blob/master/rootfs/var/lib/dietpi/services/dietpi-firstboot.bash
But I don't see something that would break it, as long as network is setup, in case of WiFi at best before first boot so that modules are never blacklisted in the first place. To be true I'm currently not sure if there is a getty active on any serial console on the new image, bot that does not influence boot/kernel messages, only the possibility to login via serial console.

[MichaIng]

I mark this as closed. Feel free to reopen if issue persists.