Cautionary tale: how to kill an SDCard with one simple command

[Gene Heskett]

I wanted to do a bit of low-level maintenance yesterday evening on a
TinkerBoard (Rockchip RK3288) running Stretch, so as an old PC hand I
ran telinit 1 At that point the SDCard became a boat anchor.
Now I'm obviously not entirely sure about this, and it /could/ be an
unfortunate coincidence. But unless absolutely sure, it might be a
hack best avoided.

I've used 'ssh -Y ***@hostname' for that telnet connection for ages, and
cannot recall toasting an SD card doing it. I also use an sshfs mount
for moving stuff around. It seems to work for me with a lot less hassle
than an nfsv4 mount ever has. ymmv of course.

[Gene Heskett]

I wanted to do a bit of low-level maintenance yesterday evening on
a TinkerBoard (Rockchip RK3288) running Stretch, so as an old PC
hand I ran telinit 1 At that point the SDCard became a boat
anchor.
Now I'm obviously not entirely sure about this, and it /could/ be
an unfortunate coincidence. But unless absolutely sure, it might be
a hack best avoided.

ages, and cannot recall toasting an SD card doing it. I also use an
sshfs mount for moving stuff around. It seems to work for me with a
lot less hassle than an nfsv4 mount ever has. ymmv of course.

That's absolutely nothing to do with telnet, that puts the OS into
single-user mode and I suspect it killed something that was necessary
for the survival of the card- or perhaps it just killed something at a
highly inopportune time.
I'd been comparing the performance of a Rockchip-based board's LAN and
USB against an RPi3B+, results were satisfactory. There's a modicum of
muttering that the 3B+ has broken something relating to the LAN or
USB.

I'm convinced its the internal usb2 hub that all i/o except the radio
and spi has to go thru. It has a rather annoying tendency to throw away
its own mouse and keyboard events. Thats not at all a pleasant
occurrance when the tossed event is a keyup, and it left 1500 lbs of
machinery moving with no stop except crashing into something. OTOH, once
code has been coaxed into a file, that file can run that same machinery
to do micron accurate work. The machine control is thru spi, writing 32
bit packets at 41 megabaud, and reading the responses 32 bits at a pop
at 25 megabaud.

So as far as machine control is concerned it works great. Funny (not)
part is that when the keyboard and mouse are miss-behaving, a powerdown
reboot, sometimes more than once, fixes it, and when fixed, it stays
fixed and uptimes can be from now to the next power failure. This
particular pi3b has its kernel and initramfs files pinned as they are
the first, and best versions of a pre-emptible kernel tried, the later 2
were even worse at the missed events from its local input.

Linuxcnc requires a pre-emptible kernel as a pre-requisite, rtai patches
are even better but this particular systems fastest thread runs at 1
kilohertz since it has hardware stepper drivers on the interface card.
I also have a bunch of manual controls mounted on the carriage apron,
replacing the hand cranks that moved this machine for its first 70
years, but with the relative eternity of human hand driven dials, a 200
hz thread is plenty fast enough for that. All of that works thru the
spi interface which is not subject to the missed events problem.

Some jessie armhf update seems to have made the missed events much less
of a problem since the original install over a year ago. So I haven't
had to reboot,test,reboot,test,reboot till it works recently.

Jessie's arm64 runs a heck of a lot better than stretch on the rock64's
in arm64 format. Networking on stretch is a non-working mess that takes
hand intervention to make work for instance. Too bad the debian crew
didn't add arm64 to the jessie menu. Now I expect it will be yet another
release after stretch before its anywhere near stable. I'm, in fairness
to debian, running ayufan's stuff. Why? Because even yesterday, I could
not find an arm64 stretch install for the rock64 on debian's ftp site.
If it exists, its very well hidden. Its claimed to be supported now, but
its obviously not going to get used if it cannot be found.

My $0.02.

[Alan Corey]

I'm liking Buster, I've been running arm64 that on this Pi since
November by the date on my sources.list. Also pulling from unstable:

deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian unstable main contrib non-free

Smooth as silk at least for what I do. As expected it's a little
bigger and a little faster compared to 32-bit.

I've heard conflicting stories about whether you can jump versions by
just changing your sources.list then doing updates and upgrades in the
new version. Might be worth cloning a machine that works well then
trying to upgrade it. I haven't found anything that works wel on my
Rock64.

Then there's always Armbian but I didn't care much for it.

Post by Gene Heskett

I wanted to do a bit of low-level maintenance yesterday evening on
a TinkerBoard (Rockchip RK3288) running Stretch, so as an old PC
hand I ran telinit 1 At that point the SDCard became a boat
anchor.
Now I'm obviously not entirely sure about this, and it /could/ be
an unfortunate coincidence. But unless absolutely sure, it might be
a hack best avoided.

ages, and cannot recall toasting an SD card doing it. I also use an
sshfs mount for moving stuff around. It seems to work for me with a
lot less hassle than an nfsv4 mount ever has. ymmv of course.

That's absolutely nothing to do with telnet, that puts the OS into
single-user mode and I suspect it killed something that was necessary
for the survival of the card- or perhaps it just killed something at a
highly inopportune time.
I'd been comparing the performance of a Rockchip-based board's LAN and
USB against an RPi3B+, results were satisfactory. There's a modicum of
muttering that the 3B+ has broken something relating to the LAN or
USB.

