Re: Anybody here know what a rock64 is?
On Sunday 22 April 2018 00:46:42 Chris Moore wrote:
> Hi,
>
> Le 21/04/2018 à 08:04, Gene Heskett a écrit :
> > On Saturday 21 April 2018 00:24:55 Chris Moore wrote:
> >> Hi,
> >>
> >> Le 20/04/2018 à 17:32, Gene Heskett a écrit :
> >>> The new kernel just installed is:
> >>> Linux rock64 4.4.77-rockchip-ayufan-136 #1 SMP Thu Oct 12 09:14:48
> >>> UTC 2017 aarch64 GNU/Linux
> >>>
> >>> Note the build date, almost 6 months ago.
> >>
> >> If you uncomment the last line of
> >> /etc/apt/sources.list.d/ayufan-rock64.list you can get Ayufan's
> >> recent pre-release updates. They work much better for me.
> >> Also Ayufan has promised a new official release after the release
> >> of Ubuntu Bionic Beaver which is due in a few days.
> >>
> >> Cheers,
> >> Chris
> >
> > I used aptitude to upgrade 2 kernel files that pulled in 6 or 7
> > more. I assume its trying to reboot, but did not close the two
> > logins I had into it, so they are locked up until I go out and to a
> > powerdown reset I expect. Its nearly 2 am, and the door that gives
> > me quick access to where it is would wake the missus, so it can sit
> > and stew in its own juices till daytime. For a change, aptitude did
> > not erase 90% of the system according to the action trace it left on
> > the konsole screen here.
> >
> > rock64@rock64:/etc/apt/sources.list.d$ sudo aptitude
> > Performing actions...
> > Selecting previously unselected package libfile-fnmatch-perl.
> > (Reading database ... 141458 files and directories currently
> > installed.) Preparing to unpack
> > .../0-libfile-fnmatch-perl_0.02-2+b3_arm64.deb ... Unpacking
> > libfile-fnmatch-perl (0.02-2+b3) ...
> > Selecting previously unselected package debsums.
> > Preparing to unpack .../1-debsums_2.2.2_all.deb ...
> > Unpacking debsums (2.2.2) ...
> > Selecting previously unselected package
> > linux-headers-4.4.120-rockchip-ayufan-209.
> > Preparing to
> > unpack
> > .../2-linux-headers-4.4.120-rockchip-ayufan-209_0.6.31_arm64.deb ...
> > Unpacking linux-headers-4.4.120-rockchip-ayufan-209 (0.6.31) ...
> > Selecting previously unselected package
> > linux-image-4.4.120-rockchip-ayufan-209.
> > Preparing to
> > unpack
> > .../3-linux-image-4.4.120-rockchip-ayufan-209_0.6.31_arm64.deb ...
> > Unpacking linux-image-4.4.120-rockchip-ayufan-209 (0.6.31) ...
> > Selecting previously unselected package device-tree-compiler.
> > Preparing to unpack .../4-device-tree-compiler_1.4.2-1_arm64.deb ...
> > Unpacking device-tree-compiler (1.4.2-1) ...
> > Preparing to unpack .../5-linux-rock64_0.6.31_arm64.deb ...
> > Unpacking linux-rock64 (0.6.31) over (0.5.15) ...
> > Preparing to unpack .../6-linux-rock64-package_0.6.31_all.deb ...
> > Unpacking linux-rock64-package (0.6.31) over (0.5.15) ...
> > Selecting previously unselected package u-boot-rock64.
> > Preparing to unpack .../7-u-boot-rock64_0.6.31_all.deb ...
> > Unpacking u-boot-rock64 (0.6.31) ...
> > Setting up linux-image-4.4.120-rockchip-ayufan-209 (0.6.31) ...
> > update-initramfs: Generating
> > /boot/initrd.img-4.4.120-rockchip-ayufan-209 Warning: root device
> > does not exist
> > live-boot: core filesystems devices utils udev wget blockdev dns.
> >
> > And the trace ends there. I'll see if I can get it to reboot in the
> > morning.
> >
It did not late yesterday, but I was talking to the next door neighbor,
and did not do a full powerdown restart. The text on screen says eth0 is
up, but its unreachable. It also was unable to mount and talk to a usb3
1T hard drive.
Since the original update replaced the kernel it twigs me that I saw the
old version go by, so I expect it needs a full powerdown to bring in the
newly installed one. The missus is awake, so I'll go check that now.
BRB. No, its stuck in a loop: root account is locked
press enter to continue
And from what I see on the boot screen, the screwing with the usb3 port
has trashed the 1T drive that was plugged in, neither sector 0 nor
sector 1 is readable. And that means I've lost several months work
because I was doing that work in the /media/slash/home/rock64 directory.
> > Now, about the afu locale, the list file in /usr/lib, contains no
> > en_US entries. And the locale shown on its own terminals, the first
> > in some list I've not found yet with grep, shows as aa_DJ? And
> > nothing I do changes it. My logins from this machine show the
> > correct en_US.XXX and work as expected, but its own terminals orage
> > and menu's are afu.
> >
> > Maybe this will fix that...
> >
> > Thanks Chris.
>
> Selecting locales after "sudo dpkg-reconfigure locales" fixed the
> locales problem for me.
>
> However I must admit that I am running the (Debian derived) Ubuntu
> Xenial Xerus not pure Debian.
> Worse it is on a (RK3328 based) Scishion V88 Piano TV box not a real
> Rock64 :(
> However I don't see why things should be worse with Debian Stretch on
> a real Rock64.
>
> I hope I haven't misled you into bricking your Rock64 :(
> (Luckily unbricking should be fairly easy.)
>
Unbricking it is as easy as plugging in another u-sd card. I just tried 5
of them, with unknown images on them, one won't even try to boot, 4 of
them can't get to a x login now. The one that won't even try to boot
probably has an rpi image on it.
But I have 2 universal readers, and 5 32 to 64 GB sd cards.
But in order to write to those cards, I've had to kill any automounter
stuff on this machine, otherwise the automount would grab it before dd
could get started, or would take it away from dd and trash the image
write. Major pain in the ass figureing THAT out.
But that apparently means I can't mount and unmount these cards to find
out whats on them, and the cache has all rpi stuff in it, regardless of
which card reader or card is plugged in, or if nothing is plugged in.
Is there some way I can cause the sd card cache to be flushed, and reread
to refresh the caches data when I plug in a different card? And yet keep
it from grabbing the card and trashing the dd write? On wheezy, this
seems impossible, and the disabling of automounter was several months
back and I can no longer recall what I did to disable it.
So I need a guru.
I've since found usbmount was disabled in /etc/usbmount/usbmount.conf on
this machine, I've re-enabled it and I've now taken the spinningrust
label back out of the rock64's /etc/fstab with a # in front of it. Next
is to see if it will now boot.
And I still need a guru...
> Cheers,
> Chris
Thanks Chris.
--
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>
Reply to: