On Saturday 23 September 2017 13:28:51 Mark Morgan Lloyd wrote: > On 23/09/17 16:45, Gene Heskett wrote: > > On Saturday 23 September 2017 12:26:23 Mark Morgan Lloyd wrote: > >> On 23/09/17 15:00, Gene Heskett wrote: > >>>> I've never had problems with dd provided that the USB->SDcard > >>>> adapter's OK: what command are you using? > >>> > >>> The usual syntax: > >>> dd if=somefile bs=512 of=somedevice, and in the case of sd card > >>> copying, > >> > >> Tell us the /exact/ command you're using. > >> > >>> since no 2 are alike so I usually look at the src's declared size > >>> in dmesg and set count=that-5k so it doesn't error out copying a > >>> pny 32GB to a Sandisk 32GB. Etcher, which is faster, has the same > >>> problem & pitches a fit when it can't find room to put the last 10 > >>> sectors. I've had poor luck with sandisk anything though. pny, > >>> samsung is good stuff. So I bought pny last night. > >> > >> The first thing I'd say is that almost all of the problems I've had > >> stopped when I changed the card reader. I'm now using one badged > >> Canyon which specifically has a Micro-SD slot, i.e. I'm no longer > >> trying to use an adapter which is universally regarded as being > >> unwise. > > > > I have 2 vivitar's, both with microsd slots. They work 100% when > > burning an image file from armbian jessie so far. > > > >> You don't need that bs=512 and trying a sector-by-sector copy on a > >> device that uses far larger blocks might be unwise. I use bs=128M > > > > I'll give that a shot. > > > >> Don't give dd an explicit block count, let it copy everything. That > >> 5k in particular could be worse than useless since it doesn't > >> correspond to a physical or logical block size. > > > > no two sd cards, even from the same maker, are exactly the same size > > due to bad block replacements before they are even blister packed > > for sale. This is the exact reason they ship stripped images that > > require you resize them on the machine they will live in. What we > > dearly need is a utility to generate the iso shrunken to only that > > which is actually used. Or do we have such a critter and I don't > > know about it? > > I know all that, and I've spent a lot of time talking to these things > directly, measuring times, checking pattern-sensitivity and so on. > > And I'd remind you that while we're using similar hardware, you're > having problems, I'm not. What does that suggest to you? :-) > > >> Zeroing the target device first might help, i.e. copying from > >> /dev/zero > >> > >> If the source device has been partitioned to be full, then shrink > >> first the top filesystem and then the top partition to make sure > >> that what you're copying is substantially smaller than the target > >> device. Alternatively a useful hack is to set up your source device > >> with an extra partition at the top, e.g. FAT just in case you want > >> to move data around between OSes, then you can delete the top > >> filesystem and partition before using dd and be confident that you > >> won't be doing an incomplete copy. > > > > Seems like something that could be scripted. > > Yes, for example by the script that Raspbian runs on its first > startup. > > Don't fool around, just make sure that the valid data on the source > card is substantially smaller- and I mean 100s of Mb, not a few Kb- > than the destination card. > > But my suspicion is that you're doing something wrong like trying to > copy one partition when you should be copying all partitions. But > since you won't give us an example of the command you're using we > can't be certain either way on that.
I did, but it was for dd. I have sincefound piclone will run ok, if itsthe first thing after a reboot. Dirty the memory with something else and its dead. So I now have the terrabyte hd cloned from the base of the card. If I ever get it to boot from it, expand the filesystem to a terrabyte. Next problem, I installed the minimal stretch to a 32GB card, and if don't think it resized that 230 mb image, but I'm logged into it, so df gives me: rock64@rock64:~$ df Filesystem 1K-blocks Used Available Use% Mounted on udev 2007908 0 2007908 0% /dev tmpfs 401960 5512 396448 2% /run /dev/mmcblk1p7 30574584 931612 28360464 4% / tmpfs 2009784 0 2009784 0% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 2009784 0 2009784 0% /sys/fs/cgroup /dev/mmcblk1p6 102182 41636 60546 41% /boot/efi tmpfs 401956 0 401956 0% /run/user/1000 So no, its not needing expansion, the whole card is there. I've carved up a /etc/network/interfaces.d/eth0 file with the usual entries, looks like this: rock64@rock64:~$ cat /etc/network/interfaces.d/eth0 #allow-hotplug eth0 auto eth0 iface eth0 inet static address 192.168.NN.2 netmask 255.255.255.0 gateway 192.168.NN.1 ditto, I made a real /etc/resolv.conf, looks like this: rock64@rock64:~$ cat /etc/resolv.conf domain coyote.den nameserver 192.168.NN.1 search hosts dns Both are made immutable so n-m can't putz with them if it is running. According to ps, it is not. If its gone from stretch, I'll need a 6 pack to celebrate that properly. :) So my local network is working as expected. BUT: root@rock64:/etc# ping -c1 yahoo.com PING yahoo.com (98.138.253.109) 56(84) bytes of data. From 192.168.71.2 (192.168.71.2) icmp_seq=1 Destination Host Unreachable Note that the dns request did resolve. But my dns requests are probably being answered by dnsmasq in the router. I cannot find anything in the routers copious settings (it's DD-WRT) that would prevent a connection, but it refuses to pass. I've tried several ipv4 addresses in that 192,168.nn block. No other machines, 5 more, on this local net are being denied network access. Ideas? I'm nearly out of hair. But its been slowly thinning for 82+ years too so I can't blame it on this too loudly. Thanks Mark. 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>
