Thanks, works now.
used commands for installing luci.
apk update
apk upgrade
apk add -u luci
Thank you
Didn't put it in bold letters but at least when I tried there weren't initramfs builds in snapshot.
I just checked again and no initramfs in snapshot per screen capture? When I installed mine I built the initramfs from source.
Huh, I think it got merged. Nowadays it's easier to submit stuff through Github. It would be good to ping some core devs about it, or go through Github. I don't want to steal your contribution, but +1 from my side up front.
1 Like
Haha. It's got my signed-off-by thing so I think anyone could take the patch and submit it through github as long as they maintain the attribution?
If they're not doing things through patchwork then I guess I'll eventually get around to submitting a bunch of things through github.
I'm having an issue getting the initramfs to boot on my MX64. I get the 3 orange flashes then nothing after that, I can't connect to the unit by SHH or Telnet. I've made sure the USB drive is FAT and formatted to less than 4gb, although the total size of the USB is 32gb but surely if I made the primary partition 4gb FAT it shouldn't matter?
Has anyone else had this issue?
Do you mean three white flashes over orange? If not, looks to me like an older U-boot version - which I have basically no experience with. I know the USB controller is quirky and also failed to detect one of my drives during development - I would try a different physical USB drive first.
I had issues with a 4G flash drive partitioned without a partition table as a one big fat. i.e .mounted as /dev/sda.
With a fat16 128M flash drive in a partition. i.e. mount as /dev/sda1 worked fine for me.
I've given this a try but it still doesn't seem to recognise it, as Leo said I think it could be the hardware. It's a sandisk for reference.
I’m experiencing the exact same issue with my MX64w. I’ve tried using multiple USB drives, but none of them seem to boot. I’ve also followed @evs recommendation to partition them exactly as specified, but unfortunately, it hasn’t made any difference. Any ideas?
I've used random flash drive, cleaned it, changed to mbr, formatted to fat32 and 8gig flash worked fine, maybe name of file is not the meraki want - connect serial console and find out.
I'm getting this responce
** Unable to use usb 0:1 for fatload **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
My sandisk 4G drive didn't work.
Yeah I've got nothing. Sometimes it seems to be a RNG. Some of my cisco switches rejected the 128M drive I had above, whilst they were OK with some of my other 1G drives. Same with my juniper gear... So I don't have anything for you other than try the fat in a partition and try different flash drives.
Fixed!
So for this issue I formatted the USB to 128mb FAT16 and used a different image file, the one from github didn't seem to work.
1 Like
Has any one had any issues with the latest Snapshot and OPKG? I updated to the latest Snapshot and OPKG doesn't seem to be even installed.
See post 399
Thanks didn't read up far enough.
test with ubi volume cleanup
2x mx64 (non a0) with snapshot from nov. 13th,
sysupgrade with snapshot nov. 24th
a) 1x sysupgrade only
b) 1x sysupgrade with prior deleting all ubi volumes except board-config
results for storage (used / available):
a) disk space: 1020.00 KiB / 360.27 Mib
b) disk space: 1024.00 KiB / 895.43 MiB <==
details before sysupgrade:
ls /sys/class/ubi/
ubi0 ubi0_1 ubi0_3 ubi0_5 ubi0_7
ubi0_0 ubi0_2 ubi0_4 ubi0_6 version
cat /sys/class/ubi/ubi0_0/name ..... part.safe
cat /sys/class/ubi/ubi0_1/name ..... part.old
cat /sys/class/ubi/ubi0_2/name ..... board-config
cat /sys/class/ubi/ubi0_3/name ..... storage
cat /sys/class/ubi/ubi0_4/name ..... diagnostic1
cat /sys/class/ubi/ubi0_5/name ..... kernel
cat /sys/class/ubi/ubi0_6/name ..... rootfs
cat /sys/class/ubi/ubi0_7/name ..... rootfs_data (mounted on /overlay)
on second unit (b):
delete 0,1 and 3-7 (every volume except!!! board-config, here: 2),
kernel, rootfs and rootfs_data will be recreated during sysupgrade
ubirmvol /dev/ubi0 -n 0 (repeat with 1,3,4,5,6,7 for -n)
after sysupgrade and reboot:
ls /sys/class/ubi/
ubi0 ubi0_0 ubi0_1 ubi0_2 ubi0_3 version
cat /sys/class/ubi/ubi0_0/name ..... kernel
cat /sys/class/ubi/ubi0_1/name ..... rootfs
cat /sys/class/ubi/ubi0_2/name ..... board-config
cat /sys/class/ubi/ubi0_3/name ..... rootfs_data
note: independend from deleting ubi volumes on one mx64, the mtd´s are
remaining identical to both units.
everything works, but question for the pundits:
Are there any drawbacks or should a ubi cleanup part of the install routine?
1 Like
Popping in to thank the crew here once more.
Picked up a used MX65W from the recyclers, now upgraded using @Leo-PL Oct 16 INIT.bin
Downloaded the latest snapshot form openwrt , used apt to install luci.(thanks @nenni)
I now have a working MX65!! Woop! 10 LAN ports plus 2 POE Lan. POE confirmed working with a Unifi Flex Mini.
Speed test I'm only getting 650mbit down, 850 up, what's everyone else' throughput on these ?
3 Likes
I've got similar results with SQM enabled. With flow offload enabled - full gigabit each direction, but QoS conflicts with that.
3 Likes
On my MX65 after updating to the latest snapshot or RC,
I'm noticing POE isn't working on ports 11/12.
I rolled back to Leo-PL October 21 sysupgrade file and I have POE again.
POE works when using LUCI to upload latest sysupgrade, but after a cold boot I lose POE again. Not sure how to troubleshoot this. Staying on Oct 21 Leo's release for now.