Gnome 44 is in the Gentoo repository, not stable yet. The transition was not as painful as my early transition to Gnome 43. The only issue so far has been gnome-clocks, but that is very minor. Most extensions worked, had a like replacement, or after tweaking the metadata.json file version.
Edited 3-27: After update to vala-0.56.4, gnome-clocks-44.0 compiled and installed.
I thought I would never reach a stable Gnome 42 install! The big issue was the mouse movement. Everything was fine under xorg, but mouse movement and overall screen image sucked under Wayland. Anyway, the mouse is sync’d to display resolution and my refresh rate was set to something like 24hz, I do not know how that happened. Either way, all fixed now.
Traditionally, GNOME Shell has been compressing pointer motion events so its handling is synchronized to the monitor refresh rate, this means applications would typically see approximately 60 events per second (or 144 if you follow the trends).
Well, the NUC is done and everything to working. It is definitely not a speed demon, Geekbench scores prove it with a 158 Single-Core Score and 570 Multi-Core Score.
I did try Wayland, and it worked well except for my extensions, so I settled on X11.
I have placed the system configuration on Gitlab including: kernel config, hardware info, files installed, and all that good stuff that should make installation easier. The entire Gentoo install is about 14 Gig and that includes Libreoffice and Firefox binary packages.
This is no fun exercise. I did this over a year ago with my Asrock system, but of course did not record the exact steps, so I had to learn all over again.
The best start is to use the Gentoo Handbook example. I used a combination of fdisk and parted for the drive layout. As a note, I swapped to an EVO850 500G SSD that I had laying around. The following is how my SSD is layed out with a fdisk first, followed by a parted list:
fdisk -l:
Disk /dev/sda: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 850
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B8C5EDC2-AAB2-5142-B4FC-23FA7FCD69E4
Device Start End Sectors Size Type
/dev/sda1 2048 6143 4096 2M BIOS boot
/dev/sda2 6144 518143 512000 250M EFI System
/dev/sda3 518144 21489663 20971520 10G Linux swap
/dev/sda4 21489664 976773134 955283471 455.5G Linux filesystem
parted -l:
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 3146kB 2097kB ext2 grub bios_grub
2 3146kB 265MB 262MB fat32 boot boot, esp
3 265MB 11.0GB 10.7GB linux-swap(v1) swap swap
4 11.0GB 500GB 489GB xfs rootfs
The sda2 partition is the normal boot partition for the kernel, followed by swap, and then sda4 as the root partition. So, what about sda1? Well it is there to provide space for grub to the best of my knowledge, but it is not used. Why use xfs for the rootfs? Because I have never used it before … I will probably downsize to a 250G SSD and switch to ext4 later because I have heard the 5.10 kernels have improvements/changes.
Next, install grub following the handbook. Note, you should be using the handbook as a guide, so at this point the drive is mounted, stage3 is installed, etc … I mount sda4 and sda2 using my script from the previous post and chroot into the image. Finally, execute:
Typical issues with Gentoo are panics on the first start. Sometimes it is the grub configuration. For the above, I have the following in /etc/default/grub:
GRUB_CMDLINE_LINUX="root=/dev/sda4"
Other times, it could be that you are not using an initial ram disk (I do not) which case the filesystem needs to be compiled into the kernel and not as a modules.
The NUC J5005 uses built in Intel UHD Graphics 605 and I have it connected to a ViewSonic VG3448 34 Inch Ultra-Wide 21:9 WQHD. In the kernel config, it is configured as an i915. Short story, the first sign of problems is when the framebuffer is initialized which is followed by the first error:
There are follow on errors and X will not start. I fought this issue for a couple days then took it to work and try with a plain monitor (small Dell or something). Surprise! It worked perfect, so now I know it is a mismatch with my monitor. WTF?
So, I started with the 5.10.9 kernel and found the “Invalid VCO” is coming from intel_dpll_mgr.c.
More poking around pointed to the i915 driver not being able to handle the data by monitor reported, so time to file an issue with the i915 driver group. Thanks to Ville Syrjälä who came back with a patch yesterday:
From 83e72257aca3386decb2b9d631c82e62732afd30 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Tue, 2 Feb 2021 01:16:53 +0200
Subject: [PATCH] drm/i915: Reject 446-480MHz HDMI clock on GLK
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The BXT/GLK DPLL can't generate certain frequencies. We already
reject the 233-240MHz range on both. But on GLK the DPLL max
frequency was bumped from 300MHz to 594MHz, so now we get to
also worry about the 446-480MHz range (double the original
problem range). Reject any frequency within the higher
problematic range as well.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 66e1ac3887c6..b593a71e6517 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2218,7 +2218,11 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
has_hdmi_sink))
return MODE_CLOCK_HIGH;
- /* BXT DPLL can't generate 223-240 MHz */
+ /* GLK DPLL can't generate 446-480 MHz */
+ if (IS_GEMINILAKE(dev_priv) && clock > 446666 && clock < 480000)
+ return MODE_CLOCK_RANGE;
+
+ /* BXT/GLK DPLL can't generate 223-240 MHz */
if (IS_GEN9_LP(dev_priv) && clock > 223333 && clock < 240000)
return MODE_CLOCK_RANGE;
--
2.26.2
I inserted the patch into the 5.10.12 kernel code and was back in business. The down side is I’ll have to remember to keep patching until it makes it into the kernel sources proper.
This project was a real rocky start. I was having a hard time booting off the USB and more trouble with a USB keyboard attached. However, when I could get the unit to boot, the chroot worked and I could compile. I was to the point think the unit was bad, so I stopped the install and started checking the problem by removing external hardware from the board. I was down to the RAM sticks, so I reseated both sticks, but as much compiling I had done on the unit, I would have expected a RAM issue show during heavy compiling.
As a last effort, that should have been an earlier effort, I updated the BIOS/UEFI. The unit had a 10/15/2019, version 1510. I had the same problem with the Asrock board, until I updated the firmware, it did not play nice. Now the unit shows the SATA drive as a possible boot option in the UEFI shell.
No way I am going over the install of Gentoo, but here are a couple references:
However, I can throw up a couple tips from years of installing Gentoo.
My Gentoo Install Tips
Use the Minimal Install CD Not sure if there is a LiveDVD, but use the current minimal because it is updated. Download the iso and burn it to a USB.
Connect the system you are installing to via ethernet cable. After booting with the above USB, do the following:
1. use passwd to give the install system a root password
2. edit /etc/ssh/sshd_config to PasswordAuthentication yes (default is no) and PermitRootLogin yes (default is commented out and prohibit-password). Save the file.
3. run /etc/init.d/ sshd start
4. do ‘ip a’ to get the install machine’s IP address
5. now you should be able to ssh and do the install from your main system.
Once the install USB loads and I can ssh into the system, it is the drive configuration. I do that in next post, but for reference I ‘mkdir /xxx’ on the running install system and mount all my partitions. Then I run the script below which is in the root of all my Gentoo systems. With that done, all that is left is a ‘chroot /xxx /bin/bash’ and then ‘source /etc/profile’
#!/bin/bash
mount --types proc /proc /xxx/proc mount --rbind /sys /xxx/sys mount --make-rslave /xxx/sys mount --rbind /dev /xxx/dev mount --make-rslave /xxx/dev
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I decided to start with an older, but a little higher end than the bottom NUC. At the time Walmart had the better price. On Ebay, a used unit can be had for $40 to $100 cheaper with some already containing RAM and an SSD. There is also a link off the Intel site to request a demo unit. I signed up, but have not heard back and I will try again.