Hello guys...
Recently I bought one of this Intel N5105 to upgrade my network...
When I write the latest OpenWRT image (23.5.0) on the SSD, the device doesn't boot... The BIOS doesn't even recognize the SSD as bootable...
I found this video looking for answers (https://www.youtube.com/watch?v=kQamMghox30&t=864s) and I was doing exactly the same steps, except for the firmware version (22.03.0-rc6)... So I tried to test this version and OpenWRT was successefully booted... After install it, I tried to upgrade to latest version from webUI and after upgrade got the same issue.
I'm worried on this situation because it's very painfull to recover...
Does anybody know why that is happening?
Please be specific which exact image you downloaded - and how you wrote it to the SSD.
Without knowing anything about the device in question (and only guessing what you might have done), I would suggest to take care of two things:
- use the combined-efi image
- make sure that secure boot is disabled
1 Like
hi.. I downloaded Generic X86/64 Combined EFI (Squashfs)...
To write it is that is the painfull step.... Its a M.2 NVME SSD... I swaped it on my laptop and booted a Win10 that I have on a SSD SATA and used Balena Etcher to write the image on the M.2 NVME SSD.
The same steps on both 23.5.0 and 22.3.0-rc6...
Also, upgrading from 22.3.0-rc6 from Luci and uploading the image, I got the sabe issue.
also... secure boot is disabled....
Another thing... I tried to write those images on an USB drive ando got the same results... 22.3.0-rc6 boots ok.... 23.5.0 doesn't even is recocnized as an UEFI bootable device... I can't even see the unit with 23.5.0 for tring to boot from it.
If 22.03.x works, what happens if you write that to SSD and sysupgrade from there?
The easiest approach is imho:
- write OpenWrt to a USB disk
- reboot the target device with that USB disk
wgetthe OpenWrt image (orscpit over)- use
zcatto write it to the SSD
well... when I tried upgrade from Luci, I was thinking about a sysupgrade... but for X86 there is no sysupgrade image.... I believe sysupgrade is for router/ap/switch devices that has storage limits. For X86 there is only these images avaiable:
The combined images are used both for installing (decompressed) and taken as-is (compressed) by sysupgrade.
1 Like
yes... i tried uncompressed image...
bottom line: Following the same steps for both 23.05.0 and 22.3.0-rc6. The 23.05.0 does not boot at all!
Here's what I did on mine, using the efi-combined squashfs:
- Make a bootable USB, Debian, Ubuntu, whatever.
- Mount it on any old workstation.
- Copy uncompressed OpenWrt image to it somewhere convenient in the bootable image partitions (or create a new one).
- Move the USB to the N5105 and boot it up.
$ mount blah blah /usbto be able to see the .img file (don't recall the mount parameters, sorry).$ dd if=/usb/openwrt.img of=nvme0n1$ reboot- Pull the USB stick out while it reboots...
After reboot, here's what I see:
$ fdisk --list /dev/nvme0n1
GPT PMBR size mismatch (246303 != 488397167) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/nvme0n1: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: WDC WDS250G2B0C-00PXH0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 266B958D-769A-BCBD-AA7B-1BAC46AB8600
Device Start End Sectors Size Type
/dev/nvme0n1p1 512 33279 32768 16M Linux filesystem
/dev/nvme0n1p2 33280 246271 212992 104M Linux filesystem
/dev/nvme0n1p128 34 511 478 239K BIOS boot
Partition table entries are not in disk order.
right... but what release did you use?
The main issue here is that, doesn't matter the procedure I use, 22.03.0-rc always work and 23.05.0 always fails...
I thought that could be an NVME issue... even tried to run on a SATA SSD and got the same results.
Even writing image on an USB thumbdrive fails to boot 23.05.0.
It was the snapshot build back in Dec 2022, so it would have been roughly equivalent to 22.03.3 or .4. Since then I've done auc updates on a mostly weekly basis...
$ ubus call system board
{
"kernel": "5.15.135",
"hostname": "rtr02",
"system": "Intel(R) Celeron(R) N5105 @ 2.00GHz",
"model": "CWWK 4x2.5G v.5",
"board_name": "x86_64,combined",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r24194-e1aaa1defd",
"target": "x86/64",
"description": "OpenWrt SNAPSHOT r24194-e1aaa1defd"
}
}
Just yesterday I put up a new x86 VM using the 23.05.0 combined-efi ext4 image, and it worked right out of the box.
I didn't try the ext4 image... neither the others...
in theory, the other images are suposed to work on this device or only the two "EFI" versions?
I suspect only the EFI versions will work on the Celeron N, with its relatively modern Intel Management Engine bios. The ext4 vs squashfs shouldn't make a difference as far as booting is concerned, you should at least get through the grub stuff before that comes into play.
Here's some more info, in case it jogs something loose...
$ lsblk --fs /dev/nvme0n1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat kernel 1234-ABCD 9.5M 40% /boot
│ /boot
├─nvme0n1p2 squashfs 0 100% /rom
└─nvme0n1p128
Partition 1 is type Linux Filesystem (8300) but it should be type EFI System (ef00).
Maybe the NVME driver on the BIOS is only looking for an efi bootloader on ef00 type partitions?
You could try booting the image from a USB stick to see if it related to NVME driver.
You could also try mounting the image on a loop device and then change the partition 1 type using gdisk (EDIT: you could also do it straight on the img file)
Also you could try enabling CSM module if it's disdable on the BIOS, the disk should be bootable from BIOS boot partition in legacy mode (but I'm not sure if NVME can be booted that way)
Well that's very odd, the fdisk list you quote is from my working N5105, which boots EFI, I would expect @dsduarte's to behave like mine, unless maybe he has ancient bios?
EFI as evidenced by the usual way of detection:
$ ll /sys/firmware/efi/
drwxr-xr-x 5 root root 0 Oct 24 19:51 ./
drwxr-xr-x 6 root root 0 Oct 24 19:51 ../
-r--r--r-- 1 root root 4096 Oct 26 13:05 config_table
dr-xr-xr-x 2 root root 0 Oct 24 19:51 efivars/
drwxr-xr-x 3 root root 0 Oct 26 13:05 esrt/
-r--r--r-- 1 root root 4096 Oct 26 13:05 fw_platform_size
-r--r--r-- 1 root root 4096 Oct 26 13:05 fw_vendor
-r--r--r-- 1 root root 4096 Oct 26 13:05 runtime
drwxr-xr-x 12 root root 0 Oct 26 13:05 runtime-map/
-r-------- 1 root root 4096 Oct 26 13:05 systab
Combined-EFI (EXT4) works fine!
The issue here is seems to be the SQUASHFS!
2 Likes
Good to hear! Not sure what to say other than, "
".
This minipc has 4 eth ports... now I'm struggling to set up a bridge between 3 ports and have VLAN's on them.
I have a xiaomi R3P with all the vlans ok but the same config is not working here... by any chance do you have this on your device? If so, could you please share your network file?
I'm not a VLAN user, might want to start a new thread on this...
Mine's just an experimental subnet router, so network config is brain-dead simple.
$ cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd66:ca11:911::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
config interface 'wan'
option device 'eth0'
option proto 'dhcp'
option peerdns '0'
config interface 'wan6'
option device 'eth0'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix '60'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '10.1.3.1'
option netmask '255.255.255.0'
option ip6assign '60'
list ip6class 'wan6'
list ip6class 'local'
1 Like