Community discussions

MikroTik App
 
Marciboy
just joined
Topic Author
Posts: 1
Joined: Sat Mar 19, 2022 2:20 pm

Router OS 7 on UEFI

Sat Mar 19, 2022 2:31 pm

Hi!

How to install ROS7.1.3 on Hyper-V under Gen2 (UEFI Boot)?
Failed to download smoothly.
Need to convert an image file maybe? Or does the Host Server require a BIOS setup?
 
kriszos
just joined
Posts: 23
Joined: Thu Dec 21, 2017 3:08 pm

Re: Router OS 7 on UEFI

Tue May 17, 2022 6:50 pm

I experienced same problem.
It is easy to just instalI RouterOS 7 x86 from iso on uefi capable virtual machine but I wanted to boot use CHR v7 as LXD virtual machine.
It seems that CHR has everything needed to boot via uefi, but its partition table is some kind of Frankenstein between GPT and MBR. Also partition that has efi files on it is formatted as ext2 so it is not in line with UEFI standard which require that EFI files are stored on FAT/16/32 partition. Bellow is a script to correct this issues. I was able to boot it on LXD, qemu/KVM and hyper-v gen2 via uefi. Secure boot is not possible, efi file is not signed by Microsoft.
My script require that you have linux with installed following packages so it can operate and has to be executed with root privileges.
wget
unzip
qemu-img
qemu-nbd
rsync
gdisk
#!/bin/bash
wget --no-check-certificate https://download.mikrotik.com/routeros/7.3beta40/chr-7.3beta40.img.zip -O /tmp/chr.img.zip
unzip -p /tmp/chr.img.zip > /tmp/chr.img
rm -rf  chr.qcow2
qemu-img convert -f raw -O qcow2 /tmp/chr.img chr.qcow2
rm -rf /tmp/chr.im*
modprobe nbd
qemu-nbd -c /dev/nbd0 chr.qcow2
rm -rf /tmp/tmp*
mkdir /tmp/tmpmount/
mkdir /tmp/tmpefipart/
mount /dev/nbd0p1 /tmp/tmpmount/
rsync -a /tmp/tmpmount/ /tmp/tmpefipart/
umount /dev/nbd0p1
mkfs -t fat /dev/nbd0p1
mount /dev/nbd0p1 /tmp/tmpmount/
rsync -a /tmp/tmpefipart/ /tmp/tmpmount/
umount /dev/nbd0p1
rm -rf /tmp/tmp*
(
echo 2 # use GPT
echo t # change partition code
echo 1 # select first partition
echo 8300 # change code to Linux filesystem 8300
echo r # Recovery/transformation
echo h # Hybrid MBR
echo 1 2 # partitions added to the hybrid MBR
echo n # Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N)
echo   # Enter an MBR hex code (default 83)
echo y # Set the bootable flag? (Y/N)
echo   # Enter an MBR hex code (default 83)
echo n # Set the bootable flag? (Y/N)
echo n # Unused partition space(s) found. Use one to protect more partitions? (Y/N)
echo w # write changes to disk
echo y # confirm
) | gdisk /dev/nbd0
qemu-nbd -d /dev/nbd0
echo "script finished, created file chr.qcow2"
to format it to hyper-v format just issue
qemu-img convert -f qcow2 -O vhdx chr.qcow2 chr.vhdx
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1537
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: Router OS 7 on UEFI

Tue May 17, 2022 7:18 pm

@kriszos: thanks for a good piece of engineering, it's a keeper!

@Marciboy, just curious but what's the reason do you need gen2?
 
User avatar
Hominidae
Member
Member
Posts: 316
Joined: Thu Oct 19, 2017 12:50 am

Re: Router OS 7 on UEFI

Wed May 18, 2022 8:53 pm

@kriszos: thanks for a good piece of engineering, it's a keeper!
+1
 
User avatar
mark99i
just joined
Posts: 5
Joined: Sat Jun 20, 2020 12:17 pm

Re: Router OS 7 on UEFI

Wed Sep 13, 2023 2:19 pm

I experienced same problem.
It is easy to just instalI RouterOS 7 x86 from iso on uefi capable virtual machine but I wanted to boot use CHR v7 as LXD virtual machine.
It seems that CHR has everything needed to boot via uefi, but its partition table is some kind of Frankenstein between GPT and MBR. Also partition that has efi files on it is formatted as ext2 so it is not in line with UEFI standard which require that EFI files are stored on FAT/16/32 partition. Bellow is a script to correct this issues. I was able to boot it on LXD, qemu/KVM and hyper-v gen2 via uefi. Secure boot is not possible, efi file is not signed by Microsoft.
My script require that you have linux with installed following packages so it can operate and has to be executed with root privileges.
the original solution.
but there are some problems as a result of using it: when you try to boot into hyper-v gen2, it loads, and even there is external access (mac winbox), but the local console keyboard is not available.
it does not respond to clicks.
in case something goes wrong with the network, it will be impossible to restore via the console
@Marciboy, just curious but what's the reason do you need gen2?
all modern operating systems can be loaded into uefi, consider this one of the stages of standardization: let all virtual operating systems be loaded into uefi, if possible.
there is no reason not to make boot support in uefi.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Thu Sep 19, 2024 9:32 pm

Bellow is a script to correct this issues.
Huge thanks. It helped me out as I've just hit some improvement at a cloud provider where only UEFI boot became possible since I've installed a CHR there the last time. Even better, I've installed CHR 7.14.3 using the script and the console works just fine.
Last edited by sindy on Thu Sep 19, 2024 10:30 pm, edited 1 time in total.
 
Josephny
Forum Veteran
Forum Veteran
Posts: 700
Joined: Tue Sep 20, 2022 12:11 am

Re: Router OS 7 on UEFI

Thu Sep 19, 2024 9:41 pm

Would some kind person explain to those of us far less knowledgeable what exactly is the situation or use-case for installing ROS in this way?

Do I understand correctly that we are talking about installing ROS on a PC (x86 architecture)?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Thu Sep 19, 2024 10:45 pm

CHR is intended for deployment as a virtual machine - where you need a virtualized router you are familiar with rather than a bare Linux for production, or where you need to simulate some complicated setups, or where you just need a Mikrotik router running on a public IP for some training, which was my particular reason to deploy two CHRs today.

The virtualization host may be your Proxmox or another virtualization platform runninng on your old PC at home or on a bare metal in a data center, but you may also install CHR as a virtual server at some cloud provider, where you share the hardware with other customers. In all these cases, the virtualization system emulates also the boot environment; some of them allow both "legacy" BIOS mode and UEFI mode, some only one of them.

As of 7.15.3, the raw image of the CHR you can download from Mikrotik pages is not compatible with the UEFI mode as-is, so the clever script above is required to convert it to a compatible format before deploying it.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Thu Sep 19, 2024 11:16 pm

FWIW, I packaged @kriszos into a GitHub project that run it run a GitHub Action, see here: https://github.com/tikoci/fat-chr

With the GitHub re-packaged CHR disk image with UEFI support going to the "Releases" section on the project. For example, 7.15.3:
https://github.com/tikoci/fat-chr/relea ... 371-custom

But as @sindy notes most platforms do support "Legacy BIOS" options. And, even then... UEFI will work on some platforms — just some EUFI BIOS software cannot use Linux file system in Mikrotik's "stock" disk images.
 
Josephny
Forum Veteran
Forum Veteran
Posts: 700
Joined: Tue Sep 20, 2022 12:11 am

Re: Router OS 7 on UEFI

Thu Sep 19, 2024 11:41 pm

CHR is intended for deployment as a virtual machine - where you need a virtualized router you are familiar with rather than a bare Linux for production, or where you need to simulate some complicated setups, or where you just need a Mikrotik router running on a public IP for some training, which was my particular reason to deploy two CHRs today.

The virtualization host may be your Proxmox or another virtualization platform runninng on your old PC at home or on a bare metal in a data center, but you may also install CHR as a virtual server at some cloud provider, where you share the hardware with other customers. In all these cases, the virtualization system emulates also the boot environment; some of them allow both "legacy" BIOS mode and UEFI mode, some only one of them.

As of 7.15.3, the raw image of the CHR you can download from Mikrotik pages is not compatible with the UEFI mode as-is, so the clever script above is required to convert it to a compatible format before deploying it.
Wow, very cool!

Do I understand correclty that I can take a regular x86 PC, put a few NICs in it and run a virtualized instance of ROS making the entire box a router (or firewall)?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Thu Sep 19, 2024 11:46 pm

Do I understand correclty that I can take a regular x86 PC, put a few NICs in it and run a virtualized instance of ROS making the entire box a router (or firewall)?
Indeed. Mikrotik recommends exactly this approach (a virtualization platform and a CHR on it even if the CHR would be the only VM running there) over the "x86" product that runs on bare metal but may be a bit behind with the network card drivers etc.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Fri Sep 20, 2024 12:10 pm

Yep, essentially the posted bash script makes use of gdisk (a version of it can run also on Windows, if you are not running Linux) by Roderick Smith, which is the defacto standard for checking/correcting/modifying MBR and GPT images or disks:
https://www.rodsbooks.com/gdisk/
and can - among other things - create hybrid MBR's, with - in the words of the Author - are "flaky and dangerous", the related page is aptly titled:
Hybrid MBRs: The Good, the Bad, and the So Ugly You'll Tear Your Eyes Out
https://www.rodsbooks.com/gdisk/hybrid.html
but sometimes they just work. :)


GPT specs are nicely published in the form of a pdf with over 2.200 pages (last time I checked), it is not a surprise that this (or that) manufacturer or software developer managed to create either non-standard setups or - on the opposite - provisions to allow booting from non-standard setups.
In other words when your OS actually boots that can happen for one of these three main reasons:
1) both the image/disk AND the BIOS/UEFI are perfectly standard
2) the image/disk is out of standard BUT the BIOS/UEFI is also allowing some slack or has added features implemented to allow that kind of non-standard
3) the image/disk is out of standard BUT has some added features implemented that workarounds the (standard or non-standard) behaviour of the BIOS/UEFI

Hybrid MBR's is essentially #3 above (non-standard image), but somehow the UEFI manages to boot from a 0x83 partition, so it is at the same time also #2.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Fri Sep 20, 2024 3:18 pm

