Anybody here know what a rock64 is?

[Gene Heskett]

I just did an update on it, running stretch, 70 files updated, and now
the locale is trashed.

Running xfce for an x11 gui, and the desktop clock/calendar, while using
an EN_US-UTF8 font, is not in english, making orage a bit useless.

Ideas how to fix it when there apparently is not an update.locale file to
be found.

Thanks.

[Punit Agrawal]

Post by Gene Heskett
I just did an update on it, running stretch, 70 files updated, and now
the locale is trashed.
Running xfce for an x11 gui, and the desktop clock/calendar, while using
an EN_US-UTF8 font, is not in english, making orage a bit useless.
Ideas how to fix it when there apparently is not an update.locale file to
be found.

For my locale related trouble, I normally run "sudo dpkg-reconfigure locales".

That's the extent of locale related knowledge. :)

[Alan Corey]

So, you can't just bring up raspi-config? It's just a script anyway.
The locale section:

do_change_locale() {
if [ "$INTERACTIVE" = True ]; then
dpkg-reconfigure locales
else
local LOCALE="$1"
if ! LOCALE_LINE="$(grep "^$LOCALE " /usr/share/i18n/SUPPORTED)"; then
return 1
fi
local ENCODING="$(echo $LOCALE_LINE | cut -f2 -d " ")"
echo "$LOCALE $ENCODING" > /etc/locale.gen
sed -i "s/^\s*LANG=\S*/LANG=$LOCALE/" /etc/default/locale
dpkg-reconfigure -f noninteractive locales
fi
}

locale is a command and a man page on its own but I think it just
reads. On this pi at the moment it says

LANG=en_US
LANGUAGE=
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

dpkg-reconfigure locales is the way to fix it under Debian probably,
files live in /usr/share/i18n/locales

Post by Punit Agrawal

Post by Gene Heskett
I just did an update on it, running stretch, 70 files updated, and now
the locale is trashed.
Running xfce for an x11 gui, and the desktop clock/calendar, while using
an EN_US-UTF8 font, is not in english, making orage a bit useless.
Ideas how to fix it when there apparently is not an update.locale file to
be found.

For my locale related trouble, I normally run "sudo dpkg-reconfigure locales".
That's the extent of locale related knowledge. :)

[Gene Heskett]

Post by Alan Corey
So, you can't just bring up raspi-config? It's just a script anyway.

raspi.config is pi-3b specific. For starters the pi is armhf, the rock64
is arm64, a whole new rig 50x faster than any pi. It would take around 3
days to build the pi's kernel on the pi. It can be done in something
less than an hour on the rock64.

Post by Alan Corey
do_change_locale() {
if [ "$INTERACTIVE" = True ]; then
dpkg-reconfigure locales
else
local LOCALE="$1"
if ! LOCALE_LINE="$(grep "^$LOCALE " /usr/share/i18n/SUPPORTED)";
then return 1
fi
local ENCODING="$(echo $LOCALE_LINE | cut -f2 -d " ")"
echo "$LOCALE $ENCODING" > /etc/locale.gen
sed -i "s/^\s*LANG=\S*/LANG=$LOCALE/" /etc/default/locale
dpkg-reconfigure -f noninteractive locales
fi
}
locale is a command and a man page on its own but I think it just
reads. On this pi at the moment it says
LANG=en_US
LANGUAGE=
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=
dpkg-reconfigure locales is the way to fix it under Debian probably,
files live in /usr/share/i18n/locales

Post by Punit Agrawal

Post by Gene Heskett
I just did an update on it, running stretch, 70 files updated, and
now the locale is trashed.
Running xfce for an x11 gui, and the desktop clock/calendar, while
using an EN_US-UTF8 font, is not in english, making orage a bit
useless.
Ideas how to fix it when there apparently is not an update.locale
file to be found.

For my locale related trouble, I normally run "sudo dpkg-reconfigure locales".
That's the extent of locale related knowledge. :)

[Alan Corey]

Well yes, all of that's true, but would raspberrypi.org mind if Debian
borrowed a copy of their scripts? I'm not a lawyer but I doubt it.
Meanwhile the Pi has a userbase of millions. OpenBSD didn't even have
locale at all last I knew, it's not that essential.

raspi-config isn't 3b specific, it works on my Zero. Speed usually
comes at the expense of power consumption, I'm looking at running
these on 18650 lithium batteries and making a tablet. They're mostly
fast enough, Firefox isn't very efficient. That and Gimp are my 2
worst hogs. But I've run only Pis for 6 months or so. I have one
amd64 laptop running because it's got an oversize battery that keeps
it up through 3-4 hours of power outage, but it's just logging
temperatures. Running Debian though. Locale on that looks the same:
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Post by Gene Heskett

