On 25/07/18 19:00, Gene Heskett wrote:
On Wednesday 25 July 2018 07:22:46 Mark Morgan Lloyd wrote:
I have not been successfull at "make pdfdocs", it hits something it
doesn't like in the chapter on networking, not finding a file that is
(or was) installed since this is now armbian, and which an apt-file
find pdftex returns 262 versions of it as available. But which is the
correct version? $64k question, that. Lots of stuff missing for make
pdfdocs, not working yet and apt has drug in close to a gigabyte of
stuff. And apt can't find half of what it wants even then. But it may
have succeeded, now installing okteta, and okular another 150 megs of
dependencies that pulls in for each.
That's something I've never tried I'm afraid, and I suspect that most
people use an online one.
However if you really do need to do that I suggest looking at the
manpage for make, since knowing exactly what command was being run would
probably help you a lot.
But lastly, because I've made some real progress, I need to make an image
backup of / but without the contents of /media/slash because that is
where I'll put the "backup". How the heck do I do that? And what
command is used to image the sd to the eMMC? Then I'll see if it will
boot from the eMMC, then have make make the debs. Seems like a logical
order anyway...
Really depends what you mean by an "image backup". I do a lot of stuff
using "ye olde traditional" dd, either between devices or more often
making an image of the entire device (i.e. including partition table
etc.) to a file and manipulate it there (e.g. by deleting a directory
tree /after/ the data has been copied).
However when using something like dd there's a major problem: you either
want the storage medium to be removed so you can copy the filesystems
offline, or you need to shut every possible piece of running software
down (including things like your SSH daemon) so that nothing's writing
to the disc when you're trying to copy it. Needless to say the same
considerations apply when using dd to do a sector-by-sector copy from
one device to another.
That would normally be done by putting the system into single user mode,
and traditionally that was done using something like the telinit 1
command... and it was that that I complained about at the start of this
thread, since I suspect it was responsible for killing an SDCard in a
TinkerBoard.
There are still ways of working round that sort of problem. For example,
you can copy an entire device using dd to capture boot segments and
partition layout, inspect and recreate the filesystems using mkfs, then
use [something] to copy files one at a time into the new filesystems
taking care that some bootloaders need a wakeup call when a file moves.
As far as "something" is concerned:
dd: Sector-by-sector copy between devices and files.
tar: Good ol' archiver, with directory-exclude etc. options.
netpipes: Do a tar or dd over the LAN.
rsync: File-by-file copy over LAN.
rdist: Ditto, less well-known but with some good points.
parted: Resize a partition.
resize2fs: Resize a filesystem contained in a partition.
So in combination, a fairly common use case would be to dd an entire
device to a file, resize2fs the final filesystem to its minimum size,
parted to reduce the final partition to its minimum size, dd to put the
file onto a new device (noting that even if the size is nominally the
same, it's common for it to be smaller by a piffling few 100s of Mb
hence the palaver of resizing) and finally expand the final partition
and its included filesystem to fit.
I've done rather a lot of that sort of thing, it's very much "old
school". And like everybody else, on at least one occasion I've got the
dd parameters wrong and roached something I really wanted to keep.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
