The amanda-client is from a debian-arm stretch repo.
Do I just need to exclude it in the /boot recipe, and make a 3rd disklist
entry just for it? But an ls -l does not show it as a linked directory.
Prowling around in it, there is not a single hint that failed directory
is anything but a normal ext3-4 subdirectory.

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
This message was imported via the External PhorumMail Module

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.

> Greetings;
>
> I added another small machine to my disklist last night, but got this
> error reported this morning:
>
> STRANGE DUMP DETAILS:
> /-- rock64 /boot lev 0 STRANGE
> sendbackup: start [rock64:/boot level 0]
> sendbackup: info BACKUP=/bin/tar
> sendbackup: info RECOVER_CMD=/bin/tar -xpGf - ...
> sendbackup: info end
> ? /bin/tar: ./efi: directory is on a different filesystem; not dumped
> | Total bytes written: 51466240 (50MiB, 6.7MiB/s)
> sendbackup: size 50260
> sendbackup: end
> \--------
>
> The amanda-client is from a debian-arm stretch repo.
> Do I just need to exclude it in the /boot recipe, and make a 3rd disklist
> entry just for it? But an ls -l does not show it as a linked directory.
> Prowling around in it, there is not a single hint that failed directory
> is anything but a normal ext3-4 subdirectory.
>
> However a mount report says this:
> /dev/mmcblk1p6 on /boot/efi type vfat
> (rw,relatime,fmask=0022,dmask=0022,codepage=936,iocharset=utf8,shortname=mixed,errors=remount-ro)
>
> So it does look like I need to adjust the disklist after all?
>
>
>
> Cheers, Gene Heskett
>
This message was imported via the External PhorumMail Module

> 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
This message was imported via the External PhorumMail Module