Hi Rick, On Mon, Jan 25, 2016 at 08:13:04PM -0800, Rick Thomas wrote: ... > If something goes wrong with installing grub, you can boot from a CD or > via ethernet and recover or re-install. > If something goes wrong with installing u-boot, you have bricked your > device. The only recourse is J-tag. Not fun at all!
Especially when your boot device is a SD or microSD card, I don't see why
J-tag would be anywhere near what you need to recover. Even when a system
usually runs off an eMMC my impression is that most devices out there still
would allow booting off the SD cards slot if you only inserted a properly
formatted card. T.b.h. I don't really see the risk you try to outline here
(for the platforms I have). If you have the impression that "most" of the
ARM systems out there are only equipped with a single boot device that's not
removable, please do give a list. Otherwise, unbricking a vfat or ext4
partition on a PC should be piece of cake.
> Installing u-boot is something that should only be undertaken very
> carefully if you know what you're doing and are prepared to recover from a
> mishap. Doing it automatically every time there's an update is not wise.
Well, let's assume this:
1.) We've got a growing platform (i.e. current popcon isn't anywhere near
what we expect to have in the next 3-4 year - read: lifespan of next
stable). And we're not talking about the one single box in a lab or
being your one-and-only private server plattform. We're talking about
larger deployments where you would *want* to have unattended-upgrades
and needrestart and alike mechanisms to take certain tasks off your
shoulders (which is what I assume/hope IoT will look like).
2.) We're talking about a Debian stretch being stable (or maybe even what
comes after stretch) - i.e. the u-boot package does only receive
maintenance and security updates.
3.) You're installing u-boot on a platform that you very well know and where
the procedure for updating u-boot is clearly outlined, i.e. no fancy
magic, e.g. just a plain dd file into constant partition.
4.) Assume that we have security hole in u-boot that needs fixing. Debian
security is putting together a DSA and the backported security fix for
the stable release version.
5.) The admin of each and every system has had the chance to enable
auto-updates for u-boot if they feel this a good thing for them under
the configuration they run (e.g. booting from uSD card). The default of
u-boot (for now) shall safely remain that auto-updates aren't enabled
(unless of course the maintainer feels that there's reason to default
otherwise on a given installation).
In this scenario I would think DSA is much happier to just roll out the fix
as-is compared to what we have now. Updating u-boot in jessie will catch at
best 30%, probably rather 3% (or even less) due to the lack of people
understand they need this update *and* knowing how to manually install it.
The part of which platforms and setups can be considered auto-upgrade-safe
would be something I'd leave for further discussion once we have a hook
mimic in place and have some first experiences (and maybe some bugreports).
So, to summarize: all I'm asking for is a hook that I can configure
willingly (if I feel confident enough) to enable this auto-updating for my
systems, in case there'd be any security issues with u-boot in the future
and ensure I don't forget to enable/install them.
Best,
Kilian
signature.asc
Description: Digital signature
