On 05/04/2014 06:24 PM, George Gallant wrote:
The fsck problem occurred after installing f2fsprogs. Modified the fstab
file to skip checking.
f2fsprogs? Do you mean e2fsprogs?
Next step is wireless. Seems like wpa_supplicant-gui is also among the
missing. Never knew I
was so dependent on graphical tools for configuration. Still have a set
of Linux Slackware diskettes
from around 1993.
GUI induced skill rot can indeed be subtle yet severe.
When copying the memory device to a host I expect dd to generate an
8-Gbyte file. That
is ok for my limited use but we have a RPi users group near by which is
what started this
trip down the black hole. Will get another memory device to experiment
with shrinking
the partitions.
This is one of the reasons the latest rootfs is only available as a
tarball. It is more compact. All you have to do is partition, mkfs,
mount to a temporary location and extract the tarball, and it's much
faster than dd-ing.
You could, however, make the dd process more efficient with a sparse
image file (2GB in this example, adjust seek= option for different size):
# dd bs=1MB count=0 if=/dev/zero of=/path/to/file.img seek=2048
# losetup /dev/loop0 /path/to/file.img
# mkfs.ext4 -b 4096 /dev/loop0
# mount /dev/loop0 /mnt
# pv /path/to/rootfs.tar.xz | pxz -cd | tar -C /mnt -xf
# umount /mnt
# losetup -d /dev/loop0
# pv /path/to/file.img | pxz > /path/to/file.img.xz
You should now have a reasonably compact, sparse image file file.img.xz.
You may find, however, that dd will still convert the holes into
0-filled blocks when copying the image to a block device so the writing
stage would not actually end up faster, unless your SD card has a clever
enough flash controller to silently throw away 0-filled blocks, like
modern SSDs do.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
