Re: need sd card backup on r-pi-3b

2017-09-23 Thread Alan Corey 
> I'm out of ideas.  And obviously I cannot configure this rock64 until the
> network works.

It sounds like only 1 machine doesn't work, your email got out after all.

> and 4 other wheezy machines work as expected thru this

So the rock64 has a chance of working.

You don't have something blocking certain MAC addresses, maybe by not
having added it to a table of allowed ones?  Access control list for
the router maybe?

You could try an arp -a but I don't think it'll work past the router.
How about traceroute 8.8.8.8?  Sounds like it's not getting past the
router for whatever reason so it'll probably map up to there and sit
there doing * * *.  Reboot the router?  I don't know what it is in
this case.  Traceroute shows me

zero# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.43.1 (192.168.43.1)  4.728 ms  4.678 ms  4.171 ms
 2  * * *
 3  172.21.192.194 (172.21.192.194)  207.516 ms  226.515 ms  226.393 ms
 4  107.77.252.106 (107.77.252.106)  225.585 ms  338.241 ms  340.453 ms
 5  107.77.252.2 (107.77.252.2)  354.467 ms  375.499 ms  381.571 ms
 6  107.77.254.116 (107.77.254.116)  381.075 ms  363.133 ms  363.692 ms
 7  12.83.186.186 (12.83.186.186)  365.420 ms  363.726 ms  364.198 ms
 8  12.83.185.153 (12.83.185.153)  390.378 ms  384.479 ms  392.005 ms
 9  12.122.28.125 (12.122.28.125)  405.034 ms  404.243 ms  401.788 ms
10  12.122.141.221 (12.122.141.221)  423.779 ms  425.877 ms  444.198 ms
11  12.247.147.22 (12.247.147.22)  444.313 ms  447.099 ms *
12  108.170.249.161 (108.170.249.161)  448.599 ms * *
13  216.239.56.91 (216.239.56.91)  519.419 ms 108.170.228.14
(108.170.228.14)  512.205 ms 216.239.54.229 (216.239.54.229)  509.196
ms
14  209.85.254.185 (209.85.254.185)  517.461 ms
google-public-dns-a.google.com (8.8.8.8)  502.167 ms  506.646 ms
zero#

Having fun with this ZeroW, which runs on about 1 watt.  And it's
about 2 inches long.


On 9/23/17, Gene Heskett  wrote:
> On Saturday 23 September 2017 20:28:08 Alan Corey wrote:
>
>> "Destination Host Unreachable" doesn't mean it didn't resolve, it can
>> mean a cable's unplugged or your netmask isn't right or in  this case
>> it's not getting outside your LAN for whatever reason.  Try pinging an
>> outside IP like 8.8.8.8 (a public Google DNS server).  Ping and dns
>> lookup are 2 different things.
>>
> Ping fails to any address beyond the router, by name or address:
> pinging the router:
> root@rock64Sheldon:~# ping router
> PING router.coyote.den (192.168.71.1) 56(84) bytes of data.
> 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=1 ttl=64
> time=1.60 ms
> 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=2 ttl=64
> time=1.01 ms
> 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=3 ttl=64
> time=1.00 ms
>
> This machine:
> root@rock64Sheldon:~# ping coyote.coyote.den
> PING coyote.coyote.den (192.168.71.3) 56(84) bytes of data.
> 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=1 ttl=64
> time=0.878 ms
> 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=2 ttl=64
> time=0.868 ms
> 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=3 ttl=64
> time=0.853 ms
>
> my ISP:
> root@rock64Sheldon:~# ping shentel.net
> PING shentel.net (204.111.6.122) 56(84) bytes of data.
> From 192.168.71.2 (192.168.71.2) icmp_seq=1 Destination Host Unreachable
> From 192.168.71.2 (192.168.71.2) icmp_seq=2 Destination Host Unreachable
> From 192.168.71.2 (192.168.71.2) icmp_seq=3 Destination Host Unreachable
>
> googles dns:
> root@rock64Sheldon:~# ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> From 192.168.71.2 icmp_seq=1 Destination Host Unreachable
> From 192.168.71.2 icmp_seq=2 Destination Host Unreachable
> From 192.168.71.2 icmp_seq=3 Destination Host Unreachable
>
> I can't see anything in the router settings that would block an outside
> the lan address, and 4 other wheezy machines work as expected thru this
> router.
>
> I'm out of ideas.  And obviously I cannot configure this rock64 until the
> network works.
>
> Humm, iptables is running, and I've not messed with that since 15 years
> ago, don't use it on the local lan net. Killed it and unloaded the
> modules. local ping still works, outside still dead.  Restarted the
> networking, which did not restart iptables or load its modules, but the
> bahavior is unchanged.
>
> Bedtime on this side of the pond. Tomorrow is a new day.
>
> Thanks Alan.
>
>> On 9/23/17, Gene Heskett  wrote:
>> > 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,
>> >> >>

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Gene Heskett 
On Saturday 23 September 2017 20:28:08 Alan Corey wrote:

