I'm find it impossible to do this at the moment, and I need to do so, because I
was surprised to find that SC card I'd built on is just about the max possible >for 16G, so the image won't fit on any others of that nominal size :(
Folderol wrote:
I'm find it impossible to do this at the moment, and I need to do so, because I
was surprised to find that SC card I'd built on is just about the max possible
for 16G, so the image won't fit on any others of that nominal size :(
Not all 16G SD cards are of exactly the same size, they may be a couple
of Megs smaller or larger. You may want to try to write onto the new
card with the "USB Image Tool" and the option "Truncate oversize
images..." set to on. This worked for me on a couple of occastions.
Folderol wrote:
I'm find it impossible to do this at the moment, and I need to do so, because I
was surprised to find that SC card I'd built on is just about the max possible
for 16G, so the image won't fit on any others of that nominal size :(
Not all 16G SD cards are of exactly the same size, they may be a couple
of Megs smaller or larger. You may want to try to write onto the new
card with the "USB Image Tool" and the option "Truncate oversize
images..." set to on. This worked for me on a couple of occastions.
Joerg Walther <usenet2@vocabsheets.de> wrote:
Folderol wrote:
I'm find it impossible to do this at the moment, and I need to do so, because I
was surprised to find that SC card I'd built on is just about the max possible
for 16G, so the image won't fit on any others of that nominal size :(
Not all 16G SD cards are of exactly the same size, they may be a couple
of Megs smaller or larger. You may want to try to write onto the new
card with the "USB Image Tool" and the option "Truncate oversize
images..." set to on. This worked for me on a couple of occastions.
Fsarchiver can restore one of its file system archives to a
differently sized partition, however if you have multiple
partitions then you'll need to create an equivalent partition
table on the new card manually.
I'm find it impossible to do this at the moment, and I need to do so, because I
was surprised to find that SC card I'd built on is just about the max possible
for 16G, so the image won't fit on any others of that nominal size :(
The PiShrink utility seems to do the compression, but the image doesn't work when put on another card.
I'm wondering if it has anything to do with the fact that this is a devuan beowulf build not debian. Just to make it more 'interesting' I can no longer find the image I originally got off the 'net :(
If I ever get to recover this, I'll find an 8G card for the reference build!
Thanks everyone for the suggestions, but somehow all of them failed.
The good news is that I was eventually able to find a compressed image of
a recent (May 2021) build of 64 bit devuan beowulf. I've tested this on one of
my 16G cards and with all the extras I needed for my project it worked perfectly, even though the image is classed as 'experimental'. Also I now know
that the completed build uses less the 4G of the card in total. Therefore the idea of getting an 8G card and building on that as my reference, then flashing
to 16G ones is perfectly feasible.
The project in question is a softsynth one, that I call the YoshimiPi. Here it
is working along with the Rosegarden sequencer.
http://www.musically.me.uk/themainevent/YoshimiPi_Working.jpg
It's pumping out 48kHz 16 bit audio without a single Xrun :)
CPU temperature is just under 60deg C, and that's without a heatsink.
Did you remember to expand the installed filesystem to fill up the card?
On Tue, 29 Jun 2021 14:12:37 +0300
Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
Not necessary with the original install as this automatically expands a first time startup. However, even then fsck reports a bad superblock (although the image runs perfectly well in the Pi). trying to correct this or change the size
Did you remember to expand the installed filesystem to fill up the card?
just seems to stop it working completely.
Bearing in mind the space actually used, even with an 8G card as the reference
one, that still gives over 4G of space for user data.
A collection of over 100 combined Yoshimi + Rosegarden projects is less that 2G
so I don't see the wastage as a problem - besides, should you really trust that
much data to an SD card?
On 29.6.21 22.03, Folderol wrote:
On Tue, 29 Jun 2021 14:12:37 +0300
Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
Not necessary with the original install as this automatically expands a first
Did you remember to expand the installed filesystem to fill up the card? >>>
time startup. However, even then fsck reports a bad superblock (although the >> image runs perfectly well in the Pi). trying to correct this or change the size
just seems to stop it working completely.
Bearing in mind the space actually used, even with an 8G card as the reference
one, that still gives over 4G of space for user data.
A collection of over 100 combined Yoshimi + Rosegarden projects is less that 2G
so I don't see the wastage as a problem - besides, should you really trust that
much data to an SD card?
This means that your way of shrinking the image is not too good.
If you have another Linux computer with enough memory to
store the image, the steps are:
1. Loop mount the image:
sudo losetup -f -P path_to_the_image
2. Check loop setup:
sudo losetup
3. Run gparted on the loop device:
gparted /dev/loopx
where loopx is the device shown on the last losetup
4. Select the ext4 partition and shrink it moving the
top limit down. There must be some free space left
on the shrunk part. gparted knows to complain if the
suggested size is too small.
After shrinking, select 'information' from the
'Partition menu' and note 'Last sector' number.
Remember to save the update partition table.
5. Exit gparted and undo loop setup:
sudo losetup -D
6. The size of the new image is the 'Last sector' number
+ 1 bytes. Truncate the image:
truncate -s the_new_size path_to_image
That's it.
Of course, we need all the utilities necessary for
loop setup, GNU parted and truncate.
The partition resize could be done with resize2fs,
and gparted uses it. I find it easier to let gparted
create the correct commands for the low-level utilities.
| Sysop: | Rempala |
|---|---|
| Location: | Richlands, NC |
| Users: | 103 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 209:15:18 |
| Calls: | 158 |
| Files: | 6 |
| Messages: | 110,592 |
