Yes, I think you’ve found the explanation yourself ^^
Because you installed 1.7.1 directly and haven’t performed any OTA update yet, Slot B is most likely simply unused/unpopulated at the moment.
I would leave it exactly as it is and wait for the next ZimaOS update. When an OTA update becomes available, RAUC should write the new version to Slot B, then change the boot state to something like:
ORDER=B A
B_OK=1
and our GRUB configuration should then boot Slot B automatically.
I’m using a modified BIOS "theBay’ ? which unlocked the optical bay for a hard drive i think. i don’t remember.
So I’ve mostly had success although I have to double check the boot order if I do a reboot as the BIOS keeps moving things around.
Also, the ZimaOS install refused to see my SSD on the SATA connection so as a proof of concept, I moved the SSD SATA to a USB adapter and it was able to install and boot correctly.
Moving it back to the SATA connection was NOT successful so this is where I am stuck.
I’m also having the issue of attempting to rewrite the grub.cfg file and I get this error .
thelab@ZimaOS:~ ➜ $ sudo mount /dev/sda1/GEN7BOOT /tmp/gen7boot
mount: /tmp/gen7boot: fsconfig() failed: /dev/sda1/GEN7BOOT: Can’t lookup blockdev.
dmesg(1) may have more information after failed mount system call.
what am I missing here?
any guidance would be appreciated. thank you
You actually have two separate issues here.
First, the mount command is just using the wrong syntax.
This:
sudo mount /dev/sda1/GEN7BOOT /tmp/gen7boot
is invalid. /dev/sda1 is the block device, while GEN7BOOT is presumably its filesystem label.
First check:
lsblk -o NAME,SIZE,FSTYPE,LABEL,PARTLABEL,MOUNTPOINTS
Then either mount the partition directly:
sudo mkdir -p /tmp/gen7boot
sudo mount /dev/sda1 /tmp/gen7boot
or, if the label really is GEN7BOOT, use:
sudo mkdir -p /tmp/gen7boot
sudo mount /dev/disk/by-label/GEN7BOOT /tmp/gen7boot
The SSD issue is probably unrelated to GRUB.
Since ZimaOS can see and install to the SSD through USB, but cannot see it when connected to the internal ODD SATA port, I would check the modified BIOS SATA settings first.
On the N54L modified BIOS, check:
Chipset
- South Bridge Configuration
- SB SATA Configuration
OnChip SATA Channel = Enabled
SATA IDE Combined Mode = Disabled
SATA EPS on all PORT = Enabled
SATA Power on all PORT = Enabled
Then under:
Advanced
- IDE Configuration
check:
SATA Controller Mode = AHCI
Embedded SATA Link Rate = Auto
SATA IDE Combined Mode = Disabled is important cause it enables AHCI on SATA ports 4 and 5, including the ODD port
After changing that, check whether the SSD appears in the BIOS AHCI configuration before trying ZimaOS again.
If the BIOS can see the SSD on the ODD port but ZimaOS still cannot, please post:
lsblk -o NAME,SIZE,MODEL,TRAN
and:
dmesg | grep -iE 'ahci|ata|sata'
and we can go from there.
I would still keep GRUB on the internal USB/SD rather than rely on the ODD SSD itself as the BIOS boot device. Once the SATA port is working correctly, GRUB can boot ZimaOS from the SSD
So your instructions about the BIOS were spot on and allowed me to boot into ZimaOS on the SSD connected to the ODD connection.
I continued with the rest of the instructions and they appears to work well also.
The reboot was going well until I reach the Custom Grub boot menu
All 4 slot options result in the error message
error: net/net.c:grub_net_open_real:1580:disk ‘,gpt2’ not found
I assumed I had a typo somewhere but I’ve checked.
I also don’t know how to roll back to the original CFG file
edit: gtp to gpt [typo]
Sorry for that.. But it’s not a very bad news, your ZimaOS installation should still be fine. This looks like a problem in the custom GRUB config, not ZimaOS itself.
The error:
disk ',gpt2' not found
tells us that the $boothd variable is empty. GRUB is trying to access:
(,gpt2)
instead of something like:
(hd0,gpt2)
Also, if your error really says gtp2 rather than gpt2, check the config carefully because it must be gpt2, gpt3, gpt4, etc.
First, we have to boot ZimaOS again :
At the custom GRUB menu press c to get the GRUB command line and enter:
insmod part_gpt
insmod fat
insmod search
insmod search_fs_file
insmod configfile
search --no-floppy --file --set=zima /EFI/BOOT/grub.cfg
echo $zima
echo $zima should return something similar to:
hd1,gpt1
If it does, continue with:
set root=$zima
configfile ($zima)/EFI/BOOT/grub.cfg
That should load the original ZimaOS GRUB configuration and allow you to boot ZimaOS again. It doesn’t modify anything permanently.
Then let’s identify why boothd is empty
Before changing the config again, you can also test this directly from the GRUB command line:
search --no-floppy --file --set=zboot /EFI/BOOT/grubenv
echo $zboot
regexp --set 1:boothd '(.+),.+' $zboot
echo $boothd
We expect something like:
zboot=hd1,gpt1
boothd=hd1
Please post what those two echo commands return.
Once we know that, we can correct the permanent config without reinstalling anything 
First off, Thank you.
You have been informative, responsive and helpful which is so rare to find online.
Please hear (read) this and know you are appreciated.
now to business,
Yes that was a typo on my part in the post (not the cfg file), I don’t have a good way to copy and paste from the MicroServer yet.
echo $zima DID return " hd1,gpt1 " and I was initially able to boot int ZIMA
and after I had zima reboot back to the custom Grub cfg
echo $zboot returned " hd1,gpt1 "
and
echo $boothd returned " hd1 "
So with your help, I’ve gotten very close but I’m still missing something.
Thank you, and that result is actually very useful.
Since :
zboot = hd1,gpt1
boothd = hd1
both work manually, the SSD detection and the regexp itself are fine.
The problem seems to be that boothd is no longer available when the actual menuentry is executed. That explains why GRUB tries to open:
(,gpt2)
instead of:
(hd1,gpt2)
Rather than relying on those variables being carried into the menu entry, I think the safest fix is to detect the ZimaOS disk again inside each menu entry.
First boot ZimaOS using the original config as you already did, then mount your GEN7BOOT device and make a backup:
sudo mkdir -p /tmp/gen7boot
sudo mount /dev/disk/by-label/GEN7BOOT /tmp/gen7boot
sudo cp /tmp/gen7boot/boot/grub/grub.cfg \
/tmp/gen7boot/boot/grub/grub.cfg.before-menu-fix
Then edit:
sudo nano /tmp/gen7boot/boot/grub/grub.cfg
We’ll keep the A/B logic at the top of the file, but replace the four menuentry blocks. Then replace entire file by :
set timeout=3
set default=99
insmod part_gpt
insmod fat
insmod search
insmod search_fs_file
insmod loadenv
insmod regexp
insmod probe
insmod linux
# ------------------------------------------------------------
# Find the ZimaOS boot partition
# ------------------------------------------------------------
search --no-floppy --file --set=zboot /EFI/BOOT/grubenv
if [ -z "$zboot" ]; then
echo "ERROR: ZimaOS boot partition not found."
echo "Press any key to continue..."
read
fi
# ------------------------------------------------------------
# Load ZimaOS / RAUC A-B state
# ------------------------------------------------------------
set ORDER="A B"
set A_OK=0
set B_OK=0
set A_TRY=0
set B_TRY=0
set MACHINE_ID=""
load_env --file=($zboot)/EFI/BOOT/grubenv \
ORDER A_OK B_OK A_TRY B_TRY MACHINE_ID
# ------------------------------------------------------------
# Select the preferred boot slot
# ------------------------------------------------------------
for SLOT in $ORDER; do
if [ "$SLOT" == "A" ]; then
INDEX=0
OK=$A_OK
TRY=$A_TRY
fi
if [ "$SLOT" == "B" ]; then
INDEX=1
OK=$B_OK
TRY=$B_TRY
fi
if [ "$OK" -eq 1 -a "$TRY" -lt 3 ]; then
set default=$INDEX
# Increment boot attempt counter
if [ "$TRY" -eq 1 ]; then
TRY=2
elif [ "$TRY" -eq 2 ]; then
TRY=3
else
TRY=1
fi
if [ "$SLOT" == "A" ]; then
A_TRY=$TRY
fi
if [ "$SLOT" == "B" ]; then
B_TRY=$TRY
fi
break
fi
done
# ------------------------------------------------------------
# If no normal slot is bootable, select rescue mode
# ------------------------------------------------------------
if [ "$default" -eq 99 ]; then
if [ "$A_OK" -eq 1 ]; then
set default=2
fi
if [ "$B_OK" -eq 1 ]; then
set default=3
fi
fi
# Save boot attempt counters back to the REAL ZimaOS grubenv
save_env --file=($zboot)/EFI/BOOT/grubenv \
A_TRY A_OK B_TRY B_OK ORDER MACHINE_ID
# ============================================================
# SLOT A
# ============================================================
menuentry "ZimaOS Slot A (OK=$A_OK TRY=$A_TRY)" {
# Find ZimaOS again inside the menu entry
search --no-floppy --file --set=zboot /EFI/BOOT/grubenv
# zboot is something like hd1,gpt1
# Extract only hd1
regexp --set 1:boothd '(.+),.+' ${zboot}
# Find RootFS A PARTUUID dynamically
probe --set=root_uuid --part-uuid (${boothd},gpt3)
# Load machine ID
set MACHINE_ID=""
set boot_condition=""
load_env --file=($zboot)/EFI/BOOT/grubenv MACHINE_ID
if [ "$MACHINE_ID" == "" ]; then
set boot_condition="systemd.condition-first-boot=true"
fi
set default_cmdline="rootwait net.naming-scheme=v250 systemd.machine_id=$MACHINE_ID fsck.repair=yes $boot_condition"
linux (${boothd},gpt2)/bzImage \
root=PARTUUID=$root_uuid \
$default_cmdline \
rauc.slot=A
}
# ============================================================
# SLOT B
# ============================================================
menuentry "ZimaOS Slot B (OK=$B_OK TRY=$B_TRY)" {
search --no-floppy --file --set=zboot /EFI/BOOT/grubenv
regexp --set 1:boothd '(.+),.+' ${zboot}
# Find RootFS B PARTUUID dynamically
probe --set=root_uuid --part-uuid (${boothd},gpt5)
set MACHINE_ID=""
set boot_condition=""
load_env --file=($zboot)/EFI/BOOT/grubenv MACHINE_ID
if [ "$MACHINE_ID" == "" ]; then
set boot_condition="systemd.condition-first-boot=true"
fi
set default_cmdline="rootwait net.naming-scheme=v250 systemd.machine_id=$MACHINE_ID fsck.repair=yes $boot_condition"
linux (${boothd},gpt4)/bzImage \
root=PARTUUID=$root_uuid \
$default_cmdline \
rauc.slot=B
}
# ============================================================
# SLOT A - RESCUE
# ============================================================
menuentry "ZimaOS Slot A - Rescue" {
search --no-floppy --file --set=zboot /EFI/BOOT/grubenv
regexp --set 1:boothd '(.+),.+' ${zboot}
probe --set=root_uuid --part-uuid (${boothd},gpt3)
set MACHINE_ID=""
set boot_condition=""
load_env --file=($zboot)/EFI/BOOT/grubenv MACHINE_ID
if [ "$MACHINE_ID" == "" ]; then
set boot_condition="systemd.condition-first-boot=true"
fi
set default_cmdline="rootwait net.naming-scheme=v250 systemd.machine_id=$MACHINE_ID fsck.repair=yes $boot_condition"
linux (${boothd},gpt2)/bzImage \
root=PARTUUID=$root_uuid \
$default_cmdline \
rauc.slot=A \
systemd.unit=recovery.target
}
# ============================================================
# SLOT B - RESCUE
# ============================================================
menuentry "ZimaOS Slot B - Rescue" {
search --no-floppy --file --set=zboot /EFI/BOOT/grubenv
regexp --set 1:boothd '(.+),.+' ${zboot}
probe --set=root_uuid --part-uuid (${boothd},gpt5)
set MACHINE_ID=""
set boot_condition=""
load_env --file=($zboot)/EFI/BOOT/grubenv MACHINE_ID
if [ "$MACHINE_ID" == "" ]; then
set boot_condition="systemd.condition-first-boot=true"
fi
set default_cmdline="rootwait net.naming-scheme=v250 systemd.machine_id=$MACHINE_ID fsck.repair=yes $boot_condition"
linux (${boothd},gpt4)/bzImage \
root=PARTUUID=$root_uuid \
$default_cmdline \
rauc.slot=B \
systemd.unit=recovery.target
}
Then:
sync
sudo umount /tmp/gen7boot
sudo reboot
This time each menu entry independently finds hd1, so it shouldn’t matter whether GRUB preserved the previous $boothd variable or not.
If anything goes wrong, you still have the backup. Boot ZimaOS using the original config again and restore it with :
sudo mkdir -p /tmp/gen7boot
sudo mount /dev/disk/by-label/GEN7BOOT /tmp/gen7boot
sudo cp /tmp/gen7boot/boot/grub/grub.cfg.bak \
/tmp/gen7boot/boot/grub/grub.cfg
sync
sudo umount /tmp/gen7boot
We’re definitely getting close : your test proves the difficult part, finding ZimaOS on the ODD SATA disk, is working correctly.
I broke it some how 
All your instructions and config were Spot on and I had been able to Boot and login into Zima cleanly.
I proceeded with an upgrade to 1.8.1-beta and it rebooted without issue (although i don’t think A upgraded also, Only B ?)
Anyway, I proceeded to install the 4 HDD in slots 1 through 4 and create a RAID5
It struggled a little bit and I ended up having to delete reset and restart the RAID config (but it didn’t involve the ZimaOS SSD connected to the ODD)
When it finished ‘Silvering’, I rebooted again and now I’m getting stuck at the GRUB menu.
Errors:
commands/search:c:grub_search_fs-File:371:no such device /EFI/BOOT/Grubenv
commands/regexp.c:grub_cmd_regexp:113:two arguments expected
net/net.c:grub_net_open_real:1580:disk ‘,gpt3’ not found
net/net.c:grub_net_open_real:1419:no server is specified
net/net.c:grub_net_open_real:1580:disk ‘,gpt2’ not found
Attempting commands from earlier in the thread result is
error: commands/search.c:grub_search_fs_file:371:no such device: /EFI/BOOT/grub.cfg
Same for /EFI/BOOT/grubenv
So I’m tempted to just rebuild the ZimaOS SSD but I just purchased the Zima+ lifetime subscription and If i rebuild I don’t think I can reapply the activation without Zima support assistance. ??
I’ve done a bit of testing on the SSD and I think I may have delete the OS install some how but I’m not ready to rebuild it yet.
I was able to install ZimaOS on a spare SSD with the same method and everything worked nicely including the dual zimaOS update (so that IS working)
SO really now my big concern is getting the Activation BACK so I can create a 4x3T RAID5
First: don’t rebuild the ZimaOS SSD yet. I think we should rule out a much simpler explanation first.
Also, what you saw after upgrading to 1.8.1-beta is normal. ZimaOS/RAUC updates the inactive slot only. So if you were running A, the update was written to B and B became active. A stays on the previous version as the fallback. The fact that it rebooted correctly into the update is actually good news : it confirms the A/B GRUB setup was working.
Your new problem started immediately after installing the four HDDs, and GRUB now says it cannot find either:
/EFI/BOOT/grubenv
/EFI/BOOT/grub.cfg
That does not necessarily mean the ZimaOS SSD was erased. It may simply mean GRUB can no longer see the ODD SATA SSD now that all four front SATA bays are populated.
Power the server off and temporarily remove/disconnect the four RAID HDDs again.
Leave only:
GEN7BOOT SD/USB
ZimaOS SSD on the ODD SATA port
Then boot.
If ZimaOS boots again, your SSD is fine and we know this is a SATA/GRUB visibility issue caused by adding the four drives.
At the GRUB menu press c, then run:
insmod ahci
insmod ata
insmod part_gpt
insmod fat
ls
search --no-floppy --file --set=zboot /EFI/BOOT/grubenv
echo $zboot
If it suddenly returns something like:
hd5,gpt1
then we have found the problem. We can simply add:
insmod ahci
insmod ata
near the top of your permanent grub.cfg, before the search commands.
Boot SystemRescue/Rescuezilla and run:
lsblk -o NAME,SIZE,MODEL,TRAN,FSTYPE,PARTLABEL,PARTUUID,LABEL
Please post the result before formatting or reinstalling anything.
On the ZimaOS SSD we should still see partitions similar to:
casaos-boot
casaos-kernel0
casaos-system0
casaos-kernel1
casaos-system1
Rebooting without RAID Drives
results
Error: commanfs.search.c:grub_search_fs_files:371:no such device: /EFI//BOOT/grubenv
error: ZimaOS boot partition not found
insmod ahci
insmod ata
insmod part_gpt
insmod fat
ls
error :net/net.c.grub_net_open_rea;:1580:disk ‘hd0,msdos1’ not found
search --no-floppy --file --set=zboot /EFI/BOOT/grubenv
error: commands/search.c:grub_search_fs_file:371:no such device: /EFI/BOOT/grubenv
echo $zboot
[nothing returned]
lsblk -o NAME,SIZE,MODEL,TRAN,FSTYPE,PARTLABEL,PARTUUID,LABEL
returns
NAME SIZE MODEL TRAN FSTYPE PARTLABEL PARTUUID LABEL
loop0 1.1g squashfs
sda 476.9G MTFDD.. SATA
sdb 59.6G USB 3.0 usb
sdb1 59.6G vfat 12c076b3-01 RESCUE1302
SDA = 512 MICRON SSD drive
SDB = 64G PNY flash drive
I also ran this test on the second SSD drive that I mentioned in the previous post.
And the results were as you had suspected/hoped.
So I’m pretty sure I accidentally deleted the original SSD.
Since I hadn’t configured anything except the Lifetime license, I don’t mind starting again.
Just annoying.
Yes, unfortunately I think your conclusion is correct.
The important part of your lsblk output is:
sda 476.9G MTFDD... sata
with no sda1, sda2, etc. underneath it.
A normal ZimaOS disk should have several GPT partitions (casaos-boot, casaos-kernel0, casaos-system0, etc.), so it looks like the partition table on that SSD has indeed been wiped.
The good news is that your test with the second SSD confirms that the Gen7 + ODD SATA + custom GRUB method itself is working, including the A/B update mechanism.
If you want one final confirmation before reinstalling, you can run:
sudo fdisk -l /dev/sda
sudo wipefs -n /dev/sda
If fdisk shows no partitions, I wouldn’t spend much more time trying to recover it since you didn’t have any data/configuration on that SSD yet.
I would reinstall ZimaOS on it, but this time keep the four RAID drives disconnected until:
Then shut down and reconnect the four HDDs.
Regarding the Lifetime ZimaOS+ license, I would first reinstall and try activating it normally on the same server. If ZimaOS refuses because the previous installation is still registered, contact support with your purchase details and, if you have it, the previous Device ID. I definitely would not buy another Lifetime license before asking support to restore/reset the existing activation.
Annoying, yes — but at least we’ve now confirmed that the actual boot method works correctly on your N54L, including switching between the ZimaOS A/B slots 
And thanks for testing all of this : your N54L results are useful because they confirm the same method can be adapted to Gen7, not just Gen8.
Once again I want to thank you for your time and patience in helping me get my N54L online with ZimaOS. IceWhale did issue a replacement activation code and I have rebuilt the RAID5 array.
A couple of notes that maybe you can comment on:
I find there is a significant LAG in the UI when i open the Storage settings window and again when I drill into the actual RAID. I am using 4x 3T Mechanical Drives
Do you find the same delay?
I also notice the System CPU gauge varies wildly between as low as 20% and as high as 85% without actual activity going on.
Both the Network Monitor and CPU/RAM views result in a blank screen, This is/was not the case with my previous ZimaOS build on an HP EliteDesk 800 G3 Mini
Lastly and this is more Opinion that I’m asking of you. I have a DAS device with a 4T RAID0 which offers both USB3 and eSATA connectivity. The N54L also has both connection options. The DAS has an independent power supply.
Which is the better choice for permeant use?
thanks again.
You’re welcome Great news about the replacement activation code and the RAID5 rebuild
A few thoughts on the other things you noticed:
1. Storage UI lag
I would expect the N54L to feel noticeably slower than your EliteDesk 800 G3. The N54L only has a dual-core AMD Turion II Neo N54L at 2.2 GHz, so the ZimaOS web UI and storage services have much less CPU available.
The Storage page can also be relatively expensive because ZimaOS queries disk/SMART information when loading storage details. There is even a current ZimaOS issue where storage queries can become very slow while waiting for disk health polling. With four mechanical drives plus RAID, some delay would therefore not surprise me.
That said, 20–85% CPU while apparently idle sounds worth investigating rather than assuming it is normal.
Could you run:
uptime
top -b -n1 | head -25
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -15
preferably when the dashboard is showing high CPU usage? That should tell us whether it is real CPU activity or just the ZimaOS gauge behaving strangely.
Also, if the RAID has only recently finished rebuilding, I would give it some time before judging idle behaviour.
Unfortunately, the N54L CPU isn’t really upgradeable in the normal sense because it is soldered directly to the motherboard.
If you’re planning to keep the N54L long-term and run more and more applications on it, though, there is another route. Some users have reused the N54L chassis and fitted a modern Intel N100-based Mini-ITX motherboard inside it.
That gives you a much faster CPU, modern UEFI support, and much lower power consumption than a traditional desktop CPU, while still keeping the nice 4-bay MicroServer case.
So I wouldn’t spend much effort trying to replace the original N54L processor itself. For a long-term upgrade project, an N100 motherboard conversion is probably much more worthwhile.
2. Blank CPU/RAM and Network Monitor pages
Since the server itself is working, I suspect either a ZimaOS UI/telemetry compatibility issue with this older hardware. ZimaOS officially supports generic x86-64 hardware, but there are still reports/requests around some Zima-specific UI features not behaving correctly on non-Zima hardware.
You can quickly confirm that Linux itself sees the information correctly:
free -h
cat /proc/loadavg
cat /proc/net/dev
If those look normal while the web graphs remain blank, I would consider it a ZimaOS UI issue rather than an N54L hardware problem.
3. DAS: USB 3 or eSATA?
For permanent use, I would personally choose eSATA, provided the DAS is detected reliably and presents its RAID volume correctly.
The N54L has a native rear eSATA Gen2 port. Its original onboard USB ports are actually only USB 2.0, so if you have USB 3.0 on yours it must be coming from an added PCIe controller.
For a permanently attached SATA DAS, eSATA has a few advantages:
USB 3 can theoretically be faster than the N54L’s eSATA Gen2, but for a NAS I would favour reliability over a benchmark difference.
One caveat: if your DAS depends on an eSATA port multiplier to expose several individual disks, we should check compatibility first. If the DAS performs RAID0 internally and exposes one logical disk to the N54L, then eSATA would definitely be my first choice.
4x3T RAID5 is working nicely finally. It just needed TIME Lots of Time.
The Lag in the UI is greatly reduced now that the RAID5 has finished doing … whatever.
You are correct it is USB2.0 not 3.0, My DAS does present a single Drive when in RAID0 and I have switched to eSATA which Zima sees as another HDD (not USB or RAID)
I haven’t used the two PCIe Slots.
What are some good addons to extend the functionality of the N54L ?
Looks like some options would be:
multi port USB 3.0
WIFI network
NVMe single or dual drive
Network card for more than 1G
anything else useful for ZimaOS setup ?