The issue here is not complicated, @kriszos explains it:
Also partition that has efi files on it is formatted as ext2 so it is not in line with UEFI standard which require that EFI files are stored on FAT/16/32 partition.
So it not really the "hybrid" MBR/GPT disk partitioning that's the issue here... the bigger issue is the disk formatting — basically ext2 file system is not readable by some EUFI BIOSes. See https://uefi.org/specs/UEFI/2.10/13_Pro ... tem-format
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Fri Sep 20, 2024 7:25 pm

Yes and no :shock: , that may (or may not) be the issue (that then could be solved by only creating a FAT32 volume with the boot loader on it), but the script additionally attempts to solve the non-bootable issue by using a hybrid MBR alright, besides the FAT formatting:
(
echo 2 # use GPT
echo t # change partition code
echo 1 # select first partition
echo 8300 # change code to Linux filesystem 8300
echo r # Recovery/transformation
echo h # Hybrid MBR
echo 1 2 # partitions added to the hybrid MBR
echo n # Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N)
echo   # Enter an MBR hex code (default 83)
echo y # Set the bootable flag? (Y/N)
echo   # Enter an MBR hex code (default 83)
echo n # Set the bootable flag? (Y/N)
echo n # Unused partition space(s) found. Use one to protect more partitions? (Y/N)
echo w # write changes to disk
echo y # confirm
) | gdisk /dev/nbd0
It is a workaround, and of the kind "So Ugly You'll Tear Your Eyes Out", but if it works, it works :) .

The current RAW disk image (chr-7.15.3.img.zip) is however seemingly ALREADY (sort of) hybridized, with two 0x83 partitions in the MBR (WITHOUT the protective 0xEE one that GPT prescribes and that gdisk would create as third partition entry) and some BIOS boot code, so there should be no point in running gdisk on it (anymore).

BTW the partitioning is "wrong", gdisk sees an overlap between the (GPT, secondary) partition table and the second partition AND a 1 sector overlap between the first and second partition, so it won't allow writing to it until the issues are fixed. (the MBR partitioning is seemingly just fine)

It is possible that the good Mikrotik guys made these overlaps intentionally to prevent people fiddling with gdisk on it (or maybe they are using some different software that produces this overlap accidentally).

Anyway the "RouterOS Boot" partition is of type "EFI system" with Attribute flag 4 (set field 2, Bios bootable).

But there is no conversion to FAT or FAT32.

It has to be tested if the change of filesystem alone would solve the problem, as the gdisk part of the script won't likely work correctly anymore.

The (GPT) EF (EFI System type) is "filesystem agnostic" and the 0x83 partition type in the MBR should also be irrelevant, as it is a "protective ID, telling Windows "here be lions", as well not connected to the filesystem used.

P.S.: I just found the older 7.14.3 image, and that one is "good" (hence the script can work on it):
7.14.3 (good)

Command (? for help): v

No problems found. 0 free sectors (0 bytes) available in 0
segments, the largest of which is 0 (0 bytes) in size.

Command (? for help): i
Partition number (1-2): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: 7009F6C9-F6E7-884F-B847-90C15779364A
First sector: 34 (at 17.0 KiB)
Last sector: 65569 (at 32.0 MiB)
Partition size: 65536 sectors (32.0 MiB)
Attribute flags: 0000000000000004
Partition name: 'RouterOS Boot'

Command (? for help): i
Partition number (1-2): 2
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 3E1AF678-B766-9E4E-BF6D-A84F74F7DB80
First sector: 65570 (at 32.0 MiB)
Last sector: 258047 (at 126.0 MiB)
Partition size: 192478 sectors (94.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'RouterOS'
vs.
7.15.3 (bad)

Command (? for help): v

Problem: partitions 2 and 1 overlap:
Partition 2: 65570 to 258048
Partition 1: 34 to 65570

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Identified 2 problems!

Command (? for help): i
Partition number (1-2): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: 530D7DB7-E875-CC44-9ABD-7F5CAEC90E75
First sector: 34 (at 17.0 KiB)
Last sector: 65570 (at 32.0 MiB)
Partition size: 65537 sectors (32.0 MiB)
Attribute flags: 0000000000000004
Partition name: 'RouterOS Boot'

Command (? for help): i
Partition number (1-2): 2
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 37D0E30B-6AA9-EF4E-A67A-4770FC37A330
First sector: 65570 (at 32.0 MiB)
Last sector: 258048 (at 126.0 MiB)
Partition size: 192479 sectors (94.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'RouterOS'
P.P.S.: As a curiosity only, the 7.14.3 image has a disk signature (which should mean that it has been mounted/accessed on a Windows system) and "botched" CHS values in the two partitions in the MBR.
These (wrong CHS) is fixed by gdisk when it writes the hybrid MBR (and it also seemingly deletes the disk signature), so it could be part of the reason why the image modified by the script worked (besides the addition of the protective 0xEE partition), it is very rare nowadays that a system would use CHS data, but you never know, on small disks such as this image is, it is a possibility.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Sat Sep 21, 2024 9:05 am

The good news for those who don't want to dive that deep (respect, @jaclaz!) is that an upgrade of an already installed CHR apparently doesn't affect the boot partition. So installing an image of 7.14.3 that has been made acceptable for UEFI using the script (whichever part of it is the actual reason that it works) and then upgrading to 7.15.3 is an easy, field-proven way to work around the 1-sector overlap.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Sat Sep 21, 2024 11:57 pm

Good to know.
I believe that also using the 7.14.3 image as base and replacing/resyncing the files on the two partitions with the 7.15.3 ones should work.

Is there a free environment where the image bootability can be tested?
I made a few tests and the image for 7.15.3 should be fixable through a slightly more complex set of gdisk commands (without needing other more complex approaches like a Hex editor), basically the two partition entries in the MBR are correct (in their LBA part), so it should be possible to use gdisk to translate from the MBR to the GPT, then it is just a matter of correcting the partition type and flags of the first GPT partition and (to be picky/strict) rename the two partitions to their original RouterOS Boot and RouterOS labels.
But the result would need to be tested, there might still be the need of changing manually a few bytes or - maybe easier for scripting - adding a few dd commands.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Sun Sep 22, 2024 11:57 am

Is there a free environment where the image bootability can be tested?
It depends on the local meaning of the symbolic address "there" :D

On Proxmox, you can choose between BIOS and UEFI boot.

According to the OP, a "Gen2" machine in Hyper V means that UEFI boot is used; strictly speaking Hyper-V is not free, but if you already have it, there is no additional cost associated with testing the image.

Similarly, if you create a VPS in a paid environment for a short enough time to just deploy the machine and test whether it boots, if will not be "free" but it will likely cost less than the coffee you'll power yourself up with during the process.

I can offer testing the images on both Proxmox and Hyper-V and, once that proves successful, even in the paid environment, but I suspect the logistics might be a bit complicated.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Sun Sep 22, 2024 3:54 pm

I can offer testing the images on both Proxmox and Hyper-V and, once that proves successful, even in the paid environment, but I suspect the logistics might be a bit complicated.
If you have the time/will to test (before the images), the actual gdisk script on a Linux machine, it's fine, no need to exchange large files.

I am attaching a small Excel spreadsheet with the Original gdisk script, a modified one (with the end result that should be the same as the original script) and a second modified one (that should IMHO be more "correct", as there are a few things that the original script does not do strictly speaking "right", but that shouldn't prevent the bootability).

The backup partition table of a GPT disk should be in theory at the end, not right after the last partition, the 1st script moves it one sector forward and then it places it back where it was (and where it is also on the 7.14.3 image), the 2nd one places it at the end of the disk.

Personally I would move the gdisk script part earlier in the whole script, before the making of the FAT filesystem, i.e. between the
qemu-nbd -c /dev/nbd0 chr.qcow2
and the
rm -rf /tmp/tmp*
as I cannot say if when mounting the qemu-nbd will use the MBR or the GPT, if it uses the first there should be not any difference, if it uses the second the newly created FAT filesystem might have 1 excess sector.

To be even more on the safer side, one could unmount and re-mount the nbd0, to make sure that when the mkfs/rsync happens the mounted image is already corrected.

On one hand (if the re-partitioning from MBR data script works) we are lucky that the good Mikrotik guys made those MBR entries, on the other hand, that image won't ever boot in BIOS as there is not any bootsector/loader, so it makes no sense to have not just a protective MBR EE partition entry for the whole disk, let alone the MBR boot code.

So, I added a third script, that gets rid of the hybrid setup, which is simply not needed (unless there is some UEFI that uses MBR partitions, which is very, very unlikely)

Real purists may want to 00 out the first 180 bytes of the MBR.
You do not have the required permissions to view the files attached to this post.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Sun Sep 22, 2024 4:39 pm

In this context, I cannot see any benefit in testing 50 incremental scenarios just to find the one that makes it work with the minimum number of changes. The amount of CPU that has to be spent on a Linux machine to make the resulting layout "the most correct one" is not a limiting factor here. So if it is scenario #3 that creates such a "most correct" layout, let's use that one alone. So please post one script as a plain text, I'll feed it with the 7.15.3 image and we'll see the outcome.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Sun Sep 22, 2024 7:05 pm

Ah. OK.

In any case the three different scripts may come useful in case there is the need to experiment, should the chosen one fail (for this or that reason).

The script that I believe creates the most correct output is this one (the one called "MODIFIED SCRIPT3 (pure EFI/GPT, NO Hybrid)
" in the spreadsheet):
(
echo 2 # use GPT
echo x # extra functionality
echo e # relocate backup data structures to the end of the disk
echo r # Recovery/transformation
echo f # load MBR and build fresh GPT from it
echo y # Warning! This will destroy the currently defined partitions! Proceed? (Y/N):
echo x # extra functionality
echo a # set attributes
echo 1 #  Partition number (1-2):
echo 2 # Toggle which attribute field (0-63, 64 or <Enter> to exit):
echo   # Toggle which attribute field (0-63, 64 or <Enter> to exit):
echo m # return to main menu
echo t # change partition code
echo 1 # select first partition
echo EF00 # Hex code or GUID (L to show codes, Enter = EF00):
echo c # change a partition's name
echo 1 #  Partition number (1-2):
echo RouterOS Boot # Enter name:
echo c # change a partition's name
echo 2 #  Partition number (1-2):
echo RouterOS # Enter name:
echo w # write changes to disk
echo y # confirm
) | gdisk /dev/nbd0
Features:
1) single 0xEE protective entry in the MBR spanning the whole disk
2) backup partition table at the end of the disk
3) corrected partition sizes
4) partition names and flags made the same as the original
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Sun Sep 22, 2024 10:15 pm

Tested at Proxmox.

With 7.15.3 as a base and your gdisk script #3, after some time of black screen, it said:
ERROR: could not find disk!
Please attach it somewhere else.

I have tried to emulate both SCSI and IDE, no difference.

Since this was my first ever attempt to UEFI-boot a CHR on Proxmox, the next step was 7.14.3 as a base and the original gdisk script by @kriszos - this way it booted allright.

Hence I took 7.14.3 as a base and your gdisk script #3, and the outcome was the same like with 7.15.3 before. So something is not right at least in the script.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sun Sep 22, 2024 10:25 pm

I have "fat-chr" builder at GitHub that uses @krisnos's script to support UTM's native Apple Virtualization support (which requires EFI).

I replaced the script with @jaclaz's version, but that did not work. UTM does not really report errors - so not sure what's wrong - but it does NOT start using @jaclaz newer script. Switching back to @krisnos script, both 7.15.3 and 7.16rc4 work with EFI using the GH built images.

I'm pretty sure @jaclaz may right on the specs ... but the "old" script has worked across few version with EFI - at least with Apple Virtualization (which is VERY picky). I cannot comment about proxmox etc, since you can use regular BIOS in proxmox (although I get @sindy is testing it)...
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Sun Sep 22, 2024 11:26 pm

So we are back to the reason why I made a few slightly different scripts.
The first one is the one that should produce an image most similar to the one as modified by the original script.
I don't have handy a suitable Linux environments right now, not a suitable VM, so I am not able to test the result.
It is entirely possible that something is anyway wrong or incomplete.

@Ammo
What Is strange from your report is that - in theory - the original script should not work at all on the 7.15.3 as gdisk should refuse to write the modifications due to the errors.
Unless the gdisk under Linux writes the changes anyway, and only the Windows version has this check, which would make no sense.
Or the transformation in qcow2 format fixes something that allows gdisk to write the changes, otherwise running the original gdisk script would be the same as not running it, and we would be back to the base issue being solved by just changing the filesystem to FAT.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Mon Sep 23, 2024 12:38 am

@Ammo
What Is strange from your report is that - in theory - the original script should not work at all on the 7.15.3 as gdisk should refuse to write the modifications due to the errors.
I have no idea. As I said, at least for Apple Virtualization EFI, 7.15.3 works with @krisnos's script.
Screenshot 2024-09-22 at 2.29.10 PM.png
Screenshot 2024-09-22 at 2.29.31 PM.png



When it built images using @jaclaz's `gdisk` script, this is what what GitHub Action got for 7.16rc4 - so it finishes something:
2024-09-22 17:02:30 (12.5 MB/s) - ‘/tmp/chr-7.16rc4.img.zip’ saved [40320254/40320254]
mkfs.fat 4.2 (2021-01-31)
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: present

Found valid MBR and GPT. Which do you want to use?
1 - MBR
2 - GPT
3 - Create blank GPT

Your answer: Using GPT and creating fresh protective MBR.

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Command (? for help):
Expert command (? for help): Relocating backup data structures to the end of the disk

Expert command (? for help):
Recovery/transformation command (? for help): Warning! This will destroy the currently defined partitions! Proceed? (Y/N):
Recovery/transformation command (? for help):
Expert command (? for help): Partition number (1-2): Known attributes are:
0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount

Attribute value is 0000000000000000. Set fields are:
No fields set

Toggle which attribute field (0-63, 64 or <Enter> to exit): Have enabled the 'legacy BIOS bootable' attribute.
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or <Enter> to exit):
Expert command (? for help):
Command (? for help): Partition number (1-2): Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): Changed type of partition to 'EFI system partition'

Command (? for help): Partition number (1-2): Enter name:
Command (? for help): Partition number (1-2): Enter name:
Command (? for help):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/nbd0.
The operation has completed successfully.
/dev/nbd0 disconnected
created file chr.qcow2, now back to raw but uncompressed...
created file chr.vmdk too
created file ZIP with raw files (for debuging)
adding: diskfiles/ (stored 0%)
adding: diskfiles/part1/ (stored 0%)
adding: diskfiles/part2/ (stored 0%)
adding: diskfiles/part2/boot/ (stored 0%)
adding: diskfiles/part2/dev/ (stored 0%)
adding: diskfiles/part2/dev/bootpart/
zip warning: file and directory with the same name: diskfiles/part2/dev/bootpart/
adding: diskfiles/part2/dev/bootdev/
zip warning: file and directory with the same name: diskfiles/part2/dev/bootdev/
adding: diskfiles/part2/rw/ (stored 0%)
adding: diskfiles/part2/rw/autorun.scr (stored 0%)
adding: diskfiles/part2/rw/REBOOT (stored 0%)
adding: diskfiles/part2/UPGRADED (stored 0%)
adding: diskfiles/part2/nova/ (stored 0%)
adding: diskfiles/part2/nova/etc/ (stored 0%)
adding: diskfiles/part2/nova/etc/serial (stored 0%)
adding: diskfiles/part2/SHOW_LICENSE (stored 0%)
adding: diskfiles/part2/bin/ (stored 0%)
adding: diskfiles/part2/bin/bash (deflated 61%)
adding: diskfiles/part2/bin/milo (deflated 42%)
adding: diskfiles/part2/var/ (stored 0%)
adding: diskfiles/part2/var/pdb/ (stored 0%)
adding: diskfiles/part2/var/pdb/system/ (stored 0%)
adding: diskfiles/part2/var/pdb/system/image (deflated 1%)
adding: diskfiles/part2/lost+found/ (stored 0%)

zip warning: Not all files were readable
files/entries read: 21 (17M bytes) skipped: 2 (0 bytes)
*** created chr-7.16rc4.uefi-fat for RAW and VMDK

And here is what happens with 7.15.3:
mkfs.fat 4.2 (2021-01-31)
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: present

Found valid MBR and GPT. Which do you want to use?
1 - MBR
2 - GPT
3 - Create blank GPT

Your answer: Using GPT and creating fresh protective MBR.

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Command (? for help):
Expert command (? for help): Relocating backup data structures to the end of the disk

Expert command (? for help):
Recovery/transformation command (? for help): Warning! This will destroy the currently defined partitions! Proceed? (Y/N):
Recovery/transformation command (? for help):
Expert command (? for help): Partition number (1-2): Known attributes are:
0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount

Attribute value is 0000000000000000. Set fields are:
No fields set

Toggle which attribute field (0-63, 64 or <Enter> to exit): Have enabled the 'legacy BIOS bootable' attribute.
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or <Enter> to exit):
Expert command (? for help):
Command (? for help): Partition number (1-2): Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): Changed type of partition to 'EFI system partition'

Command (? for help): Partition number (1-2): Enter name:
Command (? for help): Partition number (1-2): Enter name:
Command (? for help):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/nbd0.
The operation has completed successfully.
/dev/nbd0 disconnected
created file chr.qcow2, now back to raw but uncompressed...
created file chr.vmdk too
created file ZIP with raw files (for debuging)
adding: diskfiles/ (stored 0%)
adding: diskfiles/part1/ (stored 0%)
adding: diskfiles/part2/ (stored 0%)
adding: diskfiles/part2/boot/ (stored 0%)
adding: diskfiles/part2/dev/ (stored 0%)
adding: diskfiles/part2/dev/bootpart/
zip warning: file and directory with the same name: diskfiles/part2/dev/bootpart/
adding: diskfiles/part2/dev/bootdev/
zip warning: file and directory with the same name: diskfiles/part2/dev/bootdev/
adding: diskfiles/part2/rw/ (stored 0%)
adding: diskfiles/part2/rw/autorun.scr (stored 0%)
adding: diskfiles/part2/rw/REBOOT (stored 0%)
adding: diskfiles/part2/UPGRADED (stored 0%)
adding: diskfiles/part2/nova/ (stored 0%)
adding: diskfiles/part2/nova/etc/ (stored 0%)
adding: diskfiles/part2/nova/etc/serial (stored 0%)
adding: diskfiles/part2/SHOW_LICENSE (stored 0%)
adding: diskfiles/part2/bin/ (stored 0%)
adding: diskfiles/part2/bin/bash (deflated 61%)
adding: diskfiles/part2/bin/milo (deflated 42%)
adding: diskfiles/part2/var/ (stored 0%)
adding: diskfiles/part2/var/pdb/ (stored 0%)
adding: diskfiles/part2/var/pdb/system/ (stored 0%)
adding: diskfiles/part2/var/pdb/system/image (deflated 1%)
adding: diskfiles/part2/lost+found/ (stored 0%)

zip warning: Not all files were readable
files/entries read: 21 (17M bytes) skipped: 2 (0 bytes)
*** created chr-7.15.3.uefi-fat for RAW and VMDK
You do not have the required permissions to view the files attached to this post.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Mon Sep 23, 2024 1:08 am

@Ammo
Ok, the Linux version then finds the same errors as the Windows version I tested and after the changes it writes to the image. (Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/nbd0. The operation has completed successfully).
But what is the same output with the original script on 7.15.3?
The errors should prevent gdisk from writing the changes, thus the image before and after running the original gdisk script should remain unchanged.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Mon Sep 23, 2024 3:53 am

The errors should prevent gdisk from writing the changes, thus the image before and after running the original gdisk script should remain unchanged.
Well, you know, it works in UTM+Apple, but got errors with gdisk during build. I re-ran the build just now, and got what's below for @kriszos's script:
2024-09-23 00:37:54 (7.98 MB/s) - ‘/tmp/chr-7.15.3.img.zip’ saved [40110443/40110443]

mkfs.fat 4.2 (2021-01-31)
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: present

Found valid MBR and GPT. Which do you want to use?
1 - MBR
2 - GPT
3 - Create blank GPT

Your answer: Using GPT and creating fresh protective MBR.

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Command (? for help): Partition number (1-2): Current type is EF00 (EFI system partition)
Hex code or GUID (L to show codes, Enter = EF00): Changed type of partition to 'Linux filesystem'

Command (? for help):
Recovery/transformation command (? for help):
WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N):
Creating entry for GPT partition #1 (MBR partition #1)
Enter an MBR hex code (default 83): Set the bootable flag? (Y/N):
Creating entry for GPT partition #2 (MBR partition #2)
Enter an MBR hex code (default 83): Set the bootable flag? (Y/N):
Aborting write operation!
Unused partition space(s) found. Use one to protect more partitions? (Y/N):
Recovery/transformation command (? for help):
Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Problem: partitions 2 and 1 overlap:
Partition 2: 65570 to 258048
Partition 1: 34 to 65570
Aborting write of new partition table.

Recovery/transformation command (? for help): b use backup GPT header (rebuilding main)
c load backup partition table from disk (rebuilding main)
d use main GPT header (rebuilding backup)
e load main partition table from disk (rebuilding backup)
f load MBR and build fresh GPT from it
g convert GPT into MBR and exit
h make hybrid MBR
i show detailed information on a partition
l load partition data from a backup file
m return to main menu
o print protective MBR data
p print the partition table
q quit without saving changes
t transform BSD disklabel partition
v verify disk
w write table to disk and exit
x extra functionality (experts only)
? print this menu

Recovery/transformation command (? for help): /dev/nbd0 disconnected
created file chr.qcow2, now back to raw but uncompressed...
created file chr.vmdk too
created file ZIP with raw files (for debuging)
adding: diskfiles/ (stored 0%)
adding: diskfiles/part1/ (stored 0%)
adding: diskfiles/part1/map (deflated 47%)
adding: diskfiles/part1/EFI/ (stored 0%)
adding: diskfiles/part1/EFI/BOOT/ (stored 0%)
adding: diskfiles/part1/EFI/BOOT/BOOTX64.EFI (deflated 4%)
adding: diskfiles/part1/lost+found/ (stored 0%)
adding: diskfiles/part2/ (stored 0%)
adding: diskfiles/part2/boot/ (stored 0%)
adding: diskfiles/part2/dev/ (stored 0%)
adding: diskfiles/part2/dev/bootpart/
zip warning: file and directory with the same name: diskfiles/part2/dev/bootpart/
adding: diskfiles/part2/dev/bootdev/
zip warning: file and directory with the same name: diskfiles/part2/dev/bootdev/
adding: diskfiles/part2/rw/ (stored 0%)
adding: diskfiles/part2/rw/autorun.scr (stored 0%)
adding: diskfiles/part2/rw/REBOOT (stored 0%)
adding: diskfiles/part2/UPGRADED (stored 0%)
adding: diskfiles/part2/nova/ (stored 0%)
adding: diskfiles/part2/nova/etc/ (stored 0%)
adding: diskfiles/part2/nova/etc/serial (stored 0%)
adding: diskfiles/part2/SHOW_LICENSE (stored 0%)
adding: diskfiles/part2/bin/ (stored 0%)
adding: diskfiles/part2/bin/bash (deflated 61%)
adding: diskfiles/part2/bin/milo (deflated 42%)
adding: diskfiles/part2/var/ (stored 0%)
adding: diskfiles/part2/var/pdb/ (stored 0%)
adding: diskfiles/part2/var/pdb/system/ (stored 0%)
adding: diskfiles/part2/var/pdb/system/image (deflated 1%)
adding: diskfiles/part2/lost+found/ (stored 0%)

zip warning: Not all files were readable
files/entries read: 26 (21M bytes) skipped: 2 (0 bytes)
*** created chr-7.15.3.uefi-fat for RAW and VMDK
The full build script which includes the qemu-img etc commands is here:
https://github.com/tikoci/fat-chr/blob/main/build.bash

The actually .raw image file from that is here: https://github.com/tikoci/fat-chr/relea ... fi-fat.raw

While I have this all automated, I'm not the expert on the needed partitioning - so my basic test is if it works in UTM/Swift with Apple Virtualization. But... I'm a bit curious since the image produced with errors above still works!. Since I go from qcow to raw, maybe something in the process "fixes" something - I really dunno know.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Mon Sep 23, 2024 10:13 am

I also convert the result to raw as I use ceph on Proxmox that does not support qcow2, so the difference in disk image format is not the magic that saves things.

Still using version #3 (I will get to the other ones later), I haven't seen any complaints of gdisk in the log, except the one regarding the 1-sector overlap in case of 7.15.3.

7.14.3:
mkfs.fat 4.2 (2021-01-31)
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: Using GPT and creating fresh protective MBR.

Command (? for help):
Expert command (? for help): Relocating backup data structures to the end of the disk

Expert command (? for help):
Recovery/transformation command (? for help): Warning! This will destroy the currently defined partitions! Proceed? (Y/N):
Recovery/transformation command (? for help):
Expert command (? for help): Partition number (1-2): Known attributes are:
0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount

Attribute value is 0000000000000000. Set fields are:
  No fields set

Toggle which attribute field (0-63, 64 or <Enter> to exit): Have enabled the 'legacy BIOS bootable' attribute.
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or <Enter> to exit):
Expert command (? for help):
Command (? for help): Partition number (1-2): Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): Changed type of partition to 'EFI system partition'

Command (? for help): Partition number (1-2): Enter name:
Command (? for help): Partition number (1-2): Enter name:
Command (? for help):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/nbd0.
The operation has completed successfully.
/dev/nbd0 disconnected
script finished, created file chr-uefi.img
7.15.3:
mkfs.fat 4.2 (2021-01-31)
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: Using GPT and creating fresh protective MBR.

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Command (? for help):
Expert command (? for help): Relocating backup data structures to the end of the disk

Expert command (? for help):
Recovery/transformation command (? for help): Warning! This will destroy the currently defined partitions! Proceed? (Y/N):
Recovery/transformation command (? for help):
Expert command (? for help): Partition number (1-2): Known attributes are:
0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount

Attribute value is 0000000000000000. Set fields are:
  No fields set

Toggle which attribute field (0-63, 64 or <Enter> to exit): Have enabled the 'legacy BIOS bootable' attribute.
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or <Enter> to exit):
Expert command (? for help):
Command (? for help): Partition number (1-2): Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): Changed type of partition to 'EFI system partition'

Command (? for help): Partition number (1-2): Enter name:
Command (? for help): Partition number (1-2): Enter name:
Command (? for help):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/nbd0.
The operation has completed successfully.
/dev/nbd0 disconnected
script finished, created file chr-uefi.img
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Mon Sep 23, 2024 11:35 am

@Ammo
Problem: partitions 2 and 1 overlap:
Partition 2: 65570 to 258048
Partition 1: 34 to 65570
Aborting write of new partition table.
....
Recovery/transformation command (? for help):
/dev/nbd0 disconnected
That is not "an error", it is a "critical error", as it means that the original @kriszos's script doesn't actually do anything (at least on the "wrong" 7.15.3).
Which indirectly means that even if "wrong", the 7.15.3 image needs ONLY the ext2->FAT32 filesystem transformation to be bootable in your environment.

BTW, in your output of the original script, there is also another error besides the "final" one aty the "w" command:
Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N):
Creating entry for GPT partition #1 (MBR partition #1)
Enter an MBR hex code (default 83): Set the bootable flag? (Y/N):
Creating entry for GPT partition #2 (MBR partition #2)
Enter an MBR hex code (default 83): Set the bootable flag? (Y/N):
Aborting write operation!
Unused partition space(s) found. Use one to protect more partitions? (Y/N):

Compare with the output Sindy just posted, last lines are:
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/nbd0.
The operation has completed successfully.
/dev/nbd0 disconnected
Try removing completely the gdisk script from the overall script and try running it on 7.15.3.


@Sindy
Maybe when gdisk runs the first time, it only checks "loosely" the partitioning and finds only the second partition/backup partition table overlap, the other error (overlapping first and second partition is not detected).
Then when it attempts to write the modified version, it does a "v" check and finds both.

EDIT: Confirmed, the first few sectors (the relevant ones, MBR, Efi Part and the two entries in EFI partition tables) are identical between the original chr-7.15.3.img image and the modified raw one chr-7.15.3.uefi-fat.raw, so the original gdisk script does nothing to it.
We have been barking up the wrong tree. :shock:
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Mon Sep 23, 2024 5:39 pm

EDIT: Confirmed, the first few sectors (the relevant ones, MBR, Efi Part and the two entries in EFI partition tables) are identical between the original chr-7.15.3.img image and the modified raw one chr-7.15.3.uefi-fat.raw, so the original gdisk script does nothing to it.
We have been barking up the wrong tree. :shock:
Hmm. If the image works, I never check the build logs... But, yeah, gdisk isn't doing anything from the logs. So I just REMOVED the ANY `gdisk` operation from my script, and the built image still works with UTM+Apple (requiring EFI) - both 7.15.3 and 7.16rc4. And confirmed a Mikrotik-download IMG file does NOT work for same versions on UTM+Apple. So something get changed in my script, even without gdisk.... But I cannot speak to if "Gen2" or other hypervisors do need some different partitioning since I didn't test it.

Below is the relevant part from GitHub, which gets you a EFI+FAT and an uncompressed raw image. I'm pretty sure the gdisk stuff was needed at some point - so I dunno. But seems, at least in 7.15.3 and 7.16rc4, qemu-img conversions must "fix something" for UTM+AppleVM (since there is no `gdisk` in these tests).


ROSVER=7.16rc4
wget --no-check-certificate https://download.mikrotik.com/routeros/$ROSVER/chr-$ROSVER.img.zip -O /tmp/chr-$ROSVER.img.zip
unzip -p /tmp/chr-$ROSVER.img.zip > /tmp/chr-$ROSVER.img
rm -rf  chr-$ROSVER.qcow2
qemu-img convert -f raw -O qcow2 /tmp/chr-$ROSVER.img chr-$ROSVER.qcow2
rm -rf /tmp/chr-$ROSVER.im*

modprobe nbd
qemu-nbd -c /dev/nbd0 chr-$ROSVER.qcow2

rm -rf /tmp/tmp*

mkdir /tmp/tmpmount/
mkdir diskfiles

mkdir /tmp/tmpefipart/
mount /dev/nbd0p1 /tmp/tmpmount/
rsync -a /tmp/tmpmount/ /tmp/tmpefipart/
mkdir diskfiles/part1
rsync -a /tmp/tmpmount/ ./diskfiles/part1/
umount /dev/nbd0p1

mkfs -t fat /dev/nbd0p1
mount /dev/nbd0p1 /tmp/tmpmount/
rsync -a /tmp/tmpefipart/ /tmp/tmpmount/
umount /dev/nbd0p1

mount /dev/nbd0p2 /tmp/tmpmount/
mkdir diskfiles/part2
rsync -a /tmp/tmpmount/ ./diskfiles/part2/
umount /dev/nbd0p2

rm -rf /tmp/tmp*

# ALL GDISK MODS DISABLE
# @kriszos approach
# (
# echo 2 # use GPT
# ...
# echo y # confirm
# ) | gdisk /dev/nbd0
# @jaclaz
# (
# echo 2 # use GPT
# ...
# echo y # confirm
# ) | gdisk /dev/nbd0

qemu-nbd -d /dev/nbd0

echo "created file chr.qcow2, now back to raw but uncompressed..."
qemu-img convert -f qcow2 -O raw chr-$ROSVER.qcow2 chr-$ROSVER.uefi-fat.raw

 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Mon Sep 23, 2024 8:25 pm

Well, the overall script changes anyway the filesystem from ext2/3 to FAT(32), evidently that is the "key" (and compatible with the UEFI requirement).
On PC's, there are UEFI installable drivers (some made by the motherboard manufacturers or the one by P.Batard, the Author of Rufus for NTFS) and very likely there are similar ones for Linux filesystems, but the standard remains FAT, I am not so sure if it precribes FAT generically or FAT32, Microsoft uses FAT32 as their EFI system boot partition is usually huge, between 100 and 500 Mb).
The mkfs - t fat (in the script) uses directly the mounted device, should - I believe - use 65527 sectors as the minimum size, so since the filesystem is 65536 (or 65537 in 7.15.3) it should be FAT32.
And evidently, even if gdisk doesn't "like" them the errors in the GPT do not prevent bootability.
Thinking about it, it is entirely possible as the overlap is only on the last sector of the two partitions, the booting process has no reason to access them, not even to read them, and the fact that there is no protective partition in the MBR is likely irrelevant if the UEFI accesses first the GPT partition table.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Mon Sep 23, 2024 11:22 pm

Thinking about it, it is entirely possible as the overlap is only on the last sector of the two partitions
Just to be sure, did you actually mean that the last sector of one partition overlaps with the first sector of the following one, as in "the first one is one sector larger than it should be" or "the second one is positioned one sector earlier than it should be"?

the booting process has no reason to access them, not even to read them, and the fact that there is no protective partition in the MBR is likely irrelevant if the UEFI accesses first the GPT partition table.
Do I get it right that you assume that the UEFI boot does not care about even the presence, let alone the actual contents, of the backup table if the basic one is available & readable?

After double-checking that the change of file system to FAT alone (without running gdisk at all) is sufficient to make Proxmox UEFI-boot from a 7.15.3 image modified that way, I've tried to go through gdisk manually, reducing both partitions by 1 sector because not only the last sector of the first one (RouterOS boot) overlapped with the first sector of the second one (RouterOS), but also once I tried to create the protective table, I got a complaint that the second partition overlaps with the second copy of the partition table. So the whole gdisk session then looked as follows:
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 2
Using GPT and creating fresh protective MBR.

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Command (? for help): ?
b       back up GPT data to a file
c       change a partition's name
d       delete a partition
i       show detailed information on a partition
l       list known partition types
n       add a new partition
o       create a new empty GUID partition table (GPT)
p       print the partition table
q       quit without saving changes
r       recovery and transformation options (experts only)
s       sort partitions
t       change a partition's type code
v       verify disk
w       write table to disk and exit
x       extra functionality (experts only)
?       print this menu

Command (? for help): i
Partition number (1-2): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition)
Partition unique GUID: 530D7DB7-E875-CC44-9ABD-7F5CAEC90E75
First sector: 34 (at 17.0 KiB)
Last sector: 65570 (at 32.0 MiB)
Partition size: 65537 sectors (32.0 MiB)
Attribute flags: 0000000000000004
Partition name: 'RouterOS Boot'

Command (? for help): d
Partition number (1-2): 1

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-65569, default = 34) or {+-}size{KMGTP}:
Last sector (34-65569, default = 65569) or {+-}size{KMGTP}:
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): c
Partition number (1-2): 1
Enter name: RouterOS Boot

Command (? for help): i
Partition number (1-2): 2
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 37D0E30B-6AA9-EF4E-A67A-4770FC37A330
First sector: 65570 (at 32.0 MiB)
Last sector: 258048 (at 126.0 MiB)
Partition size: 192479 sectors (94.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'RouterOS'

Command (? for help): d
Partition number (1-2): 2

Command (? for help): n
Partition number (2-128, default 2):
First sector (65570-258047, default = 65570) or {+-}size{KMGTP}:
Last sector (65570-258047, default = 258047) or {+-}size{KMGTP}:
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/nbd0: 262144 sectors, 128.0 MiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 3C834E61-1789-A742-80F6-7799E266B0E8
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 258047
Partitions will be aligned on 2-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34           65569   32.0 MiB    8300  RouterOS Boot
   2           65570          258047   94.0 MiB    8300  Linux filesystem

Command (? for help): c
Partition number (1-2): 2
Enter name: RouterOS

Command (? for help): p
Disk /dev/nbd0: 262144 sectors, 128.0 MiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 3C834E61-1789-A742-80F6-7799E266B0E8
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 258047
Partitions will be aligned on 2-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34           65569   32.0 MiB    8300  RouterOS Boot
   2           65570          258047   94.0 MiB    8300  RouterOS

Command (? for help): r

Recovery/transformation command (? for help): h

WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 1 2
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): n

Creating entry for GPT partition #1 (MBR partition #1)
Enter an MBR hex code (default 83):
Set the bootable flag? (Y/N): y

Creating entry for GPT partition #2 (MBR partition #2)
Enter an MBR hex code (default 83):
Set the bootable flag? (Y/N): n

Unused partition space(s) found. Use one to protect more partitions? (Y/N): y
Note: Default is 0xEE, but this may confuse Mac OS X.
Enter an MBR hex code (default EE):

Recovery/transformation command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/nbd0.

Caution: More than one 0xEE MBR partition found. This can cause problems
in some OSes.
The operation has completed successfully.
/dev/nbd0 disconnected
With this, Proxmox UEFI-boots from the result as well, but since it doesn't BIOS-boot from the same image, I figure the hybrid MBR does not serve its purpose and hence there is no point in using it. But I may have it completely wrong and the the BIOS-boot may actually fail be e.g. due to incorrect type of the boot partition. So @jaclaz, apart from commenting on this, can you also suggest the correct way to create a proper GPT-only setup with a backup partition table before trying the resulting image on other virtualization platforms?

A separate can of worms is whether there is any point in full automation of the gdisk actions including partition resizing given that today (7.15.3), the partition sizes are off by 1 sector, and tomorrow (7.x.y) there may be another issue.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Tue Sep 24, 2024 2:33 am

Yes, each partition is one sector bigger in the GPT partition table than in the MBR one.
The two partitions start on both MBR and GPT partition tables on Sector 34 and 65570.
In the GPT the first partition goes then over the second.
The second goes over the space marked as occupied by the backup GPT partition table, that should not be there, but rather at the end of the disk, right before the backup EFI PART sector. The backup Is normally a mirror of the main one, with last sector of the disk being a copy of sector 1, and the preceding 32 sectors a copy - in inverted order - of sectors 2-33 (normally the GPT partition table has 128 entries available, 4 per sector).
For whatever reasons these Mikrotik images place these 32 sectors immediately after the second partition. (this is allowed by the specs, but uncommon)

In practice, the last sector of first partition Is all 00's (as the volume is not filled up to the brim) and the first sector of the second partition Is also all 00's (as it is the empty boot sector of a non-bootable ext2/3 volume).
As well the last sector of the second partition Is all 00's and the (inverted) last sector of the backup GPT partition table Is all 00's.
So these overlaps do not create a real conflict if you take each structure by itself.

No, I meant something different.
In the MBR, lba0, according to GPT specs, there should be only a single partition entry with id 0xEE, spanning over the whole disk, but this Is intended as a protection against older BIOSes and operating systems.
The UEFI ignores the contents of lba0 and reads directly lba1 (EFI PART) and then the following LBA 2-33 (the GPT partition tables).
The Mikrotik images do not have this EE partition entry in the MBR, which confirms that It Is not needed for booting.
But yes, when booting the backup structures are not AFAIK accessed at all, there is not a check for them being the same as the main ones in the booting phase, as long as the data in main make sense and checksums are correct, the UEFI proceeds to boot.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Tue Sep 24, 2024 11:23 am

About BIOS booting, it cannot really work, as some parts are misssing:
1. MBR boot code - check
2. MBR partition entry for the first partition active - check
2. Magic Bytes (55AA) in the MBR - check
3. Boot code in the bootsector - check (to be verified)
5. BPB (Bios Parameter Block) in the bootsector - missing
6. Magic Bytes (55AA) in the bootsector - check
7. bootloader - missing (I have no idea which bootloader was - maybe - originally there, but right now the only file in the first partition is \EFI\BOOT\BOOTX64.EFI)

As a side note I have to correct a previous statement, I just checked the chr-7.15.3.uefi-fat.raw image and the FAT filesytem created by mkfs -fat is FAT16, not FAT32, it is entirely possible that the size at which the automatic switch happens I found is obsolete or refers to another version of mkfs, in any case this confirms that for UEFI booting FAT16 is just fine.

The size of the filesystem is 65536 sectors (right), probably the mkfs is smart enough to not create a filesystem of 65537 sectors (which should be the size of the mounted volume image, if the GPT table is used).
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Tue Sep 24, 2024 5:22 pm

I did file a feature request for an "proper" EFI image for CHR, SUP-144667, earlier this year. I got usual non-comitals "Thank you for the suggestion, we will consider it". So if someone using Hyper-V or other VM platform that needs EFI image to work... I'd recommend filing a ticket at help.mikrotik.com – sometimes the volume of tickets changes the priority.

