Karl Southern wrote: > Would I be correct in assuming that u-boot chain loads the linux kernel > directly from the hard disk(s) /boot/vmlinuz, in some way shape or form? Assuming that you followed the Debian installation instructions and are using a Debian kernel, that is not correct. Both kernel and initrd are loaded from flash memory. > In that case presumably if the disk(s) that the kernel are sat on go > away, the environment becomes unbootable? Assuming that's correct the > method of recovery would be serial connector and then manipulating > u-boot's configuration? Some embedded (NAS) devices have an "emergency flash procedure" that will restore the original firmware. Current QNAP systems do not have that. That does in general leave serial console as the only option for recovery if things have gone really bad, but you probably would not need to actually modify the uboot configuration. In most cases you'd just need to use some uboot commands to set things right again. For some types of problem you might be able to attach the harddisk to another system, but the problem is that in most cases you won't know what the problem is without serial console anyway. > Finally, I assume that the only way to manipulate u-boot is directly via > a console session, and that it cannot be modified from a currently > running instance of Linux, on the same machine? There are tools to e.g. modify the uboot environment variables from linux, but the are not packaged for Debian and it's unknown how safe they are. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.