> "Destination Host Unreachable" doesn't mean it didn't resolve, it can
> mean a cable's unplugged or your netmask isn't right or in  this case
> it's not getting outside your LAN for whatever reason.  Try pinging an
> outside IP like 8.8.8.8 (a public Google DNS server).  Ping and dns
> lookup are 2 different things.
>
Ping fails to any address beyond the router, by name or address:
pinging the router:
root@rock64Sheldon:~# ping router
PING router.coyote.den (192.168.71.1) 56(84) bytes of data.
64 bytes from router.coyote.den (192.168.71.1): icmp_seq=1 ttl=64 
time=1.60 ms
64 bytes from router.coyote.den (192.168.71.1): icmp_seq=2 ttl=64 
time=1.01 ms
64 bytes from router.coyote.den (192.168.71.1): icmp_seq=3 ttl=64 
time=1.00 ms

This machine:
root@rock64Sheldon:~# ping coyote.coyote.den
PING coyote.coyote.den (192.168.71.3) 56(84) bytes of data.
64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=1 ttl=64 
time=0.878 ms
64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=2 ttl=64 
time=0.868 ms
64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=3 ttl=64 
time=0.853 ms

my ISP:
root@rock64Sheldon:~# ping shentel.net
PING shentel.net (204.111.6.122) 56(84) bytes of data.
From 192.168.71.2 (192.168.71.2) icmp_seq=1 Destination Host Unreachable
From 192.168.71.2 (192.168.71.2) icmp_seq=2 Destination Host Unreachable
From 192.168.71.2 (192.168.71.2) icmp_seq=3 Destination Host Unreachable

googles dns:
root@rock64Sheldon:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.71.2 icmp_seq=1 Destination Host Unreachable
From 192.168.71.2 icmp_seq=2 Destination Host Unreachable
From 192.168.71.2 icmp_seq=3 Destination Host Unreachable

I can't see anything in the router settings that would block an outside 
the lan address, and 4 other wheezy machines work as expected thru this 
router.

I'm out of ideas.  And obviously I cannot configure this rock64 until the 
network works.

Humm, iptables is running, and I've not messed with that since 15 years 
ago, don't use it on the local lan net. Killed it and unloaded the 
modules. local ping still works, outside still dead.  Restarted the 
networking, which did not restart iptables or load its modules, but the 
bahavior is unchanged.

Bedtime on this side of the pond. Tomorrow is a new day.  

Thanks Alan.

> On 9/23/17, Gene Heskett  wrote:
> > 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

Re: how to distinguish armel and armhf at runtime?