About BIOS booting, it cannot really work,
But Mikrotik's native images should work in that case. It's just a few EFI BIOS (i.e. HyperV "Gen2", Apple's Virtualization Framework) where there is not an option to use legacy BIOS. Would it be "better" to always use EFI if available...my guess is yes since it's just a more direct path to starting the Linux kernel.

And why Mikrotik should at least look at this whole EFI issue - since some "mkfs -t ext2" to "mkfs -t fat" in THEIR build be a lot easier for everyone. Perhaps that's not the whole story, but AFAIK EFI system partition should be FAT according to the spec....
its partition table is some kind of Frankenstein between GPT and MBR.

Now on GPT... I'm not sure why MBR be so bad in a disk image for RouterOS - it does not have some complex partition scheme. I guess my supposition is that FAT boot + MBR be the "lowest common denominator" for compatibility. Could be wrong... So I'm just not sure what GPT gets us in a simple disk image for an OS with only one boot option (...now on a real system's boot volume, there GPT make sense)
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Tue Sep 24, 2024 9:06 pm

OK, it has been a nightmare (as it often happens) but I found out that the chr-7.15.3.uefi-fat.raw image (thanks Amm0) boots in virtualbox.
A .vmdk descriptor is needed, but it is easy to make:
# Disk DescriptorFile
version=1
createType=
RW 262144 FLAT "chr-7.15.3.uefi-fat.raw" 0
ddb.uuid.image="46AB3892-1E5E-6FDF-64DA-2C2F6B3017B1"
at first boot virtualbox will add the missing data automatically.

By testing (and failing, and re-testing and re-failing) I found out where the issue lies (at least in Virtualbox), the (unexpected) NEEDED requisites are:
1) the two partitions MUST be in the MBR (the presence as third partition of the protective MBR one is irrelevant)
2) the partition ID of the first partition MUST be 83 (the - in theory - more correct EF or 06 or 0E) are not good
#1 above may be a quirk of the VM, the #2 is more likely to be related to something hardcoded in Mikrotik's Bootx64.efi, but cannot really say.

Anyway, this modified script fixes the issues gdisk finds and renders a still bootable image (again at least in Virtualbox), the good thing is that it can be run even on an already "fixed" image:
(
echo 2 # use GPT
echo x # extra functionality
echo e # relocate backup data structures to the end of the disk
echo r # Recovery/transformation
echo f # load MBR and build fresh GPT from it
echo y # Warning! This will destroy the currently defined partitions! Proceed? (Y/N):
echo x # extra functionality
echo a # set attributes
echo 1 #  Partition number (1-2):
echo 2 # Toggle which attribute field (0-63, 64 or <Enter> to exit):
echo   # Toggle which attribute field (0-63, 64 or <Enter> to exit):
echo m # return to main menu
echo t # change partition code
echo 1 # select first partition
echo EF00 # Hex code or GUID (L to show codes, Enter = EF00):
echo c # change a partition's name
echo 1 #  Partition number (1-2):
echo RouterOS Boot # Enter name:
echo c # change a partition's name
echo 2 #  Partition number (1-2):
echo RouterOS # Enter name:
echo x # extra functionality
echo r # Recovery/transformation
echo h # Hybrid MBR
echo 1 2 # partitions added to the hybrid MBR
echo n # Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N)
echo 83 # Enter an MBR hex code (default 83)
echo y # Set the bootable flag? (Y/N)
echo 83 # Enter an MBR hex code (default 83)
echo n # Set the bootable flag? (Y/N)
echo n # Unused partition space(s) found. Use one to protect more partitions? (Y/N)
echo w # write changes to disk
echo y # confirm
) | gdisk /dev/nbd0
Last edited by jaclaz on Tue Sep 24, 2024 9:18 pm, edited 1 time in total.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Tue Sep 24, 2024 9:17 pm

Sorry, double post.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Tue Sep 24, 2024 11:57 pm

Sorry, double post.
I quickly re-factored my CHR builder. So there are now 7.16 images, using the three approaches: @jaclaz's latest (chr-7.15.3.uefi-fat-jaclaz.raw), @kriszos's original (chr-7.15.3.uefi-fat-kriszos.raw), and "no gdisk" (chr-7.15.3.uefi-fat-no-gdisk.raw), see:
https://github.com/tikoci/fat-chr/releases

Kriszos still gets an error, but both "-no-gdisk" and "-jaclaz" version work - at least on UTM+Apple which is my test case.

Anyway, someone can try any of the three versions now. Since it's all a public project, I think other folks can go to https://github.com/tikoci/fat-chr/actio ... anual.yaml and look at the image builder logs under "Run script to download and modify the CHR images" to see the bash/qemu-img/gdisk script running (which is buried, so click on a particular build, then click on "build" with green icon, and you'll see the logs there)
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Wed Sep 25, 2024 1:18 am

Very good :) .
So, as soon as Sindy will be able to (hopefully) report success in the environment(s) he uses, the matter should be pseudo-solved.
Still, if the image (with just the ext2 to Fat16 conversion) works, running the gdisk script makes little sense, once set aside the things we have learned about the "crazy" requirements and the fun we had playing this UEFI Boot detective game, it is essentially an exercise in futility.
And maybe it is not yet the right time to open the can of worms Sindy mentioned, though the approach of the last script is flexible, as essentially it "trusts" the MBR values and rebuilds everything from them, i.e. there is nothing hardcoded about size and location of the partitions and location of the backup GPT partition table.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Thu Sep 26, 2024 11:29 pm

as soon as Sindy will be able to (hopefully) report success in the environment(s) he uses, the matter should be pseudo-solved.
Sorry, it was neither soon nor 100% success.

Both the pre-cooked images from @Amm0 I've tried, i.e. chr-7.16.uefi-fat.raw and chr-7.16.uefi-fat-kriszos.raw, work both in Proxmox and on Hyper-V (not surprisingly, secure boot has to be disabled). But neither of the two images worked at the cloud provider (Vultr) where the 7.14.3 image mangled using the script by @kriszos from post #2 did work fine.

A 7.15.3 image mangled using the same script with the gdisk part disabled works on both Proxmox and Hyper-V as well, but does not work on Vultr. Mangling with the gdisk part of the script enabled is not possible for 7.15.3 due to those wrong partition sizes.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Fri Sep 27, 2024 12:38 am

Yep, but the one you should try Is the third one, 7.15.3 using the last modified gdisk script.
The idea Is that the last posted gdisk script creates (should create) an image functionally identical to the 7.14.3 modified by the full (including gdisk) kriszos script.
Maybe there is still some difference remaining.

In the meantime I did a few (crazy) experiments with the original image to see how (the heck) It can boot (and It does boot) in BIOS mode.
The MBR boot code Is executed and loads the boot code in the boot sector that then loads *something else*.
There is in the loading process some kind of check, so some modifications are not possible as they result in loading errors, but It seems like a few are possible, like adding BPB data that does not break the booting process.
It Is too early to say if these experiments will lead us anywhere but I am (cautiously) optimistic.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Fri Sep 27, 2024 9:36 pm

Ran the 3 image scripts (jaclaz, kriszos, no-gdisk) again with 7.17beta2. Same as 7.16, kriszos script fails in middle because of the "overlap", the other two work. @jaclaz's gdisk script gets to "The operation has completed successfully.". Apple requires only FAT, so all three work. The 3 images are all here for 7.17beta2: https://github.com/tikoci/fat-chr/releases (although -kriszos.raw is going to be functionally the same as -no-gidsk, since the gdisk fails during build).

Here is the failure from @kriszos with 7.17beta2:
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: present

Found valid MBR and GPT. Which do you want to use?
1 - MBR
2 - GPT
3 - Create blank GPT

Your answer: Using GPT and creating fresh protective MBR.

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Command (? for help): Partition number (1-2): Current type is EF00 (EFI system partition)
Hex code or GUID (L to show codes, Enter = EF00): Changed type of partition to 'Linux filesystem'

Command (? for help):
Recovery/transformation command (? for help):
WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N):
Creating entry for GPT partition #1 (MBR partition #1)
Enter an MBR hex code (default 83): Set the bootable flag? (Y/N):
Creating entry for GPT partition #2 (MBR partition #2)
Enter an MBR hex code (default 83): Set the bootable flag? (Y/N):
Unused partition space(s) found. Use one to protect more partitions? (Y/N):
Aborting write operation!
Recovery/transformation command (? for help):
Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Problem: partitions 2 and 1 overlap:
Partition 2: 65570 to 258048
Partition 1: 34 to 65570
Aborting write of new partition table.

Recovery/transformation command (? for help): b use backup GPT header (rebuilding main)
c load backup partition table from disk (rebuilding main)
d use main GPT header (rebuilding backup)
e load main partition table from disk (rebuilding backup)
f load MBR and build fresh GPT from it
g convert GPT into MBR and exit
h make hybrid MBR
i show detailed information on a partition
l load partition data from a backup file
m return to main menu
o print protective MBR data
p print the partition table
q quit without saving changes
t transform BSD disklabel partition
v verify disk
w write table to disk and exit
x extra functionality (experts only)
? print this menu

Recovery/transformation command (? for help): /dev/nbd0 disconnected
And here is the @jaclaz script running:
2024-09-27 17:20:22 URL:https://download.mikrotik.com/routeros/ ... a2.img.zip [41086700/41086700] -> "/tmp/chr-7.17beta2.img.zip" [1]
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 63.9M 1 loop /snap/core20/2318
loop1 7:1 0 87M 1 loop /snap/lxd/29351
loop2 7:2 0 38.8M 1 loop /snap/snapd/21759
sda 8:0 0 75G 0 disk
└─sda1 8:1 0 75G 0 part /mnt
sdb 8:16 0 75G 0 disk
├─sdb1 8:17 0 74.9G 0 part /
├─sdb14 8:30 0 4M 0 part
└─sdb15 8:31 0 106M 0 part /boot/efi
nbd0 43:0 0 128M 0 disk
├─nbd0p1 43:1 0 32M 0 part
└─nbd0p2 43:2 0 94M 0 part
nbd1 43:32 0 0B 0 disk
nbd2 43:64 0 0B 0 disk
nbd3 43:96 0 0B 0 disk
nbd4 43:128 0 0B 0 disk
nbd5 43:160 0 0B 0 disk
nbd6 43:192 0 0B 0 disk
nbd7 43:224 0 0B 0 disk
nbd8 43:256 0 0B 0 disk
nbd9 43:288 0 0B 0 disk
nbd10 43:320 0 0B 0 disk
nbd11 43:352 0 0B 0 disk
nbd12 43:384 0 0B 0 disk
nbd13 43:416 0 0B 0 disk
nbd14 43:448 0 0B 0 disk
nbd15 43:480 0 0B 0 disk
mkfs.fat 4.2 (2021-01-31)
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: present

Found valid MBR and GPT. Which do you want to use?
1 - MBR
2 - GPT
3 - Create blank GPT

Your answer: Using GPT and creating fresh protective MBR.

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Command (? for help):
Expert command (? for help): Relocating backup data structures to the end of the disk

Expert command (? for help):
Recovery/transformation command (? for help): Warning! This will destroy the currently defined partitions! Proceed? (Y/N):
Recovery/transformation command (? for help):
Expert command (? for help): Partition number (1-2): Known attributes are:
0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount

Attribute value is 0000000000000000. Set fields are:
No fields set

