Re: Anybody here know what a rock64 is?
Can't you mount something to multiple mount points? In other words
just ignore the automount and mount it where you want it in parallel?
One automount culprit on a Pi anyway is the GUI file manager. In
Preferences -> Volume Management there are 3 checkboxes related to
automount. Another could be if you have auto entries in your
/etc/fstab. I killed all I could find months ago, don't remember
where they were.
Or grep the output of mount or lsof for the mount points.
I usually look at the output of dmesg when I plug an SD in to see what
partitions it has and how to mount (what they're called). Or sfdisk
-l if that fails. gparted is handy to have around too.
On 4/22/18, Gene Heskett <gheskett@shentel.net> wrote:
> 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>
>
>
--
-------------
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: