Author Archives: mgreene

New toy – ASRock J3455-ITX

Part because of a mistake and part for fun, I purchased an ASRock J3455-ITX.  I tried to boot a couple different OSs without much luck, I could not get CoreOS to boot or even a Gentoo LiveCD. Granted, it is low power and slow, so it might have been my impatience. Finally, I tried a Gentoo minimal install DVD and it booted, so in the spirit of making something easy much harder this would be yet another Gentoo build.

System make up.

The system make up by the time it was done:

  • ASRock J3455-ITX Intel Quad-Core Processor J3455 (up to 2.3GHz) Mini ITX Motherboard/CPU Combo (Newegg)
  • Silverstone 0.8mm Steel Body Tek Acrylic Front Panel for Mini-ITX Media Center/HTPC Case Cases ML05B (Amazon)
  • SilverStone Technology 300W SFX Form Factor 80 PLUS BRONZE Power Supply with +12V single rail, Active PFC (ST30SF) (Amazon)
  • Timetec Hynix IC 16GB Kit (2x8GB) DDR3L 1866MHz PC3-14900 Unbuffered Non-ECC 1.35V CL13 2Rx8 Dual Rank 204 Pin SODIMM Apple Memory RAM Module Upgrade (16GB Kit (2x8GB)) (Amazon) Returning to Amazon
  • G.SKILL 8GB (2 x 4GB) 204-Pin DDR3 SO-DIMM DDR3 1333 (PC3 10666) Laptop Memory Model F3-10666CL9D-8GBSQ (Newegg)
  • SAMSUNG 850 EVO 2.5″ 250GB SATA III 3D NAND Internal Solid State Drive (SSD) MZ-75E250B/AM (Had this from an old system)

BIOS Version J3455-ITX, BIOS P1.60 01/16/2018 – Out of the box BIOS version.

BIOS Update

Here is the catch, on the ASRock site it lists 1.40 then jumps to 1.70 as a bridge before installing 1.80. I tried the 1.70 from a fat32 USB and the board would not recognize the firmware. So screw it, I just went to 1.80 and it worked. I have to assume the 1.60 is already a bridge to 1.80.

Cooling

Probably will not put a fan in because the passive cooling seems to work well.  There are two fan connections on the board (CPU and chassis) and settings in the board configuration. Compiling webkit, which is a grind, the temps 30+ minutes into compiling webkit:

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +131.0°F (high = +221.0°F, crit = +221.0°F)
Core 0: +131.0°F (high = +221.0°F, crit = +221.0°F)
Core 1: +131.0°F (high = +221.0°F, crit = +221.0°F)
Core 2: +129.2°F (high = +221.0°F, crit = +221.0°F)
Core 3: +129.2°F (high = +221.0°F, crit = +221.0°F)
acpitz-virtual-0
Adapter: Virtual device
temp1: +132.8°F (crit = +212.0°F)

Memory

This is a real BS point. ASRock and a number of other board manufacturers advertise 16 Gig of RAM usable. I read all over the internet this thing can run with 16 Gig. I gave it a try and everything SEEMED to work.

I gave it a shot (see above in System makeup) using 16 Gig (8×2) DDR3L 1866 RAM. Like I already said, it seemed to work, but under heavy loads I got random kernel panics (Kernel 4.18.20), usually SMP NOPTI and sometimes even more spectacular blow ups. I was thinking bad RAM module? Anyway, I pulled a module and ran 8 Gig with the result that I cannot kill it with any load. A quick check of the Intel J3455 Datasheet says only an 8 Gig MAX:

In ASRock’s Memory Support List, only DDR3 Crucial 1600 16GB CT204864BF160B is listed for this configuration. So, in conclusion it might run with 16 Gig, but not always. I do not care, I really only need 8Gig and can return the other RAM to Amazon, saving some money.

EDIT:  I have since read that the board might not be automatically powering the RAM or the RAM is not quite right. A possible fix might be to take the board out if AUTO and increasing the voltage or lowering the speed. I have not tried this …

Hardware Error

This is my real hard spot with this board:

mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: e600000000020408
mce: [Hardware Error]: TSC 0 ADDR fef13b80
mce: [Hardware Error]: PROCESSOR 0:506c9 TIME 1543272637 SOCKET 0 APIC 0 microcode 32

