On Thursday 21 December 2017 07:25:59 Jens Berg wrote: > Hi, > > as you already wrote, /boot/efi is a mount point for a partition of > the flash memory of your main board, so it is in fact a different file > system, not a symlink or such. > If I understood it correctly, the partition is formatted with a > vfat-like file system and holds boot images etc. for your machine. I'm > in doubt that it makes sense to include this stuff in a backup. Even > if you need to do a bare-iron recovery of that machine, you probably > would first re-install the OS, what would update that partition with > your new boot image anyway. So I would go with a simple exclude > statement for /boot/efi in the disklist.
In other words, any real backup and restores will be done with a card reader and an image of the whole card. This cards /boot/efi contents are slated to be overridden with a realtime kernel so that it can run linuxcnc, and with a custom spi driver hacked up out of the one currently running on a pi, and the whole thing then substituted for the pi, which has a architectural problem making it imperative that the pi be retired. /rant mode ON The architectural problem in the pi, is the difficulty of reading a keyboard including its own. The fact that all the i/o data on a pi, except for the spi, must fight for time to get thru the internal usb-2 port, and often fails, resulting in dropped keyboard and mouse events. Once code to run the lathe its running, is into the sd card, it runs the lathe flawlessly because that is all done thru the spi port. But editing that code is a major pain in the ass. It may miss a keyup, key repeat then comes on and you've 23 lines of eeeee in the middle of your code before you can hit enough keys to get its attention again. To top that off, its reboot sensitive so I often have to reboot it quite a few times to reduce that problem to tolerable. When its at its worst, the power switch is the only way to reboot it because you can't type reboot from its own keyboard without its turning into a "reeeeeoooooottttt" because of the missed keyboard events.. So yeah, the pi has got to go. The rock64 is easily 5x faster at booting, and 25x faster at doing an apt update because it does not have this pinhole sized aperture for non-spi i/o. Not to mention that it has potentially 10x faster gfx than the pi, which is stuck in framebuffer mode with a very limited color pallate. I'll try a different exclude file, might even have to write a different variation of tar-comp to deal with it, but I'll get there eventually. Thanks Jens. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
