Please... Anyone with experience here, please speak up. I don't want to do anything stupid, but I *do* need to get this issue straightened out.
Thanks in advance for any help! Rick On Thu, Feb 23, 2023, at 10:36 PM, Rick Thomas wrote: > On Thu, Feb 23, 2023, at 8:02 PM, Vagrant Cascadian wrote: >> On 2023-02-23, Rick Thomas wrote: >>> I just noticed that there are no versions of the package "u-boot" available >>> on my SolidRun CuBox-i. >>> However there is a version of "u-boot-imx" available which contains the >>> actual binary >>> code for this machine. >>> Interestingly, I have other arm-based boxes and none of them have this >>> problem. >> >> u-boot (2023.01~rc4+dfsg-2) unstable; urgency=medium >> ... >> * debian/control: Drop u-boot meta-package for armhf and mips. >> ... >> -- Vagrant Cascadian <vagr...@debian.org> Thu, 05 Jan 2023 19:38:24 -0800 >> >> I had meant to deprecate it back in ... maybe 2016 or 2018 and finally >> remembered to do it this release cycle! >> >> The actual binaries you are using come from u-boot-imx since u-boot >> 2014.x versions... >> >> >> live well, >> vagrant > > Ahhh... thanks! That explains it. > > So... Is it true that all I need to do is: > aptitude unmarkauto u-boot-imx > aptitude purge u-boot > ? > > Do I need to do that on all of my arm based machines? If so, is there > an approved way to figure out, for any given machine type, which of the > "uboot-*" packages I should "unmarkauto?"? > > Rick