Post by Alan Corey
So, you can't just bring up raspi-config? It's just a script anyway.

raspi.config is pi-3b specific. For starters the pi is armhf, the rock64
is arm64, a whole new rig 50x faster than any pi. It would take around 3
days to build the pi's kernel on the pi. It can be done in something
less than an hour on the rock64.

Post by Alan Corey
do_change_locale() {
if [ "$INTERACTIVE" = True ]; then
dpkg-reconfigure locales
else
local LOCALE="$1"
if ! LOCALE_LINE="$(grep "^$LOCALE " /usr/share/i18n/SUPPORTED)";
then return 1
fi
local ENCODING="$(echo $LOCALE_LINE | cut -f2 -d " ")"
echo "$LOCALE $ENCODING" > /etc/locale.gen
sed -i "s/^\s*LANG=\S*/LANG=$LOCALE/" /etc/default/locale
dpkg-reconfigure -f noninteractive locales
fi
}
locale is a command and a man page on its own but I think it just
reads. On this pi at the moment it says
LANG=en_US
LANGUAGE=
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=
dpkg-reconfigure locales is the way to fix it under Debian probably,
files live in /usr/share/i18n/locales

Post by Punit Agrawal

Post by Gene Heskett
I just did an update on it, running stretch, 70 files updated, and
now the locale is trashed.
Running xfce for an x11 gui, and the desktop clock/calendar, while
using an EN_US-UTF8 font, is not in english, making orage a bit
useless.
Ideas how to fix it when there apparently is not an update.locale
file to be found.

For my locale related trouble, I normally run "sudo dpkg-reconfigure locales".
That's the extent of locale related knowledge. :)

--
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
Well yes, all of that's true, but would raspberrypi.org mind if Debian
borrowed a copy of their scripts? I'm not a lawyer but I doubt it.
Meanwhile the Pi has a userbase of millions. OpenBSD didn't even have
locale at all last I knew, it's not that essential.
raspi-config isn't 3b specific, it works on my Zero. Speed usually
comes at the expense of power consumption,

Power consumption, as long as cooling is adequate, is not a consideratio
when this thing has an 8/4 line cord leading to a dryer socket and 2 hp
worth of motors it controls.

Post by Alan Corey
I'm looking at running
these on 18650 lithium batteries and making a tablet. They're mostly
fast enough, Firefox isn't very efficient. That and Gimp are my 2
worst hogs.

If you want to run gimp on a pi, that 1GB of ram will kill its
performance.

Post by Alan Corey
But I've run only Pis for 6 months or so. I have one
amd64 laptop running because it's got an oversize battery that keeps
it up through 3-4 hours of power outage, but it's just logging
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

As it does on this rock64, but the default shell is not aware of it now.
The charset that mc uses is being substituted until mc is a very strange
looking beast.

Post by Alan Corey

Post by Gene Heskett

Post by Alan Corey
So, you can't just bring up raspi-config? It's just a script

raspi.config is pi-3b specific. For starters the pi is armhf, the
rock64 is arm64, a whole new rig 50x faster than any pi. It would
take around 3 days to build the pi's kernel on the pi. It can be
done in something less than an hour on the rock64.

Post by Alan Corey
do_change_locale() {
if [ "$INTERACTIVE" = True ]; then
dpkg-reconfigure locales
else
local LOCALE="$1"
if ! LOCALE_LINE="$(grep "^$LOCALE "
/usr/share/i18n/SUPPORTED)"; then return 1
fi
local ENCODING="$(echo $LOCALE_LINE | cut -f2 -d " ")"
echo "$LOCALE $ENCODING" > /etc/locale.gen
sed -i "s/^\s*LANG=\S*/LANG=$LOCALE/" /etc/default/locale
dpkg-reconfigure -f noninteractive locales
fi
}
locale is a command and a man page on its own but I think it just
reads. On this pi at the moment it says
LANG=en_US
LANGUAGE=
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

You've got a couple more lines than I do, but its all the same like
yours.

Post by Alan Corey

Post by Gene Heskett

Post by Alan Corey
dpkg-reconfigure locales is the way to fix it under Debian
probably, files live in /usr/share/i18n/locales

On Fri, Apr 20, 2018 at 3:29 AM, Gene Heskett

Post by Gene Heskett
I just did an update on it, running stretch, 70 files updated,
and now the locale is trashed.
Running xfce for an x11 gui, and the desktop clock/calendar,
while using an EN_US-UTF8 font, is not in english, making orage
a bit useless.
Ideas how to fix it when there apparently is not an
update.locale file to be found.

For my locale related trouble, I normally run "sudo
dpkg-reconfigure locales".
That's the extent of locale related knowledge. :)

Mine too, thanks Alan.

[Alan Corey]

I use the alias mc='mc -ad' in my bashrc to turn off the box-drawing
chars that don't work and disable mouse support, which makes the mouse
work for copying and pasting, at least in an rxvt window.

If this is all about lack of locale in update of the rock stuff have
you tried making a tarball of the relevant directories in the update
and just replacing them with an old version? Or a Pi version? But it
may be that your active locale (which could be just a number) got
trashed. Maybe the next update will fix it too.

Some of the config files replaced in updates get saved but renamed, I
don't remember where. Never had to use them.

I use Gimp about daily, most of the time I forget to close Firefox
first. I may have cut down the number of undo buffers in Gimp. By
default there's 2 GB of swap, it's usually using some. I had really
bad luck swapping to my USB (hard) drive, it's like the drive goes to
sleep and the Pi doesn't wake it up so it crashes. I'm experimenting
with high endurance SD cards, OK so far but my experiment only goes
back to March.

Post by Gene Heskett

Post by Alan Corey
Well yes, all of that's true, but would raspberrypi.org mind if Debian
borrowed a copy of their scripts? I'm not a lawyer but I doubt it.
Meanwhile the Pi has a userbase of millions. OpenBSD didn't even have
locale at all last I knew, it's not that essential.
raspi-config isn't 3b specific, it works on my Zero. Speed usually
comes at the expense of power consumption,

Power consumption, as long as cooling is adequate, is not a consideratio
when this thing has an 8/4 line cord leading to a dryer socket and 2 hp
worth of motors it controls.

Post by Alan Corey
I'm looking at running
these on 18650 lithium batteries and making a tablet. They're mostly
fast enough, Firefox isn't very efficient. That and Gimp are my 2
worst hogs.

If you want to run gimp on a pi, that 1GB of ram will kill its
performance.

Post by Alan Corey
But I've run only Pis for 6 months or so. I have one
amd64 laptop running because it's got an oversize battery that keeps
it up through 3-4 hours of power outage, but it's just logging
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

As it does on this rock64, but the default shell is not aware of it now.
The charset that mc uses is being substituted until mc is a very strange
looking beast.

Post by Alan Corey

Post by Gene Heskett

Post by Alan Corey
So, you can't just bring up raspi-config? It's just a script

raspi.config is pi-3b specific. For starters the pi is armhf, the
rock64 is arm64, a whole new rig 50x faster than any pi. It would
take around 3 days to build the pi's kernel on the pi. It can be
done in something less than an hour on the rock64.

Post by Alan Corey
do_change_locale() {
if [ "$INTERACTIVE" = True ]; then
dpkg-reconfigure locales
else
local LOCALE="$1"
if ! LOCALE_LINE="$(grep "^$LOCALE "
/usr/share/i18n/SUPPORTED)"; then return 1
fi
local ENCODING="$(echo $LOCALE_LINE | cut -f2 -d " ")"
echo "$LOCALE $ENCODING" > /etc/locale.gen
sed -i "s/^\s*LANG=\S*/LANG=$LOCALE/" /etc/default/locale
dpkg-reconfigure -f noninteractive locales
fi
}
locale is a command and a man page on its own but I think it just
reads. On this pi at the moment it says
LANG=en_US
LANGUAGE=
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

You've got a couple more lines than I do, but its all the same like
yours.

Post by Alan Corey

Post by Gene Heskett

Post by Alan Corey
dpkg-reconfigure locales is the way to fix it under Debian
probably, files live in /usr/share/i18n/locales

On Fri, Apr 20, 2018 at 3:29 AM, Gene Heskett

Post by Gene Heskett
I just did an update on it, running stretch, 70 files updated,
and now the locale is trashed.
Running xfce for an x11 gui, and the desktop clock/calendar,
while using an EN_US-UTF8 font, is not in english, making orage
a bit useless.
Ideas how to fix it when there apparently is not an
update.locale file to be found.

For my locale related trouble, I normally run "sudo
dpkg-reconfigure locales".
That's the extent of locale related knowledge. :)

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

[peter green]

Post by Alan Corey
Well yes, all of that's true, but would raspberrypi.org mind if Debian
borrowed a copy of their scripts?

It's MIT licensed so it should be fine to borrow

https://github.com/RPi-Distro/raspi-config/LICENSE

Post by Alan Corey
raspi-config isn't 3b specific

Indeed, it's designed for the whole Pi family.

Some parts of it are generic other parts are specific to either the Raspberry Pi hardware/firmware or to the way raspberry pi have set up their image.

The locales part is generic, but all it's doing is calling "dpkg-reconfigure locales" so there isn't much to borrow there.

[Gene Heskett]

Post by Punit Agrawal

