Cannot flash BalenaOS onto HP Proliant Server

I’m trying to flash balenaOS onto an HP Proliant DL380 server. I have flashed a USB with a dev image for my application and I can boot into the grub menu for the flasher, but the server will reboot before the flashing process is finished. After rebooting, the system is not running balena.

This is the last output before the system reboots when I use a production image that I built from scratch:

When I use a development image from the Add device button on my Balena application, I can get into the root terminal and have enough time to run one command before the device reboots. I ran systemctl status resin-init-flasher and it seemed to be running normally.

Does anyone have experience trying to flash Balena on an HP Proliant server? I’m not sure if there are some HP-specific details that are tripping me up.

Hello, we’ve responded with the correct step in the other thread you opened.

Thanks for your reply at Burning a USB drive with VMware ISO file - #7 by ab77 !

I tried following your instructions, but maybe I’m missing something. I was able to unwrap the payload image, and I put it on a USB. I then booted from an Ubuntu ISO to serve as my server rescue system. I plugged in an additional USB key with the unwrapped balena image.

My server hard drive is the 240GB SSD. It is all free space.

I then ran the command:

dd if=/media/ubuntu/usb_with_unwrapped_img/unwrapped_img.img  of=/dev/sda bs=4M

and rebooted.

The boot then froze at this error:

Was my procedure incorrect?

Was my procedure incorrect?

Generally yes, but your success will vary greatly depending on the configuration of the hardware, what devices are connected during boot, etc.

You should start again and after writing the image to the boot disk, shell out to terminal and inspect the disk with fdisk /dev/{{dd-disk}} -l. This should should you the layout of the partition table, which should have the standard MBR balenaOS partition table.

If your hardware contains multiple disks, and no hardware RAID, make sure only to write the the first one listen in the BIOS and ensure no bootable/balenaOS partitions exist on the second disk. You should also remove any USB sticks after flashing and rebooting into balenaOS.

1 Like

Running the fdisk command shows what looks like a standard partition table; I’m not sure how to vet this output:

Do you kow how to debug boot issues like this? Should I be looking into systemd? grub settings? Lacking a /dev/ folder is not something I have ever seen before.

@@os I am looking at the screenshot with the snippet of the kernel boot log, and it doesn’t look like balenaOS to me: Jellyfish

Do you think I am right?

Sorry, I don’t think I have a login to Jellyfish. Are you able to post the relevant information here?

Progress: If I try to boot directly from the unwrapped .img file (not by manually flashing with dd), systemd will start, but gets stuck in a loop where it keeps trying to run Getty on tty1:

I can get a systemd shell using here instructions here (Debugging), but I’m not sure what to run for debugging. If I try to run a systemctl status command, it says systemctl is not a recognized command.

Solution, for future readers:

The error /dev/disk/by-state/active doesn't exist or does not contain a /dev in this case meant Balena didn’t have the kernel modules with the drivers for the storage device compiled in the kernel.

Boot into an Ubuntu LiveUSB and run

udevadm info -a -n /dev/YOUR_HARD_DRIVE_NAME | grep DRIVERS

to see a list of the required storage drivers. In this case, the culprit was smartpqi. Enabling that module and building a new Balena image solved that problem.

The second key breakthrough was realizing that the HP watchdog timer was forcing the server to reboot repeatedly. Editing the boot option for the image in GRUB to pass in the kernel parameter modprobe.blacklist=hpwdt (i.e. append it to the GRUB command that starts with linux) helped solve this. The server now connects to the Balena dashboard.

When debugging, the kernel parameters panic=0 vga=normal nomodeset fb=false were necessary to see the kernel error messages.