<DC-IRC> <joekhoobyar> I am not in the above boat, @rpardini , I had a fairly recent brand new oc4 install. Less than 30 days old
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-amlogic
<DC-IRC> <jbergler> @rpardini if you look in that thread I + Igor mentioned, the `uImage` on my n2 was getting updated as recently as 23.02.2 to 6.1.11.
<DC-IRC> <jbergler> My `boot.ini` has this ```# legacy and mainline kernel diff
<DC-IRC> <jbergler> if ext4load mmc ${devno}:1 0x00000000 "/boot/.next" || fatload mmc ${devno}:1 0x00000000 ".next" || ext4load mmc ${devno}:1 0x00000000 ".next"; then
<DC-IRC> <jbergler> echo "Found mainline kernel configuration"
<DC-IRC> <jbergler> setenv uartconsole "ttyAML0,115200n8"
<DC-IRC> <jbergler> setenv kernelimage "uImage"
<DC-IRC> <jbergler> else
<DC-IRC> <jbergler> echo "Found legacy kernel configuration"
<DC-IRC> <jbergler> setenv uartconsole "ttyS0,115200n8"
<DC-IRC> <jbergler> setenv kernelimage "zImage"
<DC-IRC> <jbergler> fi```
<DC-IRC> <jbergler> Which seems to suggest that migration to mainline uboot maybe hasn't happened for me, anything I can do to check?
<DC-IRC> <jbergler> This implies uboot is really old ```# grep -a --null-data U-Boot\ 2 /dev/mmcblk1boot0 ; echo
<DC-IRC> <jbergler> U-Boot 2017.05-15377-gedb23d4U-Boot 2017.05-15377-gedb23d4 (Aug 24 2017 - 07:09:51 -0300) for ODROID-XU4```
<DC-IRC> <jbergler> Is something meant to invoke `/usr/lib/u-boot/platform_install.sh` ?
<DC-IRC> <jbergler> If it helps, I installed from whatever the latest image was on 29 Mar 2021, which might confirm that this is a problem for folks who never updated uboot
<DC-IRC> <jbergler> If it helps, I installed from whatever the latest image was on 29 Mar 2021, which might suggest that this is a problem for folks who never updated uboot manually
<DC-IRC> <igorpec> oh, so we would need to force u-boot update alongside kernel?
<DC-IRC> <c0rnelius77> I thinks that info may be a little misleading and is probs some old android garbage left over on the eMMC. Older module ```U-Boot 2017.05-15377-gedb23d4U-Boot 2017.05-15377-gedb23d4 (Aug 24 2017 - 07:09:51 -0300) for ODROID-XU4 ``` Newer module ``` U-Boot 2017.05-00008-g6a9ddb8303-dirtyU-Boot 2017.05-00008-g6a9ddb8303-dirty (May 19 2020 - 19:48:01 +0900) for ODROID-XU4 ``` and I <clipped message>
<DC-IRC> <c0rnelius77> certainly don't have this version of u-boot running on the units.
<DC-IRC> <rpardini> A 30-day old image using uImage? I'm completely at a loss how this could have happened. Please 🙏 send us that image name/url?
<DC-IRC> <rpardini> Yes this confirms my suspicion. We didn't do a good job back then (2021) about the mainline uboot migration. My fault, mostly. We've learned a thing or two since then. In short: install new kernel)drb, new uboot, and new bsp (cli) package, then run armbian-install to update uboot. Suggest make a bkp beforehand.
<DC-IRC> <rpardini> Yes this confirms my suspicion. We didn't do a good job back then (2021) about the mainline uboot migration. My fault, mostly. We've learned a thing or two since then. In short: install new kernel/dtb, new uboot, and new bsp (cli) package, then run armbian-install to update uboot. Suggest make a bkp beforehand. Make sure /boot had boot.scr, armbianEnv.txt, and not boot.ini. this <clipped message>
<DC-IRC> <rpardini> might be a lot of work, so to say the truth maybe consider a new image?
<DC-IRC> <joekhoobyar> I’m sorry @rpardini , I wasn’t clear. It’s not uImage I’m talking about.
<DC-IRC> <joekhoobyar> I’m talking about a corrupted deb
<DC-IRC> <joekhoobyar> So I’m in a “different boat”
<DC-IRC> <c0rnelius77> Armbian should ditch the boot scripts and craziness and go with the almighty EXTLINUX.
<DC-IRC> <efectn> what about efi + systemdboot
<DC-IRC> <c0rnelius77> Could do that too... But systemdboot last I checked requires a GPT partition. Unless something has changed?
<DC-IRC> <c0rnelius77> Extlinux is way easy and supports overlays.
<DC-IRC> <efectn> yes it doesn't support mbr
<DC-IRC> <efectn> it also supports devicetree overlays
<DC-IRC> <c0rnelius77> Yeah... Systemdboot doesn't fly on AML though.
<DC-IRC> <c0rnelius77> So thats out the window.
<DC-IRC> <efectn> oh then extlinux is nice
<DC-IRC> <c0rnelius77> Of the major 3 I think it would only work on RK.
<DC-IRC> <c0rnelius77> sdboot that is.
<DC-IRC> <rpardini> Oh sorry, I mixed things up. Corrupted .deb is a different story, it might be mirror/Rsync related...
<DC-IRC> <efectn> grub is also possible but it's just a crap
<DC-IRC> <c0rnelius77> and no overlay support.
<DC-IRC> <tenkawa42> grub is a nightmare on anything non-x86
<DC-IRC> <efectn> grub is nightmare on x86 too
<DC-IRC> <tenkawa42> (and >>50% on x86 too)
<DC-IRC> <tenkawa42> beat me to it
<DC-IRC> <tenkawa42> lol
<DC-IRC> <c0rnelius77> I've made grub work for me on ALL, AML and RK. But... I'm not impressed with it and if something goes wrong recovery is kind of nightmare.
<DC-IRC> <tenkawa42> yeah.. thats where it goes sideways
<DC-IRC> <tenkawa42> recovery
<DC-IRC> <c0rnelius77> If you don't make backups of the EFI binary forget ur screwed.
<DC-IRC> <c0rnelius77> On top of that, I can never get grub menus to work for me using wireless keyboards on ARM. Which also defeats the purpose in my case of using grub.
<DC-IRC> <tenkawa42> ooh good point
chewitt has quit [Quit: Zzz..]
<DC-IRC> <jbergler> Updating u-boot manually is fine for me, maybe its reasonable to somehow have the kernel package check boot.ini for uImage and build it if its expected or something?
<DC-IRC> <jbergler> Updating u-boot manually is fine for me, for the general case though maybe its reasonable to somehow have the kernel package check boot.ini for uImage and build it if its expected or something?
<DC-IRC> <jbergler> It doesn't feel unreasonable to expect that `apt-get upgrade` doesn't brick your system after a few years
<DC-IRC> <jbergler> Even if the kernel packages just error'd out saying uboot needs updating, please follow this doc or something
<DC-IRC> <rpardini> Yeah, we'd all like if everything worked perfectly. At same time, supporting legacy/vendor uboot should be done by the vendor, not by open source project done by volunteers.
chewitt has joined #armbian-amlogic
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #armbian-amlogic
chewitt_ has quit [Quit: Zzz..]
<DC-IRC> <jbergler> Yeah, not trying to say that I expect armbian to solve all the problems. Just seems like some slightly more defensive coding in the scripts to error out of expectations aren't met wouldn't be the craziest idea