For some days now I have the board mentioned in the subject, the goal is to have a webserver, git server, and maybe lateron something like a mini-personal-cloud for my family. Yesterday me and my brother finally decided which OS to use - and dd-ed the SD card with the Armbian/Debian Vanilla Jessie Server image (Armbian_5.10_Lime2_Debian_jessie_4.5.2). Some hours later after installing apache2 and trying things out I thought it would be a good idea to do an apt-get upgrade for security reasons before exposing the server to "the world". Unfortunately it was not: The device is not booting any longer after the upgrade. This is the log output of /var/log/apt/term.log (I mounted the SD card at the Linux system on my notebook):
It seems the upgrade routine tried to create a new initrd image, but failed: When I look into the /boot/ directory on the SD card, there really is no file "initrd.img-4.5.5-sunxi" (and from my (admittedly not very deep) linux knowledge there *should* be such a file ^^) and also not the old version 4.5.2.
Now 2 questions:
1. If my diagnosis is correct - does anyone know how to (re)create the file, when the board itself is not longer booting? Can I compile it on the Linux Mint system currently running on my NB? If yes, how? And is that the only thing to fix, or do I have to do more work to... well, get the system back to work?
2. I thought Debian Jessie has reached state 'stable'. So was this incident bad luck? Or is this supposed to happen more often? Since I guess this will not be the last upgrade I run on the server, I *really* don't want to rush to my families house (where the server will be located) every few weeks, only because an update script has blown up the boot files for the server and have to manually recreate them.
Or is there maybe another way to keep the system up-to-date *except* the sensitive kernel/initrd stuff, something like "apt-get safe-upgrade-that-will-not-be-likely-to-touch-the-kernel-and-ruin-my-systems-bootability"?
I would be glad if someone could help me with this issue.
Yup, already found out how to do the first part , only the mkimage command I was still searching for. Interestingly the system also booted without the mkimage step . This way I also found out what the problem with the apt-get upgrade kernel update script was: It seems it has not run "update-initramfs" with the -c switch, only with the -u switch. Thank you very much! Now the only remaining question is why the SSH fingerprint of the server got regenerated on every boot (so that ssh complained on reconnecting about a probable Man-in-the-middle-attack) before the system upgrade, and now that problem is gone. But that is 1) a completely different problem and 2) - as I said - it is gone, so I don't bother ^^.