Toggle which attribute field (0-63, 64 or <Enter> to exit): Have enabled the 'legacy BIOS bootable' attribute.
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or <Enter> to exit):
Expert command (? for help):
Command (? for help): Partition number (1-2): Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): Changed type of partition to 'EFI system partition'

Command (? for help): Partition number (1-2): Enter name:
Command (? for help): Partition number (1-2): Enter name:
Command (? for help):
Expert command (? for help):
Recovery/transformation command (? for help):
WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N):
Creating entry for GPT partition #1 (MBR partition #1)
Enter an MBR hex code (default EF): Set the bootable flag? (Y/N):
Creating entry for GPT partition #2 (MBR partition #2)
Enter an MBR hex code (default 83): Set the bootable flag? (Y/N):
Unused partition space(s) found. Use one to protect more partitions? (Y/N):
Recovery/transformation command (? for help):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/nbd0.
The operation has completed successfully.

On Vultr... I don't use it, so haven't tried it. But they seem to want an want an ISO image to kickstart a cloud instance... Mikrotik recommends using SystemRescueCD to `dd`... But the same "gdisk scripts" here could just run from ISO image that just ran a shell script to setup the Vultr disk - i.e. some new ISO image would boot, with CHR image in it as file, but just create new partitions and copy mounted files from the image to the Vultr disk. Anyway... more food for thought re Vultr.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Fri Sep 27, 2024 9:48 pm

as soon as Sindy will be able to (hopefully) report success in the environment(s) he uses, the matter should be pseudo-solved.
Sorry, it was neither soon nor 100% success.

Both the pre-cooked images from @Amm0 I've tried, i.e. chr-7.16.uefi-fat.raw and chr-7.16.uefi-fat-kriszos.raw, [...] neither of the two images worked at the cloud provider (Vultr) where the 7.14.3 image mangled using the script by @kriszos from post #2 did work fine.
If it's easy, can you try @jaclaz's version at Vultr.., as the gdisk mods did get applied in this one for 7.17beta2: https://github.com/tikoci/fat-chr/relea ... jaclaz.raw
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 8:00 pm

@jaclaz, you're the boss - 7.17.beta2 mangled using your gdisk magic made Vultr happy.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 8:43 pm

@jaclaz, you're the boss - 7.17.beta2 mangled using your gdisk magic made Vultr happy.
And I rebuilt the 7.15.3 and 7.16 images to use/default to the @jaclaz variant on GitHub:

7.15.3 - https://github.com/tikoci/fat-chr/relea ... 402-jaclaz
7.16 - https://github.com/tikoci/fat-chr/relea ... 131-jaclaz
7.17beta2 - https://github.com/tikoci/fat-chr/relea ... 808-jaclaz

Test them both using Apple Virtualization (in UTM and Swift Playground), so they generally work. If 7.17beta2 work in Vultr, I'd imagine these would too — from GitHub build logs, at least, the @jaclaz script run same in 7.15.3, 7.16, 7.17beta2.
 
optio
Forum Veteran
Forum Veteran
Posts: 884
Joined: Mon Dec 26, 2022 2:57 pm

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 9:20 pm

Test them both using Apple Virtualization (in UTM and Swift Playground), so they generally work.
Tested on mac with arm64 or x86_64 arch?

Edit: nvm, I see these images are made from x86_64 chr image.
Tried before when chr arm64 is intorduced but it didn't boot with Apple Virtualization on mac arm64...
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 10:14 pm

Test them both using Apple Virtualization (in UTM and Swift Playground), so they generally work.
Tested on mac with arm64 or x86_64 arch?
Since I'm running the CHR superstore, I built an ARM64 image with the FAT modification for 7.17beta2:
https://github.com/tikoci/fat-chr/relea ... disk-arm64 (image: chr-7.17beta2.uefi-fat-no-gdisk-arm64.raw)

I don't have ARM64 Mac here, so I you wanted to try that, LMK. It works under QEMU ARM64 emulation, on X86 Mac, so image does load. UTM on ARM Mac, IDK...

I also haven't tried Mikrtoik real CHR on ARM64, so open question in 7.17/7.16 if MT did fix something (so as not need modification)
 
optio
Forum Veteran
Forum Veteran
Posts: 884
Joined: Mon Dec 26, 2022 2:57 pm

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 10:42 pm

No luck, same issue as with my modifications on image.
com.apple.Virtualization.VirtualMachine stuck on 400% cpu, it seems loop, no output on serial console or display.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 10:44 pm

No luck, same issue as with my modifications on image.
com.apple.Virtualization.VirtualMachine stuck on 400% cpu, it seems loop, no output on serial console or display.
Remove the display – that does not work in UTM+Apple. It's serial only on X86, so imagine it's the same on ARM64. I think Apple uses some virtio-*-gpu things, but RouterOS does not have right driver/support for Display.

Also @Kartone in my Apple+UTM thread, had more tips if you want to QEMU with "stock image":
viewtopic.php?t=204805&hilit=UTM&sid=28 ... 0#p1079177
 
optio
Forum Veteran
Forum Veteran
Posts: 884
Joined: Mon Dec 26, 2022 2:57 pm

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 10:55 pm

Remove the display – that does not work in UTM+Apple. It's serial only on X86, so imagine it's the same on ARM64. I think Apple uses some virtio-*-gpu things, but RouterOS does not have right driver/support for Display.
Tried without display (using like that on Intel mac), added additionally display just to see if anything will appear.
Also @Kartone in my Apple+UTM thread, had more tips if you want to QEMU with "stock image":
viewtopic.php?t=204805&hilit=UTM&sid=28 ... 0#p1079177
Thx, seen that, but not interested using QEMU. Since I have it running on Intel mac, on arm mac was just POC tryout.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 11:02 pm

Since I have it running on Intel mac, on arm mac was just POC tryout.
Yeah same boat, I have 2019 MacBook Pro with Intel i9. Since I do deal with [Intel] VMs enough, I didn't want to mess with Rosetta ;).

The only thing else to try for UTM+Apple+ARM64 be checking the "Use NVMe"box – that was in QEMU instructions for ARM64. And that's an option in Apple-based VM within UTM Disk, I presume in the ARM64 UTM too (but dunno):
NVMe4ARM.png
You do not have the required permissions to view the files attached to this post.
 
optio
Forum Veteran
Forum Veteran
Posts: 884
Joined: Mon Dec 26, 2022 2:57 pm

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 11:13 pm

Tried also with NVMe interface, I'm running also Debian arm64 with Apple Virtualization and it requires NVMe to avoid FS corruption, unfortunately for ROS boot same result.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sat Sep 28, 2024 11:23 pm

Tried also with NVMe interface, I'm running also Debian arm64 with Apple Virtualization and it requires NVMe to avoid FS corruption, unfortunately for ROS boot same result.
Well we tried. There not a lot options to tweak, and I'd image the issue with AppleVM + CHR + ARM64 isn't partitioning. Thanks!
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Sun Sep 29, 2024 2:55 am

@jaclaz, you're the boss - 7.17.beta2 mangled using your gdisk magic made Vultr happy.
Good. :)
So this part of the problem is solved, at least until the good Mikrotik guys don't change something relevant in the images.
A solution to the other part ( keeping compatibility with BIOS booting) is on its way, I already managed to modify an image so that it boots with both firmwares, but the way to make it is complex and the resulting image is "ugly", with two partition entries in the (hybrid) MBR (+ the protective one) but three in the GPT.
In practice I shrinked the 32 MB ext2 volume to a little less than 16 MB (for BIOS) and used the freed 16 MB for a new FAT16 volume indexed only in the GPT.
From the tests I made it should be possible to have a single volume (FAT16) compatibile with both booting methods.
The obstacle at the moment is the *something* I mentioned earlier that is loaded by the bootsector code that seems to be the file "map", which is loaded not through filesystem access, but rather by direct access/absolute position and as such it is not easily moved/repositioned.
I am thinking about possible workarounds to protect that file and make the image simpler and more "safe" against accidental modifications.
Unfortunately parted and gparted (let alone fdisk) have their own quirks and limitations and manage to "ruin" the Hybrid MBR made with gdisk (and automating/scripting parted is/will be a PITA because it nags about the roughly 4 thousand sectors that are not part of any partition).
As a side note I simply hate the arrogance/patronizing behind this way programs want to do not what you tell them to do but rather what they think it is better for you.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sun Sep 29, 2024 3:28 am

@jaclaz, I wouldn't get too crazy. The 2-3 cases of AppleVZ, Vultr, and potentially "Gen2" Hyper-V.
And I do kinda think it be better to use the official Mikrotik ones if at all possible & those do work on BIOS system. So the fact these are EUFI only is kinda a safety net. Plus, there is the "bootpart" and "bootdev" block devices in p2's /dev, that appear to refer to itself...so if you do too much, I suspect you can break the "link to itself" (and thus booting).
But if you have some new script, it's easy to plug into my build system for these things now, so happy to build anything.

