I get many Error messages in the Voidlinux bootscreen, which slows down boot by many seconds. Sometimes it’s faster and sometimes slower or I have to reboot, because of it taking so long.
When starting xorg with startx or xinit: Doing something like opening a terminal at start and writing something and trying to close it, results in not getting video output.
Once you wait a while the problem does not seem to appear anymore in the current X-session. The same Problems occur with the aarch64-glibc version.
There are 3 types of boot scenarios. The one in the picture is the one where I have to shut the computer down, because of it taking too long. Another one needs a lot of time when “Scanning for Btrfs filesystem”. And the third one boots to emergency shell, where I have to exit the shell to get to be able to get further to the login.
Note that it says something about /dev/sda, there is an NTFS partition on that drive.
The date of Voidlinux is set to 01/01/2000 4 hours later. I also found this somewhere in the UEFI. How can the Systemtime of the UEFI be changed so that distributions take that time?
I have not tested Void Linux at all, but it appears that kernel is using an older version of the ACPI enablement patchset for the LX2160a.
The SATA errors could come from a number of things, however the main problem is most likely a bad cable. Generally you will find the best results with a high quality SATA III 6Gbps rated cable that is 40-50cm in length.
The date can be set from Linux userspace with the various hwclock commands, or set in UEFI by booting to UEFI shell and using the date and time commands.
1 Like
Thank you, Jon, I tried setting the date with date -s command, which set itself back on the 01/01/2000 date after reboot. I will try hwclock in Void. i tried date -s in the UEFI shell, the shell says that the option “-s” is unknown.
you can see the usage of the date and time commands for uefi shell by typing help date They are different than the Linux implementation.
1 Like
Awesome I set the right date, how can I set the time zone? (CEST/UTC)
edk2 does not manage timezone’s or daylight savings changes. It simple manages the hwclock date/time. It is a function of the Host OS to setup the appropriate timezone.
1 Like
Good to know I booted Voidlinux, which set the new, correct system time right away.
1 Like
That didn’t fix the issue with voidlinux booting times and Xorg. But thanks anyways, this may be helpful in the future. I’m guessing the issue I am having is very rare and can’t be fixed.
You are definitely getting an error reading a SATA device on boot. That is most likely what is causing the delays in booting.
1 Like
Right, I unplugged the /dev/sda drive now and the problem does not occur anymore. The system boots fast and reliably.
I made another interesting discover in the X-session: when pressing and holding Alt and the left or right mouse button, the Time freezes and resumes at the right time.
What is also odd is that Void linux sets the hardware clock by itself, resulting in an error in the UEFI Shell:“UEFI function ‘gRT->GetTime’ returned: No Response”,
the error appears when typing “date”.
Trying to set the time results in:"Invalid argument - ‘HH/MM/SS’.
I reproduced the error with these steps:
- boot to Void linux
- reboot to alpine linux
- reboot to Void linux
Additional Information on the Probem with X-session.
I enabled the options that you recommended me in the /etc/modprobe.d. And the problem with the GPU locks persists.
My assumption with the X-session problem is that gpu locks cannot be seen in an X-session.
What also points to my assumption, is that when I don’t start X right away the X-session holds its video output, but when I do something in the TTY and then start X it is possible that I don’t get any video output very fast when in the X-session.
The graphics card is also more at work in the x-session of course, than in the TTY, which can make the GPU lock more likely to appear.
I would recommend you check the mesa bug trackers for similar bugs. Many of these bugs besides the ones I specifically have found with amdgpu on the HoneyComb platform are generic issues based on the version of the software and driver. Additionally some of them can also be due to patches added to a specific distribution.
1 Like
I am also getting non-fatal errors when opening and closing the X-session: xkbcomp reports unsupported highkeycode 256, keysym XF86BrightnessAuto, keysym XF86DisplayOff and keysym XF86KbdLcdMenu erros, which i think have nothing to do with my problem.
Hello back, Jon, I am happy to tell you, that I have fixed the issue with the X-session crashing/making no video output.
Fix: edit the /etc/default/grub type “amdgpu.pcie_gen_cap=0x4” in the GRUB_CMDLINE_LINUX_DEFAULT="" section. In my case there is a “loglevel=4” option in the quotes, you have to press space after the option and add the new option and so on with other options that you want to add. Save the file and execute “update-grub”.
I have also fixed the issue of Voidlinux setting the system and hardware clock by itself, with the command “hwclock --systohc”, UPDATE: but this only works if you don’t leave the computer powered of for a longer period of time, sadly. Before executing this command you have to set the wanted time.
What causes this issue is:
- booting into Void Linux (you see the false time)
- booting into the UEFI Shell to set the right time
- shutting the computer off
- booting to Alpine linux
- rebooting to VoidLinux
Workaround: xbps-install ntp
add “ntpd -qg; hwclock -wl” to .xinitrc
starting X with this option is about 5 seconds slower and the time is UTC. In my case the date is right, but time is 2 hours earlier.
slow, unreliable booting: unplug the drive that represents /dev/sda on the Operating System.
1 Like
I tried very hard to get void linux working, because of glx support, I now have window opacity and window blurring which is aesthetic, gorgeous and easier on the eyes (no harsh, high contrast white on black). I guess I am pretty ambitious when it comes to something like that:
I worked since monday 06/21/2021 on this setup for 9 hours everyday over the course of 8 days. I put my sweat and dedication in this setup and learned something new 
Games I tested:
Teeworlds: outstanding performance
Minetest: very good performance (50 FPS average, at max graphics settings)
OpenArena: Good performance (max graphics settings with minimum resolution)
Xonotic: poor performance (radeonsi driver missing)
Is there some kind of plastic clip, that has to be removed from the clock-battery on the board?
There is not. The battery should be working when you receive the unit.
1 Like
That’s good to hear, Sound does now work aswell through a USB headset. The PWM control works really good.
UPDATE: The red cables I am using for 2 HDDs and one SSD (/dev/sda, the one that was causing these errors) turn out to be 15 years old. I got myself a newer, yellow cable. I plugged it in, and all of the errors caused by the /dev/sda drive are gone at boot. Thank you very much, Jon. I would have never figured this out. You are really Intelligent in my opinion and have great expertise!