I'm convinced its the internal usb2 hub that all i/o except the radio
and spi has to go thru. It has a rather annoying tendency to throw away
its own mouse and keyboard events. Thats not at all a pleasant
occurrance when the tossed event is a keyup, and it left 1500 lbs of
machinery moving with no stop except crashing into something. OTOH, once
code has been coaxed into a file, that file can run that same machinery
to do micron accurate work. The machine control is thru spi, writing 32
bit packets at 41 megabaud, and reading the responses 32 bits at a pop
at 25 megabaud.
So as far as machine control is concerned it works great. Funny (not)
part is that when the keyboard and mouse are miss-behaving, a powerdown
reboot, sometimes more than once, fixes it, and when fixed, it stays
fixed and uptimes can be from now to the next power failure. This
particular pi3b has its kernel and initramfs files pinned as they are
the first, and best versions of a pre-emptible kernel tried, the later 2
were even worse at the missed events from its local input.
Linuxcnc requires a pre-emptible kernel as a pre-requisite, rtai patches
are even better but this particular systems fastest thread runs at 1
kilohertz since it has hardware stepper drivers on the interface card.
I also have a bunch of manual controls mounted on the carriage apron,
replacing the hand cranks that moved this machine for its first 70
years, but with the relative eternity of human hand driven dials, a 200
hz thread is plenty fast enough for that. All of that works thru the
spi interface which is not subject to the missed events problem.
Some jessie armhf update seems to have made the missed events much less
of a problem since the original install over a year ago. So I haven't
had to reboot,test,reboot,test,reboot till it works recently.
Jessie's arm64 runs a heck of a lot better than stretch on the rock64's
in arm64 format. Networking on stretch is a non-working mess that takes
hand intervention to make work for instance. Too bad the debian crew
didn't add arm64 to the jessie menu. Now I expect it will be yet another
release after stretch before its anywhere near stable. I'm, in fairness
to debian, running ayufan's stuff. Why? Because even yesterday, I could
not find an arm64 stretch install for the rock64 on debian's ftp site.
If it exists, its very well hidden. Its claimed to be supported now, but
its obviously not going to get used if it cannot be found.
My $0.02.
--
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Gene Heskett]

Post by Gene Heskett

I'd been comparing the performance of a Rockchip-based board's LAN
and USB against an RPi3B+, results were satisfactory. There's a
modicum of muttering that the 3B+ has broken something relating to
the LAN or USB.

I'm convinced its the internal usb2 hub that all i/o except the
radio and spi has to go thru. It has a rather annoying tendency to
throw away its own mouse and keyboard events. Thats not at all a
pleasant occurrance when the tossed event is a keyup, and it left
1500 lbs of machinery moving with no stop except crashing into
something. OTOH, once code has been coaxed into a file, that file
can run that same machinery to do micron accurate work. The machine
control is thru spi, writing 32 bit packets at 41 megabaud, and
reading the responses 32 bits at a pop at 25 megabaud.

The focus of people's ire ATM appears to be the RPi3B+, where the
design has changed the chip that implements LAN and USB hub
functionality. Over the last few days I've put a lot of time into this
as the culmination of a ridiculous amount of routing/firewalling
testing, and while I'd quite like to be able to accumulate more
results what I can say so far is that while a TinkerBoard can receive
a data stream over 1GBit/sec Ethernet and farm it out to at least
three USB-connected 100MBit adapters before performance starts
degrading, an RPi3B+ can only handle one and when a second is added
performance is distributed unevenly... don't even dream of adding a
third.
The RPi range is good for what it was initially designed for, but that
LAN/USB chip appears to be its weakness. I've not sought out a
datasheet or worked my way through the kernel yet, but it looks as
though there's some sort of prioritisation in there that can get out
of kilter.
Gene, is it one of these
https://www.pine64.org/?product=rock64-media-board-computer that
you're currently running to good effect?

Yes, the 4Gb version. But while it can build the latest (yesterdays
release) rt kernel in about 3 hours, I haven't figured out how to
install it yet. 220 megs uncompressed. But I'm trying to make pdfdocs,
and don't have enough of sphinx installed to get sphinx-build, according
to the make file error. Doing an install sphinx-* says everthing that
globs to is installed and current. Sigh. Finally got enough python and
perl installed that its making pdfdocs now, but that one hell of a bug
finder, missing xrefs by the megabyte.

And something is wrong with the locale, even a "dpkg-reconfigure locale"
cannot create the locale vars needed. Getting a 9 line complaint from
perl for every file processed. I was able to fix the paper size to
letter from a default of A4 before I started making the docs in pdf.
When it gets done, maybe I'll learn something? It must be generating
quite a few gigabytes of pdf's.

And I have laundry to tend to, back later, its been munching on media-tex
for about 15 minutes now, with 3 screens worth of included files.

And just bailed out with a weird message:
build succeeded, 41 warnings.
make PDFLATEX=xelatex LATEXOPTS="-interaction=batchmode" -C
Documentation/output/./latex || exit;
xelatex -interaction=batchmode 'userspace-api.tex'
This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/Debian)
(preloaded format=xelatex)
restricted \write18 enabled.
entering extended mode
Makefile:66: recipe for target 'userspace-api.pdf' failed
make[2]: *** [userspace-api.pdf] Error 1
Documentation/Makefile:85: recipe for target 'pdfdocs' failed
make[1]: *** [pdfdocs] Error 2
Makefile:1523: recipe for target 'pdfdocs' failed
make: *** [pdfdocs] Error 2

Damn! Why the heck can't it say why?

Sigh.

Remainder noted with interest.

[Alan Corey]

Error 2 is file not found, at least in C. Don't know what it's looking for.

Sent from my Motorola XT1527

Post by Gene Heskett

Post by Gene Heskett

I'd been comparing the performance of a Rockchip-based board's LAN
and USB against an RPi3B+, results were satisfactory. There's a
modicum of muttering that the 3B+ has broken something relating to
the LAN or USB.

I'm convinced its the internal usb2 hub that all i/o except the
radio and spi has to go thru. It has a rather annoying tendency to
throw away its own mouse and keyboard events. Thats not at all a
pleasant occurrance when the tossed event is a keyup, and it left
1500 lbs of machinery moving with no stop except crashing into
something. OTOH, once code has been coaxed into a file, that file
can run that same machinery to do micron accurate work. The machine
control is thru spi, writing 32 bit packets at 41 megabaud, and
reading the responses 32 bits at a pop at 25 megabaud.