Post by Gene Heskett
I just did an update on it, running stretch, 70 files updated, and
now the locale is trashed.
Running xfce for an x11 gui, and the desktop clock/calendar, while
using an EN_US-UTF8 font, is not in english, making orage a bit
useless.
Ideas how to fix it when there apparently is not an update.locale
file to be found.

For my locale related trouble, I normally run "sudo dpkg-reconfigure locales".
That's the extent of locale related knowledge. :)

Mine too, but this is all I can get out of that command, after space bar
selecting, then tabing to ok twice.:

***@rock64:~$ sudo dpkg-reconfigure locales
[sudo] password for rock64:
locales-all installed, skipping locales generation

Regardless of what I select.
Sigh. I wish I had never heard of this rock64 board. And if I could get
my money back, I'd mail them back in a heartbeat. As is, the best I can
is claim that with the level of support I've seen since delivery of
these rock64's over 6 months ago, its a POS, save your money. The latest
upgrade has rendered it useless to do any actual work.

But I'll keep looking, there has to be something out there that doesn't
throwaway 10% of the local keyboard and mouse events like the @$%* pi's
do. Once you get your code into storage, it runs well considering its
speed, but serious editing sessions are much easier to do externally,
then send it back to the pi useing sshfs.

[Stefan Monnier]

Post by Gene Heskett
locales-all installed, skipping locales generation

It says right there: the command didn't do anything because
"locales-all" is installed.

Post by Gene Heskett
Regardless of what I select.
Sigh. I wish I had never heard of this rock64 board.

Nothing in your description indicates any relevance of the hardware on
which this Debian system is running, so I can't see how/why this would
make you feel like the board is to blame.


Stefan

[Gene Heskett]

Post by Stefan Monnier

Post by Gene Heskett
locales-all installed, skipping locales generation

It says right there: the command didn't do anything because
"locales-all" is installed.

Post by Gene Heskett
Regardless of what I select.
Sigh. I wish I had never heard of this rock64 board.

Nothing in your description indicates any relevance of the hardware on
which this Debian system is running, so I can't see how/why this would
make you feel like the board is to blame.

I don't think the board is the problem, its the near total lack of
support from the pine people.
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.

And the usb-3 port has been slowed from true usb-3 speeds to 33k/sec.
Thats not an accident as it has a bug that was discussed on the forum.
But that much of a slowdown makes it useless.

What I need is an arm64 board, like this one, that does not suffer from
the fact that the pi uses a usb-2 internal hub to talk to everything but
the spi, and its internal hub is so busy its own keyboard and mouse only
succeed in getting thru about 90% of the time. This board does not have
that architectural disaster so I thought I could make a dropin
replacement for the poorly designed pi. Wrong. I can't do it myself AND
learn how to change things around in the u-boot environment to achieve
that, The only tools the forum has pointed me at predate the arm64 by 3
years, won't even build on it, and have been unsupported for 5+ years.
So I think I am justified at being unhappy. I've wasted close to $250 on
this and its time to salvage the accessories and start on a different
card. Or go back to an *86 platform and figure out where to hide the
humungus box that implies.

Not debians fault by any means. 100% lack of support from the board
maker.

Thanks Stefan.

Post by Stefan Monnier
Stefan

[Stefan Monnier]

Post by Gene Heskett
What I need is an arm64 board, like this one, that does not suffer from
the fact that the pi uses a usb-2 internal hub to talk to everything but

I don't have any actual experience with it, but the ESPRESSObin board
looks promising in this area.


Stefan

[Chris Moore]

Hi,

Post by Gene Heskett
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

[Gene Heskett]

Post by Chris Moore
Hi,

Post by Gene Heskett
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:/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.

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.

[Chris Moore]

Hi,

Post by Gene Heskett

Post by Chris Moore
Hi,

Post by Gene Heskett
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.
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.
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.)

Cheers,
Chris

[Gene Heskett]

Post by Chris Moore
Hi,

Post by Gene Heskett

Post by Chris Moore
Hi,

Post by Gene Heskett
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.
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.

Post by Chris Moore

Post by Gene Heskett
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...

Post by Chris Moore
Cheers,
Chris

Thanks Chris.

[Alan Corey]

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.

Post by Gene Heskett

Post by Chris Moore
Hi,

Post by Gene Heskett

Post by Chris Moore
Hi,

Post by Gene Heskett
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.
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.

Post by Chris Moore

Post by Gene Heskett
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...

Post by Chris Moore
Cheers,
Chris

Thanks Chris.
--
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
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?

First you need the log to see what it was that was detected when it was
plugged in. Since wheezy changed to /var/log/syslog as opposed to
messages, the log hasn't been near as usefull, too much other noise.
Twould be nice if a tail could be put on dmesg.

Post by Alan Corey
One automount culprit on a Pi anyway is the GUI file manager.

This isn't a pi, its an amd64 phenom around a decade old now. Its what
the card readers are being plugged into to burn images with.

Regarding the usb3 drive thats apparently now trashed, the rock64 is the
only usb3 capable thing on site.

I finally got it to boot after disabling the usb3 HD mount in fstab.

But x isn't running, no screens found according to the log. Then 3 hours
later I tap the spacebar to wake up the monitor again, and find a 2 line
message about re-adjusting it to 1366x768, which is in fact the monitors
native resolution. I've had a black screen with a flashing underline
cursor that wasn't connected to the keyboard or mouse. Getting that far
enables the networking, so I have a couple logins into it.

Running dmesg gets me those same lines as the screen now shows as the
last 2 lines.
8148.676369] rockchip-vop ff370000.vop: [drm:vop_crtc_enable] Update
mode to 1366*768
[ 8148.676421] rockchip-vop ff370000.vop: [drm:vop_isr] *ERROR* BUS_ERROR
irq err

What is this trying to tell me?

So how and where do I create an xorg.conf that gives it that screen?

Thanks Alan.

[Alan Corey]

See man xorg.conf On my old hp laptop (Pavillion dv2700) with Debian
Linux hp 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux
There's a /etc/X11/xorg.conf.d directory, the individual parts go in
there with .conf extensions. You don't need a whole one. It looks in
various places for one, I think it's in a man page somewhere. You
should be able to tell by the log if it's reading it.

There's also the option of doing xorg -configure (only when running as
root) and it will make its best guesses and write them out to an
xorg.conf file, you can use that as a template and edit it into what
you need. I don't remember where it puts it, current directory or
~/$HOME I think. I don't think it puts it where it needs to go to
work.

I don't have any usb3 stuff, does it have to be usb3? If you took
the drive out of the adapter and plugged it into a SATA connector
you'd probably find it's OK, might need an fsck. I don't know about
clearing the buffers, seems like the power switch should work. Maybe
unplug any powered USB hub for a minute too.

I don't know what vop is. The pi has the same GUI file manager as my
hp, pcmanfm or something. But it seems like that would only be a
problem under X and if you were poking around in mc without X that
stuff shouldn't be mounted. Maybe the file manager is only
controlling the automount happening somewhere else.

You can do dmesg | less or into grep for what you're looking for. Or
send it to a text file with >. Or journalctl is the newer way, about
the same stuff I think, but you can enable persistent logging to look
at log entries just before a crash.

Post by Gene Heskett

Post by Alan Corey
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?

First you need the log to see what it was that was detected when it was
plugged in. Since wheezy changed to /var/log/syslog as opposed to
messages, the log hasn't been near as usefull, too much other noise.
Twould be nice if a tail could be put on dmesg.

Post by Alan Corey
One automount culprit on a Pi anyway is the GUI file manager.

This isn't a pi, its an amd64 phenom around a decade old now. Its what
the card readers are being plugged into to burn images with.
Regarding the usb3 drive thats apparently now trashed, the rock64 is the
only usb3 capable thing on site.
I finally got it to boot after disabling the usb3 HD mount in fstab.
But x isn't running, no screens found according to the log. Then 3 hours
later I tap the spacebar to wake up the monitor again, and find a 2 line
message about re-adjusting it to 1366x768, which is in fact the monitors
native resolution. I've had a black screen with a flashing underline
cursor that wasn't connected to the keyboard or mouse. Getting that far
enables the networking, so I have a couple logins into it.
Running dmesg gets me those same lines as the screen now shows as the
last 2 lines.
8148.676369] rockchip-vop ff370000.vop: [drm:vop_crtc_enable] Update
mode to 1366*768
[ 8148.676421] rockchip-vop ff370000.vop: [drm:vop_isr] *ERROR* BUS_ERROR
irq err
What is this trying to tell me?
So how and where do I create an xorg.conf that gives it that screen?
Thanks Alan.
--
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
See man xorg.conf On my old hp laptop (Pavillion dv2700) with Debian
Linux hp 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64
GNU/Linux There's a /etc/X11/xorg.conf.d directory, the individual
parts go in there with .conf extensions. You don't need a whole one.
It looks in various places for one, I think it's in a man page
somewhere. You should be able to tell by the log if it's reading it.

Ack the log, its not.

Post by Alan Corey
There's also the option of doing xorg -configure (only when running as
root) and it will make its best guesses and write them out to an
xorg.conf file, you can use that as a template and edit it into what
you need. I don't remember where it puts it, current directory or
~/$HOME I think. I don't think it puts it where it needs to go to
work.

No shell until x starts. Or I can get it to the empty screen with a
blinken cursor. Once it gets to that screen, I have networking. Theres a
window the boot logs itself to, but no bash or whatever.

Post by Alan Corey
I don't have any usb3 stuff, does it have to be usb3?

There is a difference inside the normal looking connector, 5 contacts.
Regular usb has 4.

Post by Alan Corey
If you took
the drive out of the adapter and plugged it into a SATA connector
you'd probably find it's OK, might need an fsck. I don't know about
clearing the buffers, seems like the power switch should work. Maybe
unplug any powered USB hub for a minute too.
I don't know what vop is. The pi has the same GUI file manager as my
hp, pcmanfm or something. But it seems like that would only be a
problem under X and if you were poking around in mc without X that
stuff shouldn't be mounted. Maybe the file manager is only
controlling the automount happening somewhere else.
You can do dmesg | less or into grep for what you're looking for. Or
send it to a text file with >. Or journalctl is the newer way, about
the same stuff I think, but you can enable persistent logging to look
at log entries just before a crash.

Post by Gene Heskett

Post by Alan Corey
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?

First you need the log to see what it was that was detected when it
was plugged in. Since wheezy changed to /var/log/syslog as opposed
to messages, the log hasn't been near as usefull, too much other
noise. Twould be nice if a tail could be put on dmesg.

Post by Alan Corey
One automount culprit on a Pi anyway is the GUI file manager.

This isn't a pi, its an amd64 phenom around a decade old now. Its
what the card readers are being plugged into to burn images with.
Regarding the usb3 drive thats apparently now trashed, the rock64 is
the only usb3 capable thing on site.
I finally got it to boot after disabling the usb3 HD mount in fstab.
But x isn't running, no screens found according to the log. Then 3
hours later I tap the spacebar to wake up the monitor again, and
find a 2 line message about re-adjusting it to 1366x768, which is in
fact the monitors native resolution. I've had a black screen with a
flashing underline cursor that wasn't connected to the keyboard or
mouse. Getting that far enables the networking, so I have a couple
logins into it.
Running dmesg gets me those same lines as the screen now shows as
the last 2 lines.
8148.676369] rockchip-vop ff370000.vop: [drm:vop_crtc_enable]
Update mode to 1366*768
[ 8148.676421] rockchip-vop ff370000.vop: [drm:vop_isr] *ERROR*
BUS_ERROR irq err
What is this trying to tell me?
So how and where do I create an xorg.conf that gives it that screen?

Thanks Alan.

[Alan Corey]

The
xorg.conf configuration file is searched for in the following places
when the server is started as a normal user:

/etc/X11/<cmdline>
/usr/etc/X11/<cmdline>
/etc/X11/$XORGCONFIG
/usr/etc/X11/$XORGCONFIG
/etc/X11/xorg.conf
/etc/xorg.conf
/usr/etc/X11/xorg.conf.<hostname>
/usr/etc/X11/xorg.conf
/usr/lib/X11/xorg.conf.<hostname>
/usr/lib/X11/xorg.conf
Seems like in OpenBSD it's /usr/lib/x11 , /usr/share/x11 is possible

Maybe X is running without screens? Should show in ps ax | grep X as
Xorg Do you always get a new Xorg.0.log? Maybe X doesn't start
sometimes.

I thought usb2 and 3 were supposed to be somewhat compatible. Yanking
a few plugs, my CD/DVD drive has 4 pins, my sound card has 5, but
they're both plugged into the same D-Link powered hub and they both
work. There's something about Pis not being compatible with usb3
always but using a hub between helps.

Post by Gene Heskett

Post by Alan Corey
See man xorg.conf On my old hp laptop (Pavillion dv2700) with Debian
Linux hp 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64
GNU/Linux There's a /etc/X11/xorg.conf.d directory, the individual
parts go in there with .conf extensions. You don't need a whole one.
It looks in various places for one, I think it's in a man page
somewhere. You should be able to tell by the log if it's reading it.

Ack the log, its not.

Post by Alan Corey
There's also the option of doing xorg -configure (only when running as
root) and it will make its best guesses and write them out to an
xorg.conf file, you can use that as a template and edit it into what
you need. I don't remember where it puts it, current directory or
~/$HOME I think. I don't think it puts it where it needs to go to
work.

No shell until x starts. Or I can get it to the empty screen with a
blinken cursor. Once it gets to that screen, I have networking. Theres a
window the boot logs itself to, but no bash or whatever.

Post by Alan Corey
I don't have any usb3 stuff, does it have to be usb3?

There is a difference inside the normal looking connector, 5 contacts.
Regular usb has 4.

Post by Alan Corey
If you took
the drive out of the adapter and plugged it into a SATA connector
you'd probably find it's OK, might need an fsck. I don't know about
clearing the buffers, seems like the power switch should work. Maybe
unplug any powered USB hub for a minute too.
I don't know what vop is. The pi has the same GUI file manager as my
hp, pcmanfm or something. But it seems like that would only be a
problem under X and if you were poking around in mc without X that
stuff shouldn't be mounted. Maybe the file manager is only
controlling the automount happening somewhere else.
You can do dmesg | less or into grep for what you're looking for. Or
send it to a text file with >. Or journalctl is the newer way, about
the same stuff I think, but you can enable persistent logging to look
at log entries just before a crash.

Post by Gene Heskett

Post by Alan Corey
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?

First you need the log to see what it was that was detected when it
was plugged in. Since wheezy changed to /var/log/syslog as opposed
to messages, the log hasn't been near as usefull, too much other
noise. Twould be nice if a tail could be put on dmesg.

Post by Alan Corey
One automount culprit on a Pi anyway is the GUI file manager.

This isn't a pi, its an amd64 phenom around a decade old now. Its
what the card readers are being plugged into to burn images with.
Regarding the usb3 drive thats apparently now trashed, the rock64 is
the only usb3 capable thing on site.
I finally got it to boot after disabling the usb3 HD mount in fstab.
But x isn't running, no screens found according to the log. Then 3
hours later I tap the spacebar to wake up the monitor again, and
find a 2 line message about re-adjusting it to 1366x768, which is in
fact the monitors native resolution. I've had a black screen with a
flashing underline cursor that wasn't connected to the keyboard or
mouse. Getting that far enables the networking, so I have a couple
logins into it.
Running dmesg gets me those same lines as the screen now shows as
the last 2 lines.
8148.676369] rockchip-vop ff370000.vop: [drm:vop_crtc_enable]
Update mode to 1366*768
[ 8148.676421] rockchip-vop ff370000.vop: [drm:vop_isr] *ERROR*
BUS_ERROR irq err
What is this trying to tell me?
So how and where do I create an xorg.conf that gives it that screen?

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

[Chris Moore]

Hi,

Post by Gene Heskett

Post by Chris Moore
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.

Sorry, I hadn't realised that you were running from a micro-SD card.

I have found that running with the rootfs on a micro-SD card soon
corrupts it and it will no longer boot.
I *suspect* that it is due to the frequent writes and that the driver or
the DT has incorrect write timings or some other bug.
I therefore always run with the rootfs on a USB stick now.

But again this is with Ayufan's Ubuntu Xenial on a Scishion V88 Piano.
However I am pretty sure that Ayufan uses the same kernel and DT for
Xenial and Stretch.
I also guess that the micro-SD slot circuitry is identical to that of
the Rock64.

Cheers,
Chris

[Gene Heskett]

Post by Chris Moore
Hi,

Post by Gene Heskett

Post by Chris Moore
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.

Sorry, I hadn't realised that you were running from a micro-SD card.
I have found that running with the rootfs on a micro-SD card soon
corrupts it and it will no longer boot.

On smallish cards, yes. But my rpi-3b has been running jessie from a 32GB
card for about a year now, w/o a problem. Bigger cards have much more
room for wear leveling. The pi says via df that only 27% is used.

But I see by df, that the root filesystem on the rock64 is only 8GB, but
the card is 32GB, so resize2fs has not been run on it, has been now. But
will no doubt need yet another of its complicated reboots to make it
visible.

And tommorrow I am busy as the first thing I have to do after taking care
of the missus is go get a 2018 sticker for my trash trailers license
plate, about a 75 mile round trip to a dmv office, then hook it up and
take several hundred lbs to the dump. Then if I have any giddyup left,
fire up the weed eater and trim up half an acre thats too steep or small
to get a 38" rider over. Too much stuff in the back yard. Way too much
stuff. . . And its not even square, so there are unusable corners that
still grow weeds. Blocks were laid out with the lay of the land 50 years
ago.

Post by Chris Moore
I *suspect* that it is due to the frequent writes and that the driver
or the DT has incorrect write timings or some other bug.
I therefore always run with the rootfs on a USB stick now.
But again this is with Ayufan's Ubuntu Xenial on a Scishion V88 Piano.
However I am pretty sure that Ayufan uses the same kernel and DT for
Xenial and Stretch.
I also guess that the micro-SD slot circuitry is identical to that of
the Rock64.
Cheers,
Chris

[Alan Corey]

I've had a 32 GB and a 128 GB fail. Piclone is very useful, you can back up
a 128 in half an hour or so, only copies files, not empty space. It uses cp
as its active ingredient.

High Endurance SD cards made for video surveillance may be an improvement,
too soon to know.

Post by Gene Heskett

Post by Chris Moore
Hi,

Post by Gene Heskett

Post by Chris Moore
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.

Sorry, I hadn't realised that you were running from a micro-SD card.
I have found that running with the rootfs on a micro-SD card soon
corrupts it and it will no longer boot.

On smallish cards, yes. But my rpi-3b has been running jessie from a 32GB
card for about a year now, w/o a problem. Bigger cards have much more
room for wear leveling. The pi says via df that only 27% is used.
But I see by df, that the root filesystem on the rock64 is only 8GB, but
the card is 32GB, so resize2fs has not been run on it, has been now. But
will no doubt need yet another of its complicated reboots to make it
visible.
And tommorrow I am busy as the first thing I have to do after taking care
of the missus is go get a 2018 sticker for my trash trailers license
plate, about a 75 mile round trip to a dmv office, then hook it up and
take several hundred lbs to the dump. Then if I have any giddyup left,
fire up the weed eater and trim up half an acre thats too steep or small
to get a 38" rider over. Too much stuff in the back yard. Way too much
stuff. . . And its not even square, so there are unusable corners that
still grow weeds. Blocks were laid out with the lay of the land 50 years
ago.

Post by Chris Moore
I *suspect* that it is due to the frequent writes and that the driver
or the DT has incorrect write timings or some other bug.
I therefore always run with the rootfs on a USB stick now.
But again this is with Ayufan's Ubuntu Xenial on a Scishion V88 Piano.
However I am pretty sure that Ayufan uses the same kernel and DT for
Xenial and Stretch.
I also guess that the micro-SD slot circuitry is identical to that of
the Rock64.
Cheers,
Chris

--
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
I've had a 32 GB and a 128 GB fail. Piclone is very useful, you can
back up a 128 in half an hour or so, only copies files, not empty
space. It uses cp as its active ingredient.

For some reason, I've not been able to make that work and its not in the
jessie/armhf repos that I know of. Src URL for the latest?

Post by Alan Corey
High Endurance SD cards made for video surveillance may be an
improvement, too soon to know.

Thats all I buy, class 10 stuff.

Now, the helper has arrived, and I'm outta here to go get a plate
sticker.

[Alan Corey]

I think this is the original/official one:
https://github.com/raspberrypi-ui/piclone

Somebody's forked it at least once: https://github.com/billw2/rpi-clone

Class 10 is speed. High Endurance is meant to survive many write
cycles. You can void the warranty on some if you use them in a
dashcam. Sandisk Ultra especially. Apparently dashcams record
continuously, overwriting the end and continuously replacing it.

https://techlomedia.in/review/transcend-high-endurance-microsd/
https://www.carcamcentral.com/guide/recommended-sd-cards-avoid-sandisk-ultra-cards

I bought the Sandisk Extreme 64GB about Mar 5 2018, the Transcend 128 GB
3/18/2018. Both came from B&H Photo

Post by Gene Heskett

Post by Alan Corey
I've had a 32 GB and a 128 GB fail. Piclone is very useful, you can
back up a 128 in half an hour or so, only copies files, not empty
space. It uses cp as its active ingredient.

For some reason, I've not been able to make that work and its not in the
jessie/armhf repos that I know of. Src URL for the latest?

Post by Alan Corey
High Endurance SD cards made for video surveillance may be an
improvement, too soon to know.

Thats all I buy, class 10 stuff.
Now, the helper has arrived, and I'm outta here to go get a plate
sticker.
--
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
https://github.com/raspberrypi-ui/piclone
https://github.com/billw2/rpi-clone
Class 10 is speed. High Endurance is meant to survive many write
cycles. You can void the warranty on some if you use them in a
dashcam. Sandisk Ultra especially. Apparently dashcams record
continuously, overwriting the end and continuously replacing it.

Sandisk is the floor sweepings, and should be priced accordingly. They go
in the round container that gets bagged and picked up by the trash
service weekly. I've trashed 2 of them now on the 2nd image write.

SamSung and pny seem to be solid stuffs.

[Alan Corey]

If you say so. I've got about 95% Sandisk AKA Western Digital. If
you do the warranty paperwork they'll replace them. Just be evasive
about what you're using them for, tell them a phone or camera or
something. One of mine had 10 years warranty, the other was lifetime.

Post by Gene Heskett

Post by Alan Corey
https://github.com/raspberrypi-ui/piclone
https://github.com/billw2/rpi-clone
Class 10 is speed. High Endurance is meant to survive many write
cycles. You can void the warranty on some if you use them in a
dashcam. Sandisk Ultra especially. Apparently dashcams record
continuously, overwriting the end and continuously replacing it.

Sandisk is the floor sweepings, and should be priced accordingly. They go
in the round container that gets bagged and picked up by the trash
service weekly. I've trashed 2 of them now on the 2nd image write.
SamSung and pny seem to be solid stuffs.
--
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>