This seems to be common on all the ASRock boards and a lengthy Redhat (here) post gets to the source. The most interesting:

Tony Luck 2017-08-02 13:15:00 EDT
I wrote a trivial EFI program to dump the machine check banks and put it on a USB stick a \EFI\BOOT\BOOTX64.EFI, then booted that USB stick.

The machine check was already logged at this point.

So Linux (and grub boot loader) aren’t involved. Tracking with someone who supports BIOS on this platform now.

So, this is some kind of issue with the BIOS and during boot it picks up on the already existing error. Intel NUC Kits also had this problem, but fixed it in the BIOS. It seems to be a problem that probably will not go away, but does not cause issues.

 

 

New install – GDM not starting “(EE) Cannot open log file “/var/lib/gdm/.local/share/xorg …”

On a new Gentoo install, GDM kept failing to start:

(EE) Cannot open log file "/var/lib/gdm/.local/share/xorg ...log

Found:

The GDM install changed the ownership of /var/lib/gdm/.local/share/applications to gdm.gdm – but it did not change the ownership of the parent directory /var/lib/gdm/.local/share …

Simple solution, chown -R gdm.gdm /var/lib/gdm

 

avahi-daemon chroot failed

Another annoying journal error:

avahi-daemon[301]: chroot.c: open() failed: No such file or directory
avahi-daemon[285]: Failed to open /etc/resolv.conf: Invalid argument

Copy avahi-daemon.service from /lib/systemd/system to /etc/systemd/system. Edit /etc/systemd/system/avahi-daemon.service and add the “After=systemd-resolved.service” line like below and restart. This should result in no error:

avahi-daemon[364]: Successfully called chroot().
avahi-daemon[364]: Successfully dropped remaining capabilities.


# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

[Unit]
Description=Avahi mDNS/DNS-SD Stack
After=systemd-resolved.service
Requires=avahi-daemon.socket

[Service]
Type=dbus
BusName=org.freedesktop.Avahi
ExecStart=/usr/sbin/avahi-daemon -s
ExecReload=/usr/sbin/avahi-daemon -r
NotifyAccess=main

[Install]
WantedBy=multi-user.target
Also=avahi-daemon.socket
Alias=dbus-org.freedesktop.Avahi.service

gjs spamming the journal with stack traces

Another long time annoyance is the endless number of stack traces gjs inserts to the journal. As best as I can figure, based on reading, someone thought this was a good idea to find legacy js scripts or some such stuff. This is and example of the log entries that keep being inserted:

gnome-shell[1981]: Object St.BoxLayout (0x5603b05ffc50), has been already finalized. Impossible to get any property from it.
org.gnome.Shell.desktop[1981]: == Stack trace for context 0x5603ab329170 ==
org.gnome.Shell.desktop[1981]: #0 0x7ffd99df2850 b resource:///org/gnome/shell/ui/tweener.js:73 (0x7f0d5c1ddef0 @ 9)
org.gnome.Shell.desktop[1981]: #1 0x7ffd99df28f0 b resource:///org/gnome/shell/ui/tweener.js:105 (0x7f0d5c1df230 @ 36)
org.gnome.Shell.desktop[1981]: #2 0x7ffd99df2990 b resource:///org/gnome/shell/ui/tweener.js:92 (0x7f0d5c1df098 @ 52)
org.gnome.Shell.desktop[1981]: #3 0x7ffd99df3560 I resource:///org/gnome/gjs/modules/tweener/tweener.js:203 (0x7f0d5c1e9cd0 @ 54)
org.gnome.Shell.desktop[1981]: #4 0x7ffd99df36b0 b resource:///org/gnome/gjs/modules/tweener/tweener.js:332 (0x7f0d5c1e9d58 @ 1626)
org.gnome.Shell.desktop[1981]: #5 0x7ffd99df3760 b resource:///org/gnome/gjs/modules/tweener/tweener.js:345 (0x7f0d5c1e9de0 @ 100)
org.gnome.Shell.desktop[1981]: #6 0x7ffd99df37f0 b resource:///org/gnome/gjs/modules/tweener/tweener.js:360 (0x7f0d5c1e9e68 @ 10)
org.gnome.Shell.desktop[1981]: #7 0x7ffd99df3870 I resource:///org/gnome/gjs/modules/signals.js:126 (0x7f0d5c1e2b38 @ 386)
org.gnome.Shell.desktop[1981]: #8 0x7ffd99df3920 b resource:///org/gnome/shell/ui/tweener.js:208 (0x7f0d5c1df808 @ 159)
org.gnome.Shell.desktop[1981]: #9 0x7ffd99df3980 I resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f0d5c1c2bc0 @ 71)
org.gnome.Shell.desktop[1981]: #10 0x7ffd99df3980 I resource:///org/gnome/shell/ui/tweener.js:183 (0x7f0d5c1df780 @ 20)
org.gnome.Shell.desktop[1981]: #11 0x7ffd99df3a10 I self-hosted:917 (0x7f0d5c1ee5e8 @ 394)
org.gnome.Shell.desktop[1981]: == Stack trace for context 0x5603ab329170 ==
org.gnome.Shell.desktop[1981]: #0 0x7ffd99df2850 b resource:///org/gnome/shell/ui/tweener.js:80 (0x7f0d5c1ddef0 @ 82)
org.gnome.Shell.desktop[1981]: #1 0x7ffd99df28f0 b resource:///org/gnome/shell/ui/tweener.js:105 (0x7f0d5c1df230 @ 36)
org.gnome.Shell.desktop[1981]: #2 0x7ffd99df2990 b resource:///org/gnome/shell/ui/tweener.js:92 (0x7f0d5c1df098 @ 52)
org.gnome.Shell.desktop[1981]: #3 0x7ffd99df3560 I resource:///org/gnome/gjs/modules/tweener/tweener.js:203 (0x7f0d5c1e9cd0 @ 54)
org.gnome.Shell.desktop[1981]: #4 0x7ffd99df36b0 b resource:///org/gnome/gjs/modules/tweener/tweener.js:332 (0x7f0d5c1e9d58 @ 1626)
org.gnome.Shell.desktop[1981]: #5 0x7ffd99df3760 b resource:///org/gnome/gjs/modules/tweener/tweener.js:345 (0x7f0d5c1e9de0 @ 100)
org.gnome.Shell.desktop[1981]: #6 0x7ffd99df37f0 b resource:///org/gnome/gjs/modules/tweener/tweener.js:360 (0x7f0d5c1e9e68 @ 10)
org.gnome.Shell.desktop[1981]: #7 0x7ffd99df3870 I resource:///org/gnome/gjs/modules/signals.js:126 (0x7f0d5c1e2b38 @ 386)

I found a Redhat patch to address this mess: https://bugzilla.redhat.com/attachment.cgi?id=1433199

Personally, I just want a clean log. I just comment out g_critical( … up to and including gjs_dumpstack(); and six in all for the 1.50.4 version.

So:
1. ebuild gjs-1.50.4.ebuild configure
2. Comment out the blocks of code.
3. ebuild gjs-1.50.4.ebuild compile — look for errors
4. ebuild gjs-1.50.4.ebuild install
5. ebuild gjs-1.50.4.ebuild qmerge

I do save the tree under image to a safe spot so I do not have to go through this again. If you need to see the errors just do a regular emerge of gjs. After you are done copy back the lib files to quiet everything down again.

*** As a note, when I do “emerge @changed-deps”, portage wants to replace gjs. I do “emerge -v –exclude gjs @changed-deps” to keep this from happening ***

evolution-calendar login errors

Finally decided to shut this up:


e_cal_recur_generate_instances_sync: assertion 'icaltime_compare (interval_start, interval_end) < 0' failed

I found this patch:
diff -up gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c.xxxx gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c
--- gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c.xxxx 2017-11-02 17:05:55.000000000 +0100
+++ gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c 2018-04-30 14:07:17.611055378 +0200
@@ -590,6 +590,11 @@ app_load_events (App *app)
g_list_free (app->live_views);
app->live_views = NULL;

+ if (!app->since || !app->until)
+ {
+ print_debug ("Skipping load of events, no time interval set yet");
+ return;
+ }
/* timezone could have changed */
app_update_timezone (app);

So:
1. ebuild gnome-shell-3.26.2-r4.ebuild configure
2. Install the patch
3. ebuild gnome-shell-3.26.2-r4.ebuild compile — look for errors
4. ebuild gnome-shell-3.26.2-r4.ebuild install
5. ebuild gnome-shell-3.26.2-r4.ebuild qmerge