Now Dr. Jaclaz... if you had any ideas to get CHR boot from iPXE, that be interesting to hear. Not a current problem, but Equinox Metal only support iPXE (and Vultr would take iPXE from URL too. But could never figure out how wireup iPXE to CHR to boot it.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Sun Sep 29, 2024 3:51 am

@jaclaz, I wouldn't get too crazy.
Sure, I know, it is more like, you know :wink:
The way I see it, if you're gonna build a time machine into a car, why not do it with some *style?*
The IPXE could be another royal PITA, I am now a bit rusty about BIOS/UEFI and filesystems, but at least in my days I was familiar enough with that kind of stuff, PXE/IPXE I only touched a few times, and never really studied it in detail.
We'll see.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: Router OS 7 on UEFI

Sun Sep 29, 2024 5:28 pm

Somehow, I would expect gentlemen in Riga to provide either "BIOS CHR" and "UEFI CHR" images or a "universal CHR" image off the shelf rather than offloading that task to volunteers. I am still not sure why I had to use the UEFI-compatible image for the recent lot of CHRs all of a sudden whilst the standard image was sufficient to run multiple previous ones at the same Vultr, but I assume that the hosting providers are switching to UEFI boot for new installations as UEFI has been on all the hardware machines for years, so a UEFI boot in a hosting is not a niche case any more.

Given what the hosting providers typically offer, it is in fact bad enough that one has to use the recovery Linux "CD" (.iso) to install a CHR image since no CHR .iso is available - people who are scared by command line and love Winbox are forced to type. But on the other hand, maybe the whole use of a CHR in a public hosting center is a niche case, given all the security aspects of doing so, and hence creating a proper .iso that would look around and choose the boot image matching the environment, instead of a one-size-fits-all barking cat image, would be an unjustifiable waste of developers' time.

So to summarize, is this worth a support ticket?
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sun Sep 29, 2024 7:32 pm

Somehow, I would expect gentlemen in Riga to provide either "BIOS CHR" and "UEFI CHR" images or a "universal CHR" image off the shelf rather than offloading that task to volunteers. [...]
Yeah that was my point to @jaclaz – Mikrotik should fix the UEFI & they'd know WAY more since nothing is exactly "standard linux" in these images (e.g. I presume their milo is some custom lilo, etc. etc.).

And, the community has helped them identify the #1 issue which is FAT IMO. The #2 issue is it be nice to deploy CHR (and it's license scheme) but have the same "install step" as X86 when booting, but using the right CHR driver and CHR's license scheme instead. This get you an ISO that likely work at Vultr/etc (and perhaps iPXE from ISO), but with same CHR licensing (since using the X86 licensing be tough in the cloud/VMs).

it is in fact bad enough that one has to use the recovery Linux "CD" (.iso) to install a CHR image since no CHR .iso is available
I hadn't looked at the Vultr instructions in Mikrotik's help until this thread, that's a travesty. The Vultr looks pretty reasonable offering and relative cheap. For $5/month and $50/once for CHR, it looks like you can get a public IP for tunnel/VPN/etc. It's like they don't want to sell more CHR licenses... if you could bring up a CHR in a couple steps, folks might actually get to point where they can license it ;).

I read those directions, and thus the question about "iPXE" – since that was also support by Vultr. And, if you ask me, that's looks ideal: if you could provide some iPXE URL to some futurist "https://pxe.mikrotik.com/?version=7.15.3" (or show a menu, like what https://netboot.xyz) - it be one-step to install on Vultr and others. For example, Equinix Metal only supports iPXE for custom images. While Equinix VMs are expensive, they do give you BGP access to Equinix's backbone - so it's shame CHR doesn't run there.


So to summarize, is this worth a support ticket?

I put in a feature request a while back, SUP-144667. In March '24, I got back:
Thank you for the suggestion, we will consider it.
And after the recent discussion here & noticing there ~10K on esoteric topic like UEFI... I even added link this thread last week — to highlight it wasn't just me & 10K views on the topic of "UEFI", but I got this back:
And there are only 9 users who are posting in this thread... As I said previously we will consider if there will be user demand.
So if you want to "vote" for doing something, apparently either post you need it, or file a ticket. (Now on the metrics... mDNS took 100K forum post views for something to come out ;).
Last edited by Amm0 on Sun Sep 29, 2024 7:52 pm, edited 1 time in total.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 21366
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Router OS 7 on UEFI

Sun Sep 29, 2024 7:39 pm

Rhetorical question, the answer is YES, remove work-arounds where possible. In this case, the cost/effort to remain compatible with major cloud providers is important in the support of the their CHR product line. To be fair, they cannot be on top of every issue and I am confident they will jump on this one to rectify, once aware.
However after reading the above post, it appears they are sadly ambivalent.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Sun Sep 29, 2024 8:03 pm

With all due respect for the good guys @Mikrotik, in this particular case something went wrong, they failed, and failed big.

If they wanted to have the CHR image to be only BIOS bootable (through their - let's call it "strange" - method, bootsector code and hardcoded map) why did they add in the image the \EFI\BOOT\BOOTX64.EFI? :shock:

That should mean that they had all the good intentions :) to make it UEFI bootable.

But then, they completely omitted to test it, I don't think there are many UEFI systems out there with ext2fs drivers. :-?

Maybe the tester has got one of these rare systems and didn't even think to test the image on the things that people (please read as customers) actually use.

This is IMHO (the use of ext2FS instead of FAT) much more "serious" of the little partition hiccup starting from 7.15.3, and it is more than two years old.

Vultr is a little more strict than other virtual environments (that *like* anyway the non-gdisk massaged partition table), but the requirement of not having overlapping partitions is a "sound" one.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Sun Sep 29, 2024 8:34 pm

Basically I agree with @sindy:
I would expect gentlemen in Riga to provide either "BIOS CHR" and "UEFI CHR" images or a "universal CHR" image off the shelf rather than offloading that task to volunteers. [...] so a UEFI boot in a hosting is not a niche case any more.
Two images for download: chr-bios.raw and chr-uefi.raw (*with UEFI actually tested and partitioned according to specs, which ext2 is not) would go a long way. The universal image is how we got here... but IDK maybe it's fixable.

And, long-term some iPXE boot is what I'd like to see as then I can just type a URL to get the image from mikrotik.com, no manual download step required. But I don't have high hopes for that anytime soon. And the pre-requisite is a working UEFI image to even have hopes of iPXE.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Tue Oct 01, 2024 7:31 pm

OK, so, if anyone is interested in this "universal image", in the attached spreadsheet there are the basic instructions to modify the image so that it boots both in BIOS and in UEFI.

NOT a fully tested script, only the needed info and the commands I used manually.

Due to the hardcoded addresses in "map" (that has also a checksum of some kind, checked at boot time) the file cannot be modified nor moved, so the easiest is extending the number of reserved sectors in the new FAT BPB (from the default 4 to 12400) to protect it and keep it outside the accessible filesystem..

The available space is a little less, but there is anyway plenty of room for the only needed file in the FAT volume, the /EFI/BOOT/BOOTX64.EFI.

It is entirely possible that in a next release of ROS the "map" is changed/moved, but the method can be adapted, someone more capable than me with Linux and bash scripting may well fully automate it, by reading the LBA address of the file and its size and doing the calculations.
You do not have the required permissions to view the files attached to this post.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4143
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: Router OS 7 on UEFI

Tue Oct 01, 2024 8:58 pm

NOT a fully tested script, only the needed info and the commands I used manually.
I can offer a self-service solution to building them....

FWIW, you/anyone to rebuild the image using any script with GitHub running it using "GitHub Actions".

Basically, the steps to "Creating your own CHR builder" are:

1. Use/create a GitHub account (free & as long as your repo/project is public, you get decent number of "free minutes" to run builds)

2. Use the "Fork" option from https://github.com/tikoci/fat-chr to create your own copy:
ForkRepoToYourAccount.png
3. In your new repo/fork, within your "Setting" for the repo, you'll need to enable GitHub Actions (by default, there disabled for Forks):
EnableGitHubActionsInFork.png
4. GitHub has nifty feature to bring "VSCode for Web" by just hitting the . (dot) key while viewing your repo in a web browser. This allows you to edit a script or build actions (in .github/workflows/manual.yaml). You can create a new script file in the root with any new/desired steps, or just modify any of the exist script (no-gdisk, jclaz, etc). If you change one, go to the Git icon on left to "commit" and changes to the script.
VSCodeForWeb.png
So you don't have to leave the web to build these things....and have a repeatable process as a result

5. In you main fork's main GitHub page (not VSCode view), you can go to "Actions", click the "Manual Build and Release", then use the "Run workflow" button to pick the RouterOS version and "mod script" file name to run as part of the build. For X86 leave "arch" blank (and use "arm64" when building arm, but only the no-gdsk-arm64 script works with that option):
RunActionManualBuild.png
6. If you run the workflow from popup, a new job will appear. If you click it, then click "build" button in center, you'll see what's going on at each step:
GitHubBuildRunner.png
7. The Release section from main project will have the images if build was successful.
You do not have the required permissions to view the files attached to this post.
 
anovojr
newbie
Posts: 48
Joined: Wed Nov 15, 2017 9:24 am
Location: Philippines
Contact:

Re: Router OS 7 on UEFI

Sun Oct 20, 2024 12:01 pm

Hey! When I was setting up ROS 7.1.3 on Hyper-V Gen2, I found it helpful to use a VHDX file for the installation. Make sure the image you’re using is compatible with UEFI boot since that can cause issues if it’s not. I had some trouble downloading the image smoothly too, so I ended up switching networks and re-downloading, which did the trick. Also, double-check your Hyper-V settings, especially the virtual switch—having that configured right makes a big difference.
 
jaclaz
Forum Guru
Forum Guru
Posts: 1756
Joined: Tue Oct 03, 2023 4:21 pm

Re: Router OS 7 on UEFI

Sun Oct 20, 2024 12:37 pm

Hey! When I was setting up ROS 7.1.3 on Hyper-V Gen2, I found it helpful to use a VHDX file for the installation. Make sure the image you’re using is compatible with UEFI boot since that can cause issues if it’s not. I had some trouble downloading the image smoothly too, so I ended up switching networks and re-downloading, which did the trick. Also, double-check your Hyper-V settings, especially the virtual switch—having that configured right makes a big difference.

Well, the whole point of this thread is exactly that one.
Summed up:
The image Mikrotik provides has a bootable EFI file (\EFI\BOOT\BOOTX64.EFI) but it has it residing inside an ext2/3 filesystem, for which most (if not all) firmware EFI/UEFI won't have a driver for, thus it is in practice unreadable.
The nice original idea by kryszos was to reformat the first volume to FAT (FAT16) and copy back that file, and modify accordingly the GPT partition table..
This approach worked fine until version 7.14.3, no idea when the issues started, but probably the 7.1.3 image you used was "good" and needed not this post-processing.
Then - for *some reasons* (probably an unintentional mistake in building the image) - starting from 7.15.something the GPT partition table has incorrect values and the original gdisk script doesn't work anymore.
A slightly modified script was posted/implemented so that the GPT partitioning is first fixed and later modified in gdisk.
This - like the original script - produces a working UEFI bootable image BUT the modified image is not anymore BIOS bootable (the original one is).
So I posted the needed steps (only for purists) to have the modified image bootable in both BIOS and UEFI.
 
divinehawk
just joined
Posts: 3
Joined: Tue Oct 22, 2024 9:21 pm

Re: Router OS 7 on UEFI

Thu Oct 24, 2024 9:20 pm

Anyone tried this on AWS arm64? I have tried several of the linked image without success.
 
User avatar
BetaQuasi
just joined
Posts: 2
Joined: Tue Apr 11, 2023 8:39 am

Re: Router OS 7 on UEFI

Tue Oct 29, 2024 1:06 am

Not for AWS, however for OCI using one of their Ampere VM's, this image worked: https://github.com/tikoci/fat-chr/relea ... disk-arm64 - UEFI only on OCI's Ampere implementation.

Who is online

Users browsing this forum: No registered users and 0 guests