The focus of people's ire ATM appears to be the RPi3B+, where the
design has changed the chip that implements LAN and USB hub
functionality. Over the last few days I've put a lot of time into this
as the culmination of a ridiculous amount of routing/firewalling
testing, and while I'd quite like to be able to accumulate more
results what I can say so far is that while a TinkerBoard can receive
a data stream over 1GBit/sec Ethernet and farm it out to at least
three USB-connected 100MBit adapters before performance starts
degrading, an RPi3B+ can only handle one and when a second is added
performance is distributed unevenly... don't even dream of adding a
third.
The RPi range is good for what it was initially designed for, but that
LAN/USB chip appears to be its weakness. I've not sought out a
datasheet or worked my way through the kernel yet, but it looks as
though there's some sort of prioritisation in there that can get out
of kilter.
Gene, is it one of these
https://www.pine64.org/?product=rock64-media-board-computer that
you're currently running to good effect?

Yes, the 4Gb version. But while it can build the latest (yesterdays
release) rt kernel in about 3 hours, I haven't figured out how to
install it yet. 220 megs uncompressed. But I'm trying to make pdfdocs,
and don't have enough of sphinx installed to get sphinx-build, according
to the make file error. Doing an install sphinx-* says everthing that
globs to is installed and current. Sigh. Finally got enough python and
perl installed that its making pdfdocs now, but that one hell of a bug
finder, missing xrefs by the megabyte.
And something is wrong with the locale, even a "dpkg-reconfigure locale"
cannot create the locale vars needed. Getting a 9 line complaint from
perl for every file processed. I was able to fix the paper size to
letter from a default of A4 before I started making the docs in pdf.
When it gets done, maybe I'll learn something? It must be generating
quite a few gigabytes of pdf's.
And I have laundry to tend to, back later, its been munching on media-tex
for about 15 minutes now, with 3 screens worth of included files.
build succeeded, 41 warnings.
make PDFLATEX=xelatex LATEXOPTS="-interaction=batchmode" -C
Documentation/output/./latex || exit;
xelatex -interaction=batchmode 'userspace-api.tex'
This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/Debian)
(preloaded format=xelatex)
restricted \write18 enabled.
entering extended mode
Makefile:66: recipe for target 'userspace-api.pdf' failed
make[2]: *** [userspace-api.pdf] Error 1
Documentation/Makefile:85: recipe for target 'pdfdocs' failed
make[1]: *** [pdfdocs] Error 2
Makefile:1523: recipe for target 'pdfdocs' failed
make: *** [pdfdocs] Error 2
Damn! Why the heck can't it say why?
Sigh.

Remainder noted with interest.

--
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Gene Heskett]

Post by Alan Corey
Error 2 is file not found, at least in C. Don't know what it's looking for.

userspace.api the named string in a previous not show stopper failure, it
is a directory and contains:
conf.py index.rst no_new_privs.rst seccomp_filter.rst unshare.rst

Might be a typu in the makefile. Next check at least. But didn't get that
far, hit conf.py first, & cat conf.py shows---
conf.py:
# -*- coding: utf-8; mode: python -*-

project = "The Linux kernel user-space API guide"

tags.add("subproject")

latex_documents = [
('index', 'userspace-api.tex', project,
'The kernel development community', 'manual'),
]

and userspace-api.tex does not exist.

linux-rt-users list CC'd.

[g***@manlymail.net]

take a look at
https://odroidinc.com/products/odroid-xu4

[g***@manlymail.net]

take a look at
https://odroidinc.com/products/odroid-xu4

[Gene Heskett]

Post by g***@manlymail.net
take a look at
https://odroidinc.com/products/odroid-xu4

I have one, bricked, it has a uefi bios and at the time, the linux
installer had no clue how to deal with it. The only option I could find
in the bios was to disable the tcp chip, which bricked it, and a jtag
programmer and adapter worth more than the odroid is required to restore
it. This is NOT mentioned ANYPLACE is the sales propaganda on their site
or in this link. Had they not been drinking the windows koolaid, it
might have been able to do my job, but AFAIAC, they sold me the s.o.b.
under false pretenses. That bios according to US law, is sick bird as
there is supposed to be a way it can be turned off, but there is not.

[Lennart Sorensen]

We've got an ODroid. The impression I got was that the hardware was fairly
well done, but that the distro that came with it (some variant of Ubuntu)
rather less so... the usual things about missing dependencies which can make
things very flaky (e.g. autoremove broke X11 beyond repair).
My recollection of the UEFI situation is that Intel et al. made "Secure
Boot" optional on PCs but mandatory on ARM systems that had UEFI.

Microsoft made that a rule for devices that are Windows Certified.
x86 devices with Windows should have an option to let the user decide
about secureboot (but it must be on by default), while arm devices must
always use secureboot with Windows.

Intel had nothing to do with that.

[Gene Heskett]

On Sat, 21 Jul 2018 15:42:41 -0400

Post by Gene Heskett

Post by g***@manlymail.net
https://odroidinc.com/products/odroid-xu4

I have one, bricked, it has a uefi bios and at the time, the linux
installer had no clue how to deal with it. The only option I could
find in the bios was to disable the tcp chip, which bricked it, and
a jtag programmer and adapter worth more than the odroid is required
to restore it. This is NOT mentioned ANYPLACE is the sales
propaganda on their site or in this link. Had they not been drinking
the windows koolaid, it