2017-09-23 Thread Paul Wise 
On Sun, Sep 24, 2017 at 2:42 AM, Uwe Kleine-König wrote:
> On Sat, Sep 23, 2017 at 02:08:28AM +0100, Steve McIntyre wrote:
>> On Fri, Sep 22, 2017 at 09:57:02PM +0200, Uwe Kleine-König wrote:
>> >Hello,
>> >
>> >for the package sparse I have to distinguish armel and armhf. The reason
>> >is that sparse parses system headers and so has to know which cpp
>> >symbols to define. Usually it uses uname -m to distinguish platforms but
>> >that isn't suitable to tell armel and armhf apart.
>> >
>> >For armhf I need to define __ARM_PCS_VFP but that must be absent on armel.
>>
>> Right, that makes sense.
>>
>> >For upstreaming a fix it would be great if the test would not be Debian
>> >specific.
>>
>> That's likely to be difficult - it's perfectly possible to have
>> headers etc. for both on a single system with multi-arch (for
>> example). It's an ABI choice, not a hardware difference.
>>
>> What are you trying to work this out for? Package build time?
>
> No, it's for run time. The target is sparse which can parse C and to be
> able to handle system includes it needs the right cpp variables defined.
>
> Currently the test suite for sparse makes the package FTBFS on armhf:
>
> env CHECK=./sparse ./cgcc -no-compile memops.c
> /usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:12: error: unable to 
> open 'gnu/stubs-soft.h'
>
> The scripts that needs adaption is
>
> http://sources.debian.net/src/sparse/0.5.0-4/cgcc/#L224

That script calls the real compiler to find out various things, so it
sounds like you just need to make it find out what the compiler
include path is:

This appears to be the best option since it works for clang and gcc:

cc -E -Wp,-v - < /dev/null

I guess you can parse the output fine in perl but here is a sed script
to strip out the cruft in the output:

