Lennart: On Thu, Feb 28, 2013 at 9:14 AM, Lennart Sorensen <[email protected]> wrote: > > That bit would be tricky unless you had a part of your storage that was > never written to that contained the code to boot when nothing else worked.
At some point, that's essential. And since you can't change it, you want the LOC for that part to be as small as possible so that you reduce your exposure to defects. That means stripping out everything you can live without. A brain-dead simple u-boot is just fine here, since in the nominal case all it needs to do is pull a kernel+initramfs into memory from a predictable location. That kernel+initramfs is also unlikely to change, at least in my case, because I almost always have enough storage to keep the customer's own kernel and rootfs elsewhere. When I find that (detected by a /boot/zImage in the customer filesystem, for example) I kexec to it. So the customer "updates the kernel" in the device via an ordinary package installation, just like a workstation. But unlike a workstation, the customer doesn't have to worry about really screwing up the system because their kernel isn't the one responsible for initially bringing the core platform to life. On the other hand, I don't have to worry about bringing a kernel that can do EVERYTHING the customer wants it to do, because I know that they can just supplement the system with their own kernel once they decide to do so. The job for my kernel+initramfs is, in most cases, to provide a bare minimum of functionality that either gets me to their kernel, or allows the platform to "phone home" to restore the user's filesystem if necessary. (Kind of like what the recovery partition does on an Android device, but implemented differently). But if things go really bad, and that kernel+initramfs is somehow lost, then it's ok to be much more restrictive about the recovery process since it's a much less likely event. I'll do a board swap, tftp, or something similar. > There is no need to do things 500 different ways. Maybe 10 or 20 > different ways is sufficient (certainly 1 way is likely to be too > restrictive). Agreed. But to be clear, I think what you and I are defining as "different ways" may in fact be different. You and I both run Debian workstations, and both behave in generally the same way even though we both probably have significant differences in e.g. how our networks are set up. And yet we can still manage both machines with the same packaging concepts and sysadmin procedures. Thus, from one perspective our machines are identical: the underlying framework. But we use are using that identical framework to achieve different work products, which is precisely what the framework was designed to allow. I have found that the Debian Way is pretty much the One True Way for dealing robustly with a shockingly wide range of use cases, both yours and mine. I'm just saying that rather than crowding it out by making larger and more functional bootloaders, we should consider going the opposite direction: "debianizing" more and more of what we now think of as the bootloader concept, and marginalizing our true bootloaders farther and farther into the background where they came from. The Debian installer is another instance of what I'm talking about: it sits above the hardware, and does intelligent things. Then it hands control over to the filesystem after it decides everything is ready to go. In fact, it was kind of my inspiration. > Diversity does not mean sprawl is required. Correct. Debian is proof of that. Your workstation, compared to mine, is proof of that. As are all the devices I have here that are running Debian-like configurations, none of which look or act like workstations at all. (The one downside? They all look so similar here that I have to be very careful when I issue a reboot command over SSH. Whoops, wrong target!) > I really hope the ARM servers can do something sane so that they have > a common interface for installation and booting. If they don't I doubt > they will ever be taken seriously. That would be a shame. I agree! But "server" is just one use case, and ARM is a broadly applicable family of SoCs that does wayyyyy more than server workloads. If we are smart about it, we can accommodate a lot of those use cases within a consistent, flexible, and sane framework. Some of us already are. The n2100/n4100 devices are a perfect example of a server-like device that was almost perfectly-executed from a Debian perspective. The only flaw, in my opinion, is that the startup sequence depends on having just one kernel in the system, and that kernel has to live in flash. If that kernel+initramfs instead just did a kexec+pivot_root over to whatever it found on disk, I could put my serial cables away forever. Martin Michlmayr is really, really good. But I think he has as little time as I do for these kinds of things! Does anyone else smell dead horse? :-) b.g. -- Bill Gatliff [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/cadkcauub61rhn5jepqtkjq9dd8bxfqisdpgksd82txsx41m...@mail.gmail.com