I'm a little confused by this. Are you saying that they put UEFI on
the ODROID XU4 so that it could run Windows? As you said, this is not
mentioned anyplace in the marketing info, but I can't find it
mentioned anywhere else either. I also see no claims that the XU4
could run Windows.
Did you ever discuss this with Hardkernel (preferably in a public
forum like https://forum.odroid.com/)? Did they acknowledge or deny
the UEFI situation?

They acknowledged it, and told me how to fix it, but the fix cost more
than the odroid, a jtag programmer and a special cable that cost well
over $125 is required. And someone else recently advised me that UEFI
bypassing in the bios was only legal on x86 stuffs. If thats so, I'd
push for legislation to outlaw the whole concept as it is unfair
competition to me, and microsoft should owe damages to everyone that got
burnt as I did. In any event, I've not been back to their site and if
they starve I could care less. Get screwed once, shame on them, twice,
shame on me.

The only possible mention is at
<https://forum.odroid.com/viewtopic.php?f=138&t=20593>
Smarter folks than I might be able to build a workaround, but they were
pretty carefull how that subject was covered. u-boot might be able to
deal with it, but I haven't studied up on that enough to say. The rock64
gets around it but I've no clue how that works either.

I have successfully built the linux-rt kernels on both the pi and the
rock64, but now I cannot find a utility that will actually update the sd
cards boot code to install the replacement code, and questions about how
to do this seem to be ignored on all the revelant forums. zero answers
other than a few links to code from 2011 & 2012 that seems to be
unrelated have been supplied. I do know that dpkg knows how to deal with
it as I've seen its onscreen log while doing it on the rock64, but it
doesn't seem to be covered in the dpkg man pages. Also a stumbling
block, make doesn't know how to "make" a vmlinuz, only huge vmlinux, and
no initrd's. But I have made those. example:
ls -l /media/slash/v4.16.18-rt10/
total 798300
drwxr-xr-x 33 gene gene 4096 Jul 20 00:42 arch
drwxr-xr-x 3 gene gene 4096 Jul 21 07:08 block
-rw-r--r-- 1 gene gene 744766 Jul 21 08:08 built-in.o
drwxr-xr-x 2 gene gene 4096 Jul 21 06:52 certs
-rw-r--r-- 1 gene gene 148020 May 27 18:39
config-4.4.126-rockchip-ayufan-239
-rw-r--r-- 1 gene gene 18693 Jul 20 00:42 COPYING
-rw-r--r-- 1 gene gene 98556 Jul 20 00:42 CREDITS
drwxr-xr-x 4 gene gene 12288 Jul 21 08:15 crypto
drwxr-xr-x 125 gene gene 12288 Jul 21 18:47 Documentation
drwxr-xr-x 136 gene gene 4096 Jul 21 08:08 drivers
drwxr-xr-x 2 gene gene 4096 Jul 21 07:11 firmware
drwxr-xr-x 73 gene gene 12288 Jul 21 07:40 fs
drwxr-xr-x 29 gene gene 4096 Jul 20 16:52 include
drwxr-xr-x 2 gene gene 4096 Jul 21 08:08 init
drwxr-xr-x 2 gene gene 4096 Jul 21 07:03 ipc
-rw-r--r-- 1 gene gene 2245 Jul 20 00:42 Kbuild
-rw-r--r-- 1 gene gene 287 Jul 20 00:42 Kconfig
drwxr-xr-x 17 gene gene 12288 Jul 21 07:03 kernel
drwxr-xr-x 13 gene gene 20480 Jul 21 08:15 lib
drwxr-xr-x 5 gene gene 4096 Jul 20 00:42 LICENSES
-rw-r--r-- 1 gene gene 446794 Jul 20 00:42 MAINTAINERS
-rw-r--r-- 1 gene gene 62082 Jul 20 00:42 Makefile
drwxr-xr-x 3 gene gene 12288 Jul 21 06:57 mm
-rw-r--r-- 1 gene gene 19130 Jul 21 06:51 modules.builtin
-rw-r--r-- 1 gene gene 27819 Jul 21 08:10 modules.order
-rw-r--r-- 1 gene gene 637973 Jul 21 08:10 Module.symvers
drwxr-xr-x 68 gene gene 4096 Jul 21 07:59 net
-rw-r--r-- 1 gene gene 148020 May 27 18:39 oldconfig
-rw-r--r-- 1 gene gene 722 Jul 20 00:42 README
drwxr-xr-x 28 gene gene 4096 Jul 20 00:43 samples
drwxr-xr-x 14 gene gene 4096 Jul 21 06:51 scripts
drwxr-xr-x 10 gene gene 4096 Jul 21 07:04 security
drwxr-xr-x 25 gene gene 4096 Jul 21 07:11 sound
-rw-r--r-- 1 gene gene 3918000 Jul 21 08:10 System.map
drwxr-xr-x 31 gene gene 4096 Jul 20 00:43 tools
drwxr-xr-x 2 gene gene 4096 Jul 21 06:51 usr
drwxr-xr-x 4 gene gene 4096 Jul 21 07:48 virt
-rwxr-xr-x 1 gene gene 220318224 Jul 21 08:10 vmlinux
-rw-r--r-- 1 gene gene 590810760 Jul 21 08:09 vmlinux.o

It took something just over 1 hour to build that on the rock64. On an
120GB SSD mounted to /media/slash via a sata to usb-3 adapter, so I
wasn't beating the sd card to death. What I'd like to do is copy that sd
to the eMMC module, plugged in but empty ATM and do the installs to the
eMMC memory, so it boots from a known good boot, but will use the eMMC
as the bootable medium if the sd card is removed. That way I'd have a
fallback rescue path if the install on the eMMC card is broken. Just
plug the sd card back in and push the power button.

Perhaps I am a dreamer?

[Gene Heskett]

Post by Gene Heskett

On Sat, 21 Jul 2018 15:42:41 -0400

Post by Gene Heskett

Post by g***@manlymail.net
https://odroidinc.com/products/odroid-xu4

I have one, bricked, it has a uefi bios and at the time, the linux
installer had no clue how to deal with it. The only option I could
find in the bios was to disable the tcp chip, which bricked it,
and a jtag programmer and adapter worth more than the odroid is
required to restore it. This is NOT mentioned ANYPLACE is the
sales propaganda on their site or in this link. Had they not been
drinking the windows koolaid, it

I'm a little confused by this. Are you saying that they put UEFI
on the ODROID XU4 so that it could run Windows? As you said, this
is not mentioned anyplace in the marketing info, but I can't find
it mentioned anywhere else either. I also see no claims that the
XU4 could run Windows.
Did you ever discuss this with Hardkernel (preferably in a public
forum like https://forum.odroid.com/)? Did they acknowledge or
deny the UEFI situation?

They acknowledged it, and told me how to fix it, but the fix cost
more than the odroid, a jtag programmer and a special cable that
cost well

Did you get them to acknowledge this in /public/, i.e. where
prospective customers can see it?

It, unless its been erased to protect the guilty, should be in that
forums msg base, but I've long since forgotten the subject line. Nearly
2 years ago now.

Post by Gene Heskett
over $125 is required. And someone else recently advised me that
UEFI bypassing in the bios was only legal on x86 stuffs. If thats
so, I'd

"Only legal" in the USA, and I regret to say that it's /your/
political system that enabled things like the DMCA.

Touche` It damned sure wasn't something I wanted, and told my congress
critters so at the time, but big checks from the stakeholders can always
buy the votes they need to get anything they want. Democracy has sadly
developed into a highest bidder gets the job over the last 150 years.
Goes along with the winners always getting to write the history books I
guess.

Post by Gene Heskett
push for legislation to outlaw the whole concept as it is unfair
competition to me, and microsoft should owe damages to everyone that
got burnt as I did. In any event, I've not been back to their site
and if they starve I could care less. Get screwed once, shame on
them, twice, shame on me.
The only possible mention is at
<https://forum.odroid.com/viewtopic.php?f=138&t=20593>
Smarter folks than I might be able to build a workaround, but they
were pretty carefull how that subject was covered. u-boot might be
able to deal with it, but I haven't studied up on that enough to
say. The rock64 gets around it but I've no clue how that works
either.
I have successfully built the linux-rt kernels on both the pi and
the rock64, but now I cannot find a utility that will actually
update the sd cards boot code to install the replacement code, and
questions about how to do this seem to be ignored on all the
revelant forums. zero answers other than a few links to code from
2011 & 2012 that seems to be unrelated have been supplied. I do know
that dpkg knows how to deal with it as I've seen its onscreen log
while doing it on the rock64, but it doesn't seem to be covered in
the dpkg man pages. Also a stumbling block, make doesn't know how to
"make" a vmlinuz, only huge vmlinux, and no initrd's. But I have
made those.

In the kernel source directory run make help | less and check the
section "Architecture specific targets" towards the bottom, then what
formats your loader etc. supports. As I said a few days ago, initrd is
made by distro-specific tools, it has to be done that way since apart
from the format it's really got very little to do with the kernel per
se.

I'll do that make help|less, thanks. How about make help >filename so I
can load and print it with geany? Done, and printed.

I have not been successfull at "make pdfdocs", it hits something it
doesn't like in the chapter on networking, not finding a file that is
(or was) installed since this is now armbian, and which an apt-file
find pdftex returns 262 versions of it as available. But which is the
correct version? $64k question, that. Lots of stuff missing for make
pdfdocs, not working yet and apt has drug in close to a gigabyte of
stuff. And apt can't find half of what it wants even then. But it may
have succeeded, now installing okteta, and okular another 150 megs of
dependencies that pulls in for each.

There were 3 reported warnings and a 4th I saw go by.
Highlighting of certain text will be skipped. couldn't lex something.

The 3 errors are:

build succeeded, 3 warnings.
make PDFLATEX=xelatex LATEXOPTS="-interaction=batchmode" -C
Documentation/output/./latex || exit;
xelatex -interaction=batchmode 'dev-tools.tex'
This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/Debian)
(preloaded format=xelatex)
restricted \write18 enabled.
entering extended mode
Makefile:66: recipe for target 'dev-tools.pdf' failed
make[2]: *** [dev-tools.pdf] Error 1
Documentation/Makefile:85: recipe for target 'pdfdocs' failed
make[1]: *** [pdfdocs] Error 2
Makefile:1523: recipe for target 'pdfdocs' failed
make: *** [pdfdocs] Error 2

Post by Gene Heskett
It took something just over 1 hour to build that on the rock64. On
an 120GB SSD mounted to /media/slash via a sata to usb-3 adapter, so
I wasn't beating the sd card to death. What I'd like to do is copy
that sd to the eMMC module, plugged in but empty ATM and do the
installs to the eMMC memory, so it boots from a known good boot, but
will use the eMMC as the bootable medium if the sd card is removed.
That way I'd have a fallback rescue path if the install on the eMMC
card is broken. Just plug the sd card back in and push the power
button.

Usual caveat about not getting anything on the eMMC that subsequently
prevents you booting from SDCard etc. I for one always feel a bit
queasy about writing to non-removable Flash devices.

I would not claim its not removable, I assume it can be lifted back out
of the socket since I had to insert it into the socket. The trick is
probably in a boot priority setting someplace so it boots from the sd
card if its present, eMMC if its not. Wishfull thinking perhaps but it
would make a lot of sense to do it that way. OTOH, if there was a
lawyer in the building, any and all bets are null and void. :(

I'm like that fellow Shakespear, first we kill all the lawyers.

We had a removable Odroid eMMC module that died, they subsequently
admitted (in public) that they'd had manufacturing problems.

Humm, wonder if that applies to these rock64's too as they are at least a
year old now. These 2 are from the 2nd run.

But lastly, because I've made some real progress, I need to make an image
backup of / but without the contents of /media/slash because that is
where I'll put the "backup". How the heck do I do that? And what
command is used to image the sd to the eMMC? Then I'll see if it will
boot from the eMMC, then have make make the debs. Seems like a logical
order anyway...

Thanks Mark.

[Adam Borowski]

Really depends what you mean by an "image backup". I do a lot of stuff using
"ye olde traditional" dd, either between devices or more often making an
image of the entire device (i.e. including partition table etc.) to a file
and manipulate it there (e.g. by deleting a directory tree /after/ the data
has been copied).
However when using something like dd there's a major problem: you either
want the storage medium to be removed so you can copy the filesystems
offline, or you need to shut every possible piece of running software down
(including things like your SSH daemon) so that nothing's writing to the
disc when you're trying to copy it. Needless to say the same considerations
apply when using dd to do a sector-by-sector copy from one device to
another.

man fsfreeze

Some filesystems (at least btrfs) can also enumerate all writes since a
certain point of time, which allows backing up the full filesystem even
without freezing writes, with incremental versions done very cheaply.

There are still ways of working round that sort of problem. For example, you
can copy an entire device using dd to capture boot segments and partition
layout, inspect and recreate the filesystems using mkfs, then use
[something] to copy files one at a time into the new filesystems taking care
that some bootloaders need a wakeup call when a file moves.

Usually dd-ing the partition table and u-bootage, then rsync on filesystem
data works pretty well. Unlike btrfs ways, rsync is not atomic, but most
people consider it good enough.


Meow!

[Gene Heskett]

Post by Gene Heskett
I have not been successfull at "make pdfdocs", it hits something it
doesn't like in the chapter on networking, not finding a file that
is (or was) installed since this is now armbian, and which an
apt-file find pdftex returns 262 versions of it as available. But
which is the correct version? $64k question, that. Lots of stuff
missing for make pdfdocs, not working yet and apt has drug in close
to a gigabyte of stuff. And apt can't find half of what it wants
even then. But it may have succeeded, now installing okteta, and
okular another 150 megs of dependencies that pulls in for each.

That's something I've never tried I'm afraid, and I suspect that most
people use an online one.
However if you really do need to do that I suggest looking at the
manpage for make, since knowing exactly what command was being run
would probably help you a lot.

Post by Gene Heskett
But lastly, because I've made some real progress, I need to make an
image backup of / but without the contents of /media/slash because
that is where I'll put the "backup". How the heck do I do that? And
what command is used to image the sd to the eMMC? Then I'll see if
it will boot from the eMMC, then have make make the debs. Seems
like a logical order anyway...

Really depends what you mean by an "image backup". I do a lot of stuff
using "ye olde traditional" dd, either between devices or more often
making an image of the entire device (i.e. including partition table
etc.) to a file and manipulate it there (e.g. by deleting a directory
tree /after/ the data has been copied).
However when using something like dd there's a major problem: you
either want the storage medium to be removed so you can copy the
filesystems offline, or you need to shut every possible piece of
running software down (including things like your SSH daemon) so that
nothing's writing to the disc when you're trying to copy it. Needless
to say the same considerations apply when using dd to do a
sector-by-sector copy from one device to another.
That would normally be done by putting the system into single user
mode, and traditionally that was done using something like the
telinit 1 command... and it was that that I complained about at the
start of this thread, since I suspect it was responsible for killing
an SDCard in a TinkerBoard.
There are still ways of working round that sort of problem. For
example, you can copy an entire device using dd to capture boot
segments and partition layout, inspect and recreate the filesystems
using mkfs, then use [something] to copy files one at a time into the
new filesystems taking care that some bootloaders need a wakeup call
when a file moves.
dd: Sector-by-sector copy between devices and files.
tar: Good ol' archiver, with directory-exclude etc. options.
netpipes: Do a tar or dd over the LAN.
rsync: File-by-file copy over LAN.
rdist: Ditto, less well-known but with some good points.

I'll have to look at that. I need dd like copies, but I don't
want /media/slash to be anything but an empty dir in the image it makes.

parted: Resize a partition.
resize2fs: Resize a filesystem contained in a partition.
So in combination, a fairly common use case would be to dd an entire
device to a file, resize2fs the final filesystem to its minimum size,
parted to reduce the final partition to its minimum size, dd to put
the file onto a new device (noting that even if the size is nominally
the same, it's common for it to be smaller by a piffling few 100s of
Mb hence the palaver of resizing) and finally expand the final
partition and its included filesystem to fit.
I've done rather a lot of that sort of thing, it's very much "old
school". And like everybody else, on at least one occasion I've got
the dd parameters wrong and roached something I really wanted to keep.

Got the t-shirt and wore it out myself. ;-) Sometimes the recovery has
been a cast iron bitch. I'm almost afraid to putz with the r-pi-3b as
its working better these days. Now if I could just figure out how to fix
the ssh logins. I think I'll go run synaptic and reinstall that ssh kit.

[Gene Heskett]

Post by Gene Heskett

There are still ways of working round that sort of problem. For
example, you can copy an entire device using dd to capture boot
segments and partition layout, inspect and recreate the filesystems
using mkfs, then use [something] to copy files one at a time into
the new filesystems taking care that some bootloaders need a wakeup
call when a file moves.
dd: Sector-by-sector copy between devices and files.
tar: Good ol' archiver, with directory-exclude etc. options.
netpipes: Do a tar or dd over the LAN.
rsync: File-by-file copy over LAN.
rdist: Ditto, less well-known but with some good points.

I'll have to look at that. I need dd like copies, but I don't
want /media/slash to be anything but an empty dir in the image it makes.

dd to a file, then use losetup -f -P to make the partitions in that
file mountable, mount the appropriate one and delete the stuff you
don't want.

Wouldn't the file, if put on /media/slash, it seems dd would
include /media/slash in that file, and the result even if it didn't get
into a recursion forever loop, would still be around 10GB bigger than
media//slash, and it already has some stuff on it:
***@picnc:~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 30387788 10165868 20189152 34% /
devtmpfs 468264 0 468264 0% /dev
tmpfs 472584 0 472584 0% /dev/shm
tmpfs 472584 6548 466036 2% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 472584 0 472584 0% /sys/fs/cgroup
/dev/mmcblk0p1 41322 32253 9070 79% /boot
/dev/sda3 50132520 3064328 44545348 7% /media/slash
/dev/sda1 1079216 4 1079212 1% /media/boot
tmpfs 94520 4 94516 1% /run/user/1000
That totals quite a bit more than the 50GB available on that SSD.

I need dd like to preserve the file addresses in /boot as I've read they
are expected to be at fixed addresses with this boot method.

Maybe it would be best if I used the resize utility to resize the / to
just over whats used. I've made a copy of /home/pi/linuxcnc, so I at
least have the codes I've already written backed up locally.

And I've not been able to find, but haven't looked online, a man page for
rdist. Now have, but bears a re-read, its nothing like a dd.

[Gene Heskett]

Post by Gene Heskett

Post by Gene Heskett

There are still ways of working round that sort of problem. For
example, you can copy an entire device using dd to capture boot
segments and partition layout, inspect and recreate the
filesystems using mkfs, then use [something] to copy files one at
a time into the new filesystems taking care that some bootloaders
need a wakeup call when a file moves.
dd: Sector-by-sector copy between devices and files.
tar: Good ol' archiver, with directory-exclude etc. options.
netpipes: Do a tar or dd over the LAN.
rsync: File-by-file copy over LAN.
rdist: Ditto, less well-known but with some good points.

I'll have to look at that. I need dd like copies, but I don't
want /media/slash to be anything but an empty dir in the image it makes.

dd to a file, then use losetup -f -P to make the partitions in
that file mountable, mount the appropriate one and delete the stuff
you don't want.

Wouldn't the file, if put on /media/slash, it seems dd would
include /media/slash in that file, and the result even if it didn't
get into a recursion forever loop, would still be around 10GB bigger

I was assuming that you weren't trying to dd to something on the same
physical device... which would be highly inadvisable if not impossible
since you need to put what you're copying from into a quiescent state
(i.e. single user or as Adam pointed out fsfreeze.

Not from-to the same device, / is a 32Gb u-sd card its currently booting
from, and /media/slash is /dev/sda3, hooked up by a usb-3<->sata adapter
plugged into a usb-2 port. But the /media mount point is in the u-sd
file structure. Would dd follow that into the files that are there on
the SSD?

There is supposed to be a flag that can make the pi-3b boot from an
attached hard drive, but I have never had the command to flip it, work
always a permissions error or something. Early pi's don't have it?

So either get another temporary device and connect it via USB, or use
dd+netpipes to copy the device onto a different system over the LAN.

or sshfs. I don't currently have it setup so root can use it though, just
me is all.

Post by Gene Heskett
I need dd like to preserve the file addresses in /boot as I've read
they are expected to be at fixed addresses with this boot method.

There's usually something that can't easily be moved, unless there's a
loader in ROM with enough smarts to be able to drive a FAT (etc.)
filesystem.

Which I don't believe the pi-3b has.

Post by Gene Heskett
Maybe it would be best if I used the resize utility to resize the /
to just over whats used. I've made a copy of /home/pi/linuxcnc, so I
at least have the codes I've already written backed up locally.

But you'll still need to unmount / or at the very least go into
single-user mode or freeze it before you can do anything like that.

Post by Gene Heskett
And I've not been able to find, but haven't looked online, a man
page for rdist. Now have, but bears a re-read, its nothing like a
dd.

As I said above, rdist is comparable with rsync.

So I'd best pull that sd card, put it in a reader and dd it to a file,
then dd that file back to a 64 Gb sd just to make a backup copy? I'll
need a few more 64Gb's just to have working room.

Thanks, Mark.

[Gene Heskett]

Post by Gene Heskett

Post by Gene Heskett
Wouldn't the file, if put on /media/slash, it seems dd would
include /media/slash in that file, and the result even if it
didn't get into a recursion forever loop, would still be around
10GB bigger than media//slash, and it already has some stuff on

I was assuming that you weren't trying to dd to something on the
same physical device... which would be highly inadvisable if not
impossible since you need to put what you're copying from into a
quiescent state (i.e. single user or as Adam pointed out fsfreeze.

Not from-to the same device, / is a 32Gb u-sd card its currently
booting from, and /media/slash is /dev/sda3, hooked up by a
usb-3<->sata adapter plugged into a usb-2 port. But the /media mount
point is in the u-sd file structure. Would dd follow that into the
files that are there on the SSD?

No, dd is copying the device not the files it contains, so is
completely oblivious of mounts etc.

Post by Gene Heskett
There is supposed to be a flag that can make the pi-3b boot from an
attached hard drive, but I have never had the command to flip it,
work always a permissions error or something. Early pi's don't have
it?

Recap: RPi3 has a 32Kb ROM (not Flash) containing boot code. Depending
on what it reads from one-time programmable storage, it either boots
from SDCard, or it also tries to look at USB mass-storage devices or
LAN. External boot is disabled by default, and on the original RPi3 is
still a bit flaky... my desktop RPi boots from a Maxstor disc via a
Newlink hub but I've had limited success with other combinations.
The OTP may also be set so that the boot code in ROM reads some GPIO
pins to determine whence to boot, but I've not played with that.
-----8<-----
[Add] program_usb_boot_mode=1 to the end of /boot/config.txt. Reboot
the Raspberry Pi with sudo reboot. Once the client Raspberry Pi has
17:3020000a
Ensure the output 0x3020000a is correct.
The client configuration is almost done. The final thing to do is to
remove the program_usb_boot_mode line from config.txt (make sure there
is no blank line at the end).
----->8-----
Plus plenty of other stuff if you Google.

Post by Gene Heskett

So either get another temporary device and connect it via USB, or
use dd+netpipes to copy the device onto a different system over the
LAN.

or sshfs. I don't currently have it setup so root can use it though,
just me is all.

No. dd DOES NOT copy the content of a filesystem, it copies the entire
filesystem /or/ the entire partition /or/ the entire device.

Post by Gene Heskett

Post by Gene Heskett
I need dd like to preserve the file addresses in /boot as I've
read they are expected to be at fixed addresses with this boot
method.

There's usually something that can't easily be moved, unless
there's a loader in ROM with enough smarts to be able to drive a
FAT (etc.) filesystem.

Which I don't believe the pi-3b has.

It does, see above.

Post by Gene Heskett
So I'd best pull that sd card, put it in a reader and dd it to a
file, then dd that file back to a 64 Gb sd just to make a backup
copy? I'll need a few more 64Gb's just to have working room.

For removable devices... yes, that's the easiest way. However (a) this
might surprise you but keeping an image of an SDCard is an entirely
adequate backup and (b) when you do write one back to a card note my
earlier comments about possibly needing to reduce its size slightly
since you can't rely on all "64Gb" cards having exactly the same
number of sectors.

I've already been smacked around by that, which is why I just bought 3
64GB pny's to copy the 32GB I'm currently running on, to. But I've not
started that step yet. Wally's had the 64's marked down to 18 dollars
and change. Last time I checked, they were about a buck a gigabyte. :(

Like SSD's which also seem to have prices in freefall.

[Gene Heskett]

On Wed, 25 Jul 2018 06:04:01 -0400

Post by Gene Heskett
They acknowledged it, and told me how to fix it, but the fix cost
more than the odroid, a jtag programmer and a special cable that
cost well over $125 is required. And someone else recently advised
me that UEFI bypassing in the bios was only legal on x86 stuffs. If
thats so, I'd

...

Post by Gene Heskett
The only possible mention is at
<https://forum.odroid.com/viewtopic.php?f=138&t=20593>

If we overlook the fact that that thread is about the ODROID C2 and
not the XU4, there's still the problem that it makes no mention of
UEFI.

I just went out and excavated it from a pile of junk on the table saw,
and you are correct, it is a C2. My mistake. When I went to their site,
I didn't think the pix of the XU4 was quite right, and should have dug
it out then. Its a C2, rev 0.2 20160226, so its pretty old now.

But I would certainly clarify with them that the XU4 doesn't have that
restriction and that something like armbian WILL install and run on it,
or if you are stuck with only their "signed" kernels. Their stuff is
still ubuntu based and linuxcnc will not run on the ubuntu kernels since
hardy/2008/10 lts expired. So linuxcnc's install images were then based
on debian, and both wheezy and jessie versions run very well. They now
have a new, stretch based image but I haven't tried it, stretch to me is
not yet "stable" with network setups being a flip the quarter to see if
it works in a static environment. This C2 has an empty eMMC socket on
the bottom. I might have ordered it too, but didn't know what it was for
at the time.

It mentions a binary-only freedom-restricting firmware piece that
ISN'T uefi. Which doesn't mean that there isn't UEFI on it, but that
thread doesn't mention it.

Its a scary acronym. Get the suckers money before he finds out. :(

I would expect that if the XU4 had a UEFI, there would be information
(somewhere) about using EFI-supporting bootloaders on it, like
grub-efi or refind.

refind? Whats it do?

Are you sure that you're using the right term (UEFI) here to describe
your problem?

Yes, it was in the refusal message from the bios when I tried to install
an early jessie on it. So I went into the bios looking for the switch,
but could only find a way to disable the Trusted Computing Chip, and
that bricked it. And it takes the jtag programmer to re-enable it. At
3x the cost of the C2.

If ODROID is selling a ethically-questionable (or user-hostile) piece
of hardware, the case against them is not helped by wrong/misleading
terminology.

Its at least user hostile IMO.

And as a past and potentially future customer of ODROID, I'd like to
have an accurate understanding of this before I make future
purchasing(/boycott) decisions.

So would I have appreciated it too. So get it in an email, and printout 2
or 3 copies for evidence before spending your money.

[g***@manlymail.net]

so we still talking about the xu4

On Wed, 25 Jul 2018 16:57:09 -0400

Post by Gene Heskett
The only possible mention is at
<https://forum.odroid.com/viewtopic.php?f=138&t=20593>

Which links to
https://fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html which
is particularly interesting.

Also, it's my understanding that this problem exists with nearly
all of these pocket-computer/fruit-pi devices to some degree or
other -- to the point that it's a shorter list of the devices that
don't have this problem than a list of the devices that do.
(Anyone know of such a list?)

I think the real question is whether to countenance something that
has a boot loader in Flash which can be (intentionally or otherwise)
overwritten (link here is interesting since it gives a memory layout
http://odroid.com/dokuwiki/doku.php?id=en:c2_partition_table ) or
whether to prefer something in ROM (which is what the RPi has).
The robustness of the ROM approach has a lot going for it, but it
can cause a Hell of a problem if either it contains a
hardware-initialisation bug (which might be the cause of some issues
I'm currently exploring) or if it leaves the hardware in an
operating state which the device's owner considers unacceptable
(e.g. one that requires a signed kernel).
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]

[g***@manlymail.net]

take a look at
https://odroidinc.com/products/odroid-xu4

[g***@manlymail.net]

take a look at
https://odroidinc.com/products/odroid-xu4

[g***@manlymail.net]

take a look at
https://odroidinc.com/products/odroid-xu4

[Alan Corey]

Hmpf, only 2 GB of RAM. I'd like to see 16 or 64. Or put an SODIMM socket
on the board so you could plug in what you want. I generally consider RAM
size more important than CPU speed.

As far as the dead SD, have you tried formatting it in a phone or camera,
then bringing it back to Linux? But really dead so even dd won't write to
it?


Sent from my Motorola XT1527

Post by g***@manlymail.net
take a look at
https://odroidinc.com/products/odroid-xu4