sed -n 's/^ //;/^#include <\.\.\.> search starts here:$/,/^End of
search list\.$/{//!p}'

Info found via these pages:

https://stackoverflow.com/questions/17939930/finding-out-what-the-gcc-include-path-is
https://gcc.gnu.org/ml/gcc-help/2007-09/msg00206.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4917

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Alan Corey 
"Destination Host Unreachable" doesn't mean it didn't resolve, it can
mean a cable's unplugged or your netmask isn't right or in  this case
it's not getting outside your LAN for whatever reason.  Try pinging an
outside IP like 8.8.8.8 (a public Google DNS server).  Ping and dns
lookup are 2 different things.

On 9/23/17, Gene Heskett  wrote:
> 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   5512396448   2% /run
> /dev/mmcblk1p7  30574584 931612  28360464   4% /
> tmpfs2009784  0   2009784   0% /dev/shm
> tmpfs   5120  4  5116   1% /run/lock
> tmpfs2009784  0   2009784   0% /sys/fs/cgroup
> /dev/mmcblk1p6102182  41636

Re: how to distinguish armel and armhf at runtime?

2017-09-23 Thread peter green 

On 23/09/17 19:42, Uwe Kleine-König wrote:

On Sat, Sep 23, 2017 at 02:08:28AM +0100, Steve McIntyre wrote:

On Fri, Sep 22, 2017 at 09:57:02PM +0200, Uwe Kleine-König wrote:

Hello,

for the package sparse I have to distinguish armel and armhf. The reason
is that sparse parses system headers and so has to know which cpp
symbols to define. Usually it uses uname -m to distinguish platforms but
that isn't suitable to tell armel and armhf apart.

For armhf I need to define __ARM_PCS_VFP but that must be absent on armel.

Right, that makes sense.


For upstreaming a fix it would be great if the test would not be Debian
specific.

That's likely to be difficult - it's perfectly possible to have
headers etc. for both on a single system with multi-arch (for
example). It's an ABI choice, not a hardware difference.

What are you trying to work this out for? Package build time?

No, it's for run time. The target is sparse which can parse C and to be
able to handle system includes it needs the right cpp variables defined.

Are people expected to have gcc installed when using this tool? if so gcc 
-dumpmachine may be an option.

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Gene Heskett 
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   5512396448   2% /run
/dev/mmcblk1p7  30574584 931612  28360464   4% /
tmpfs2009784  0   2009784   0% /dev/shm
tmpfs   5120  4  5116   1% /run/lock
tmpfs2009784  0   2009784   0% /sys/fs/cgroup
/dev/mmcblk1p6102182  41636 60546  41% /boot/efi
tmpfs 401956  0401956   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:

Re: how to distinguish armel and armhf at runtime?

2017-09-23 Thread Uwe Kleine-König 
On Sat, Sep 23, 2017 at 02:08:28AM +0100, Steve McIntyre wrote:
> On Fri, Sep 22, 2017 at 09:57:02PM +0200, Uwe Kleine-König wrote:
> >Hello,
> >
> >for the package sparse I have to distinguish armel and armhf. The reason
> >is that sparse parses system headers and so has to know which cpp
> >symbols to define. Usually it uses uname -m to distinguish platforms but
> >that isn't suitable to tell armel and armhf apart.
> >
> >For armhf I need to define __ARM_PCS_VFP but that must be absent on armel.
> 
> Right, that makes sense.
> 
> >For upstreaming a fix it would be great if the test would not be Debian
> >specific.
> 
> That's likely to be difficult - it's perfectly possible to have
> headers etc. for both on a single system with multi-arch (for
> example). It's an ABI choice, not a hardware difference.
> 
> What are you trying to work this out for? Package build time?

No, it's for run time. The target is sparse which can parse C and to be
able to handle system includes it needs the right cpp variables defined.

Currently the test suite for sparse makes the package FTBFS on armhf:

env CHECK=./sparse ./cgcc -no-compile memops.c
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:12: error: unable to 
open 'gnu/stubs-soft.h'

The scripts that needs adaption is

http://sources.debian.net/src/sparse/0.5.0-4/cgcc/#L224

Best regards
Uwe


signature.asc
Description: PGP signature

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Mark Morgan Lloyd 

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.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

Re: how to distinguish armel and armhf at runtime?

2017-09-23 Thread Wookey 
On 2017-09-22 21:57 +0200, Uwe Kleine-König wrote:
> Hello,
> 
> for the package sparse I have to distinguish armel and armhf. The reason
> is that sparse parses system headers and so has to know which cpp
> symbols to define. Usually it uses uname -m to distinguish platforms but
> that isn't suitable to tell armel and armhf apart.
> 
> For armhf I need to define __ARM_PCS_VFP but that must be absent on armel.
> 
> For upstreaming a fix it would be great if the test would not be Debian
> specific.
> 
> Any ideas?

It's just an ABI difference, not a difference in the kernel or
hardware, so you have to look at the files run. So asking gcc or the
glibc in use is one correct way to do it.

gcc -dumpmachine will tell you what triplet applies. I assume that
works on non-debian machines too:
armhf: arm-linux-gnueabihf
armel: arm-linux-gnueabi

For building things in a debian context, normally the right thing to
do is just rely on the compiler to DTRT for the arch targetted. (As
opposed to trying to work out yourself both what arch is in use and
what the right corresponding set of runes is). Not least because the
correct set of runes changes over times. gcc will get this right (i.e
set the correct options for the ABI and for debian), for both
compiling and cross-compiling.



Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Gene Heskett 
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?

> 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.

Thanks Mark.

I'm going to get some legal clothes on, and go write that starter image 
to one or more of these fresh cards. bbl.
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

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Mark Morgan Lloyd 

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.


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


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.


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.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Alan Corey 
Last first, your fstab and your /boot/cmdline.txt have to be pointing
to the partition you want to boot.  Those were the only changes I had
to make when I picloned my sd to my hard drive.  By default they point
to /dev/mmcblk0, change them to something like /dev/sda.  The ones on
the hard drive.

I'm not sure why you have color depth issues, just about everything
I've seen can run 24 bit color just fine.  I edit photos on most of
mine.  X has some capability to mix color depths, so there could be a
16 bit window on a 24 bit screen.  Try xwininfo if you have it, it
will tell you stuff like this on whatever window you click on first:

xwininfo: Window id: 0x802 "rxvt"
  Absolute upper-left X:  135
  Absolute upper-left Y:  56
  Relative upper-left X:  1
  Relative upper-left Y:  30
  Width: 578
  Height: 340
  Depth: 24
  Visual: 0x22
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +135+56  -787+56  -787-404  +135-404
  -geometry 80x24+134+26
That was a window in a vnc session and I could copy and paste it into
Firefox in OpenBSD.  copy/paste to/from vnc works about 70% of the
time

VNC is also called remote framebuffer  A server makes a connection to
X then forwards it over a network connection to a client that displays
it.  There are clients for windows and mac, there's even a java applet
that's a client so you can have a gui desktop on one machine in a web
browser on another.  It's been around for years so it's pretty stable.
No security or encryption, it's not safe to use raw vnc over the
internet, but you can  tunnel it through ssh.  Different versions have
different compression schemes, that gets negotiated between server and
client.  Keyboard and mouse activity go through it, there's no sound.
Color depth is a little muddy because less colors mean more speed,
sometimes 256 are plenty, so it's 1 byte per pixel instead of 2 or 3.
You don't usually have a lot of control over it.

What I have on this pi is:
ii  libvncclient0:armhf0.9.9+dfsg2-6.1+deb8u2
  armhfAPI to write one's own vnc server -
client library
rc  libvncserver0:armhf0.9.9+dfsg2-6.1+deb8u2
  armhfAPI to write one's own vnc server
ii  tightvncserver 1.3.9-6.5
  armhfvirtual network computing server
software
ii  x11vnc-data0.9.13-1.2
  all  data files for x11vnc
ii  xtightvncviewer1.3.9-6.5
  armhfvirtual network computing client
software for X

You probably don't care about the API stuff, you just need a server
and a client.  Tightvnc was a big deal because it used compression,
now it's just one of a dozen or so protocols that the server and
client agree on.  There's an order to the desirability, the client and
server pick the highest one they can both use but they can fall back
to lower ones.  So essentially a vnc client is a vnc client, details
don't matter.  It's remote control yet not: vnc makes its own
connection to the X server so what's happening remotely isn't visible
or accesible on the local machine other than cpu load.  You can't open
a document locally then see it or edit it remotely, you'd need to open
it again.

Your cnc stuff must be taking up the first 9 X connections, that's why
it's so demanding of speed. Most people only have 1 or 2 displays.
Seems like you might be better off with a modern quad or octal core
i386/amd64 machine with a lot of resources.  A gaming machine
essentially with enough cpu (and gpu) to be doing things like 3d
graphics, lots of video ram.

Something's odd here, if I do echo $DISPLAY in an ssh window it's not
even defined yet you're using up yours.  In local rxvt/xterms they all
read the same thing of :0.  I'm not sure it matters.  In fvwm if you
right click on the root window it shows other applications you might
want to switch to.  I've got stuff in 6 of 9 panes of my pager,
connections to 3 other machines.  This is on an old Pentium 4 machine
circa 2002, a Dell gx270.

> restricted things like running synaptic-pkexec to a local keyboard and
Synaptic sounds like a laptop touchpad driver (or a debian application
manager).  I'm not sure that will work in a non-local situation.

> So, tell me more about vnc please.  If it can bypass this crap, and let
> me do gfx stuff as root using sudo, I'll see if I can make it work.

I don't use sudo much, I just log in as root.  I'm not saying everyone
should but I've been doing it for 20 years, old habits die hard.  I
haven't screwed up anything I haven't been able to fix, and I'm behind
a firewall.  Pretty good with regedit in windows too, used to get in
there and

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Jonathan Wilson 
On Fri, 2017-09-22 at 22:07 -0400, Gene Heskett wrote:
> Greetings;
> 
> Trying to dd a copy of the micro-sd card the pi-3b is booting from, to 
> another micro-sd card in a usb reader/writer, and winding up with 
> nothing but an empty lost+found directory on it.
> 
> Obviously some sort of a syntax error, but it still takes the pi several 
> hours to do it, with the traffic led on the reader/writer showing 
> continuous activity.
> 
> Is there another way/util that actually works for making verbatim backups 
> of these limited lifetime sd cards?
> 
> Thanks.
> 
> Cheers, Gene Heskett

I used to use dd quite a lot, usually to a file (from a disk) as I was
playling with virtual boxes quite a bit. It "may" be that the dd is not
from the disk, but is from a partition... or some other variation on the
theme (1). Also, its worth typing sync after the dd to make sure that
all disk access (write) is coalesced. If I recall correctly, once the
sync returns to the command line then there are no more pending writes
so even pulling the SD (not correctly un-mounting/ejecting it) shouldn't
corrupt it. 


(1) When dd'ing between physical drives I always made sure they were
matched size wise, which was probably not required but I had it in my
head that dd'ing a drive including the partition table to a larger sized
drive would cause issues. Where the drives were unmatched I'd set the
new partition(s) manually, and then dd the partitions one at a time and
I always made sure the too partition was set up to be the same size as
the from partition (even if the location differed) and then do any
re-sizing of the cloned partition & file system upwards afterwards. As I
say, possibly not required in some/all cases but gut feelings are hard
to overcome as I had it in my head - something to do with backup tables
set at the far end of partitions.

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Gene Heskett 
On Saturday 23 September 2017 10:58:47 Gene Heskett wrote:

> On Saturday 23 September 2017 07:43:14 Jonathan Wilson wrote:
> > On Fri, 2017-09-22 at 22:07 -0400, Gene Heskett wrote:
> > > Greetings;
> > >
> > > Trying to dd a copy of the micro-sd card the pi-3b is booting
> > > from, to another micro-sd card in a usb reader/writer, and winding
> > > up with nothing but an empty lost+found directory on it.
> > >
> > > Obviously some sort of a syntax error, but it still takes the pi
> > > several hours to do it, with the traffic led on the reader/writer
> > > showing continuous activity.
> > >
> > > Is there another way/util that actually works for making verbatim
> > > backups of these limited lifetime sd cards?
> > >
> > > Thanks.
> > >
> > > Cheers, Gene Heskett
> >
> > I used to use dd quite a lot, usually to a file (from a disk) as I
> > was playling with virtual boxes quite a bit. It "may" be that the dd
> > is not from the disk, but is from a partition... or some other
> > variation on the theme (1). Also, its worth typing sync after the dd
> > to make sure that all disk access (write) is coalesced. If I recall
> > correctly, once the sync returns to the command line then there are
> > no more pending writes so even pulling the SD (not correctly
> > un-mounting/ejecting it) shouldn't corrupt it.
>
> All followed and understood.
>
> > (1) When dd'ing between physical drives I always made sure they were
> > matched size wise, which was probably not required but I had it in
> > my head that dd'ing a drive including the partition table to a
> > larger sized drive would cause issues. Where the drives were
> > unmatched I'd set the new partition(s) manually, and then dd the
> > partitions one at a time and I always made sure the too partition
> > was set up to be the same size as the from partition (even if the
> > location differed) and then do any re-sizing of the cloned partition
> > & file system upwards afterwards. As I say, possibly not required in
> > some/all cases but gut feelings are hard to overcome as I had it in
> > my head - something to do with backup tables set at the far end of
> > partitions.
>
> humm... backup inodes are generally at 8k offsets from the starters
> location, or so I've read.
>
> And why, when I click on reply to list, do I get blank to: lines and
> have to manually copy them from the incoming email?  Its a right pita.

My problem, I didn't have folder marked as containing a mailing list.  
Fixed, sorry for the noise.

> Cheers, Gene Heskett


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

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Gene Heskett 
On Saturday 23 September 2017 07:43:14 Jonathan Wilson wrote:

> On Fri, 2017-09-22 at 22:07 -0400, Gene Heskett wrote:
> > Greetings;
> >
> > Trying to dd a copy of the micro-sd card the pi-3b is booting from,
> > to another micro-sd card in a usb reader/writer, and winding up with
> > nothing but an empty lost+found directory on it.
> >
> > Obviously some sort of a syntax error, but it still takes the pi
> > several hours to do it, with the traffic led on the reader/writer
> > showing continuous activity.
> >
> > Is there another way/util that actually works for making verbatim
> > backups of these limited lifetime sd cards?
> >
> > Thanks.
> >
> > Cheers, Gene Heskett
>
> I used to use dd quite a lot, usually to a file (from a disk) as I was
> playling with virtual boxes quite a bit. It "may" be that the dd is
> not from the disk, but is from a partition... or some other variation
> on the theme (1). Also, its worth typing sync after the dd to make
> sure that all disk access (write) is coalesced. If I recall correctly,
> once the sync returns to the command line then there are no more
> pending writes so even pulling the SD (not correctly
> un-mounting/ejecting it) shouldn't corrupt it.
>
All followed and understood.
>
> (1) When dd'ing between physical drives I always made sure they were
> matched size wise, which was probably not required but I had it in my
> head that dd'ing a drive including the partition table to a larger
> sized drive would cause issues. Where the drives were unmatched I'd
> set the new partition(s) manually, and then dd the partitions one at a
> time and I always made sure the too partition was set up to be the
> same size as the from partition (even if the location differed) and
> then do any re-sizing of the cloned partition & file system upwards
> afterwards. As I say, possibly not required in some/all cases but gut
> feelings are hard to overcome as I had it in my head - something to do
> with backup tables set at the far end of partitions.

humm... backup inodes are generally at 8k offsets from the starters 
location, or so I've read.

And why, when I click on reply to list, do I get blank to: lines and have 
to manually copy them from the incoming email?  Its a right pita.
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

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Gene Heskett 
On Saturday 23 September 2017 04:36:49 Mark Morgan Lloyd wrote:

> On 23/09/17 05:45, Gene Heskett wrote:
> > Months at a time here, but anytime I need to do anything as root
> > that involves more than ncurses graphics, I have to go to the
> > machine and do it there, and its a stand-up job with very poor gfx
> > due to the pi's
>
> In that case investigate what's stopping you from logging in directly
> as root. It's probably a setting in sshd_config and another in the
> display manager's configuration file.
>
> Otherwise if you've got an SSH session as non-root you should be able
> to run arbitrary non-root X11 programs over it i.e.
> tunelling/forwarding X11 over SSH. Once that is working, you should be
> able to use a desktop-specific graphical variant of sudo to run a
> program as root: in the case of KDE it's kdesudo. Or alternatively, in
> an SSH session try sudo -E someprogram  which works in many cases.
>
Thats something I haven't tried, I'll check the sudo man page, thanks.

> 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, 
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.

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

Re: need sd card backup on r-pi-3b

2017-09-23 Thread Mark Morgan Lloyd 

On 23/09/17 05:45, Gene Heskett wrote:


Months at a time here, but anytime I need to do anything as root that
involves more than ncurses graphics, I have to go to the machine and do
it there, and its a stand-up job with very poor gfx due to the pi's


In that case investigate what's stopping you from logging in directly as 
root. It's probably a setting in sshd_config and another in the display 
manager's configuration file.


Otherwise if you've got an SSH session as non-root you should be able to 
run arbitrary non-root X11 programs over it i.e. tunelling/forwarding 
X11 over SSH. Once that is working, you should be able to use a 
desktop-specific graphical variant of sudo to run a program as root: in 
the case of KDE it's kdesudo. Or alternatively, in an SSH session try 
sudo -E someprogram  which works in many cases.


I've never had problems with dd provided that the USB->SDcard adapter's 
OK: what command are you using?


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]