Re: Resize a disk image from 32G to 4G or copy u-boot?
On Wednesday 25 March 2020 09:51:03 grumpy@mailfence.com wrote:
> On Wed, 25 Mar 2020, Gene Heskett wrote:
> > On Wednesday 25 March 2020 08:51:17 grumpy@mailfence.com wrote:
> >> On Wed, 25 Mar 2020, Gene Heskett wrote:
> >>> On Wednesday 25 March 2020 04:18:20 Andrei POPESCU wrote:
> >>>> On Ma, 24 mar 20, 19:12:46, Gene Heskett wrote:
> >>>>> And nothing so far, and I have been watching, in the way of
> >>>>> reducing a filesystem to only the actual size occupied. Then it
> >>>>> can be backed up with dd and recovered, rewritten by dd, at a
> >>>>> reasonable size for storage. And re-expanded to fit the media
> >>>>> it finds.
> >>>>
> >>>> You could do this with the 'sparse' option of dd (you might need
> >>>> to fill the partition with a file containing only zeroes first).
> >>>>
> >>>> The resulting file must be handled with care as many tools (cp,
> >>>> rsync) will un-sparse it by default, as will writing it to a
> >>>> filesystem without support for sparse files (tar it first).
> >>>>
> >>>> To see the actual size with ls you will have to use -s/--size.
> >>>>
> >>>>> All of my attempts to do that with dd alone have been thwarted
> >>>>> by the fact that I have yet to find two u-sd's marked as such
> >>>>> and such a capacity, that actually were the same size.
> >>>>
> >>>> Just create the partitions slightly smaller than the size of the
> >>>> SD card.
> >>>
> >>> I've also considered that, but then you risk losing the gpt tables
> >>> and it all disappears in the cloud of blue smoke being emmited
> >>> from ones ears.
> >>>
> >>> BTDT at least twice on arm systems. The distro folks have it and
> >>> use it to make an install image of 5 gigs, unpacks to 7 or 8G and
> >>> which can then be auto expanded on the first reboot to fill the
> >>> card, so they know how to do it, why can't the user make backups
> >>> from a deployed well running system that could be put on a fresh
> >>> u-sd card and treated exactly the same for recovery purposes?
> >>
> >> could you not just dd to a file and then manipulate that file to
> >> suit you but i would never dd a running system
> >
> > Amanda has very occassional problems with that as all its backups
> > are from a live system.
>
> doing backups of files and creating an image are apples and oranges
> it sounded like you wanted an image that could be redeployed
> if you create an image and save a copy on your backup server
> exclude it from your amanda backup since it will never change
Not true as I update about weekly. Both raspbian and LinuxCNC which I
build from a fresh git pull of Master about weekly, there by keeping my
debs up to date. And my config also gets updated when more gingerbread
gets added to the GUI. It has several extras such as a readout of both
chuck overtravel at the bottom of the hole and If I export the tpi or
tpmm via an m68 command I get a overshoot depth display which I intend
to ship back to the gcode and use to automatically trim the depth of the
g33.1 command. the idea being to stop it from hitting the bottom of a
blind hole and breaking the tap. One can EDM the broken tap out and save
the part but it takes a good piece of a day to do as my EDM supply is a
bit puny. This is something that LinuxCNC doesn't normally do. Neither
does anybody else's control software that I've come in contact with.
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)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: