* Loïc Minier <[email protected]> [2013-11-09 22:10]: > Well, you'd think this is what /boot is for, but if you add the > constraint that the bootloader needs to be able to read /boot and that > the bootloader only speaks vfat / ext2, you might face painful > situations.
So here's how I see things. In my opinion, there are two separate classes of devices: off the shelve devices that are not easily hackable (i.e. in this case, don't have a serial console by default nor an easy way to recover via JTAG) and other devices that are hackable. The QNAP devices are examples of the first class. While you can add a serial console, it's not there by default and voids your warranty. Furthermore, there's no easy way to recover the system if the bootloader is broken. Therefore, our policy is not to touch the boot loader at all (neither the binary nor the configuration) and live with what we have. This leads to certain hacks in flash-kernel, such as overriding the root device passed to the kernel from the u-boot environment. On the other hand, there are devices like the SheevaPlug, which are made to be hackable. You can easily recover if you flash a broken u-boot. Therefore, we require users to upgrade u-boot and set specific environment variables. Because the SheevaPlug is hackable, I was never interested in supporting other plug devices (like the PogoPlug), which are not. The GuruPlug and DreamPlug are somewhat inbetween since the JTAG module is external because my assumption is that anyone who wants to install Debian will get the JTAG module. Therefore, I think we can expect users to install a specific version of u-boot and set the u-boot environment. As such, I feel that we don't need hacks in flash-kernel that assume that people are running an u-boot that only supports FAT. We can simply tell people to install a different version of u-boot. Of course we can support devices that are restricted, e.g. need the kernel in a specific location. In that case, I don't mind flash-kernel mounting /dev/sda1 and writing stuff there. We can also support devices that need the kernel on a specific partition. In that case, we can even include checks in d-i to ensure that /boot is on that partition. However, I don't think this is the right solution for the DreamPlug, as I consider it a hackable device. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
