Re: Cautionary tale: how to kill an SDCard with one simple command
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.
On 7/21/18, Gene Heskett <gheskett@shentel.net> wrote:
> On Saturday 21 July 2018 10:20:02 Mark Morgan Lloyd wrote:
>
>> On 21/07/18 14:00, Gene Heskett wrote:
>> > On Saturday 21 July 2018 07:46:38 Mark Morgan Lloyd wrote:
>> >> 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 user@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.
>>
>> 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
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Reply to: