bug#59467: Successful UEFI Manual installation on Guix 1.3.0
Glossary: BIOS: Basic Input Output System GPU: Graphics Processor Unit GPT: GUID Partition Table EFI: Extensible Firmware Interface CSM: Compatibility Support Module Equipment: Toshiba Satellite C40D-A GPU: Radeon HD 8330 bug #0: Graphical Installer Description: Unexpected problem Logs: Workaround Solution: Overview: The follow recipe is for user's Guix and GNU/Linux beginners that wants to start with advance science GNU/Linux 100% Free Software distribution. Step 1: Enter to BIOS Step 1.1 setup defaults Step 1.2 setup UEFI Step 1.2.1: Remove signature UEFI that lock GNU/Linux 100% Free Software distributions Step 2: Run Guix Installer 1.3.0 Step 3: Select Manual Installation Step 4: Review the instructions carefully on the manual installation guide. Step 5: Use GPT on your HDD Step 6: Create three partitions with parted Step 6.1 I suggest EFI partition 1 size 300 GB Step 6.2 I suggest system partition 2 size 90 GB Step 6.3 I suggest Swap partition 3 size 10 GB Step 7: Make file system partition formats Step 7.1: EFI partition mkfs.fat -F32 /dev/sda1 Step 7.2: system partition mkfs.ext4 /dev/sda2 Step 7.3: Swap partition mkswap /dev/sda3 Step 8: I suggest to use bare-bone.scm to configure your install system. Step 9: Install the system. Step 10: GRUB edit the command linux before booting adding modprob.blacklist=Radeon Step 10: Review your Guix system was install successfully Notes: The Guix installer 1.3.0 had a better graphical performance than BIOS setup CSM. Bug root cause: Graphical Installer Process Feel free to reach me out engineer.octavio member.fsf.org Solution: Ing. Octavio Toscano Familia Amor Salud Dinero Libertad
bug#59635: SDDM lacks a Guix theme
We have guix-simplyblack-sddm-theme packaged, we can make sddm use this theme by default.
bug#59598: "Unsupported manifest format" error
Hi zimoun, On +2022-11-27 13:22:22 +0100, zimoun wrote: [...] > > This file lives in the store. Hum, I am surprised that a power shutdown > removed this file. > Are all the conditions for a clean sync of the file system where /gnu/store is mounted guaranteed? What is the difference between power shutdown when you let the battery run down and the OS shuts everything down vs if you log out and click power down? Is it not possible that when you have recharged the battery and boot up that a journaling file system will discover traces of an incomplete transaction (i.e. the one that was supposed to record and atomically commit the missing file) and discards it to reestabllish coherent file system state? And what about continuations that were possibly waiting for availability of that file? Hopefully the OS will recover a good state, but what can userland innocents expect to be guaranteed, in terms of work flow they can understand? (those with the grok-fu to understand internals won't need much to imagine failure scenarios, but will presumably appreciate /design/rationale/implementation/ documentation tips) > Well, I do not know if you can recover this empty file. At least, you > can the previous generation; e.g., guix package --roll-back. > Assuming the file system recovered -- a pretty good bet, but ... :) > Or you can extract a previous manifest with, > > guix package -p > /var/guix/profiles/per-user//guix-profile--link \ >--export-manifest > /tmp/manifest-.scm > > where and depends on. Then, > > guix package -m /tmp/manifest-scm > > will reinstall the same list of packages but at their current version > (the ones of current Guix revision; guix describe). > > > Cheers, > simon > -- Regards, Bengt Richter
bug#59616: Texinfo 6.7 test hangs on i586-gnu (GNU/Hurd)
Hi, Ludovic Courtès skribis: > The childhurd only has this: > > ludo@childhurd /tmp/guix-build-texinfo-6.7.drv-0/texinfo-6.7/info$ ls -l > /dev/ptyp* > crw--w 1 root tty 0, 0 Nov 26 16:05 /dev/ptyp0 > crw--w 1 ludo tty 0, 0 Nov 26 16:05 /dev/ptyp1 > crw--- 1 root root 0, 0 Nov 26 16:05 /dev/ptyp2 Part of the solution is to create more of them in hurd-boot.scm. But there’s a second problem: we need to build glibc’s ‘pt_chown’ setuid program (with ‘--enable-pt_chown’) so that ‘grantpt’ can change the owner of /dev/ttyp*. At least that’s how it’s done on Debian GNU/Hurd, but I’m surprised /hurd/term (for pty-slave) doesn’t just return the right UID on ‘io_stat’. Ludo’.
bug#59515: nginx: Fails to start on boot while upstream service is not yet running
Jonathan Brielmaier skribis: > I added `(shepherd-requirement '(radicale))` to my nginx-configuration. > Sadly the issue is not fixed, the situation is the same as before. > > I assume that radicale takes a fracture of a second to start. And nginx > starts faster up. See this small experiment: That looks like a bug in the radicale service: there’s no synchronization upon startup: --8<---cut here---start->8--- (list (shepherd-service (provision '(radicale)) (documentation "Run the radicale daemon.") (requirement '(networking)) (start #~(make-forkexec-constructor (list #$(file-append package "/bin/radicale") "-C" #$config-file) #:user "radicale" #:group "radicale")) (stop #~(make-kill-destructor --8<---cut here---end--->8--- It should wait for a PID file or be started as a systemd or inetd service. That way, we’d be sure that shepherd considers it started once it’s really listening for input. A quick grep in the source suggests it creates a PID file somewhere. HTH! Ludo’.
bug#59463: [doc] More foolproof command in https://guix.gnu.org/cookbook/en/html_node/Reproducible-profiles.html
Thanks for reporting in time for the 1.4.0 release of the cookbook. :) Fixed in 39f88ee29faa98d0b9b9761f2db8dc7721200fe5. Regards, Florian
bug#59361: linux-libre 6 breaks OpenGL on nouveau driver
Hi,
Maxim Cournoyer writes:
> Hello,
>
> Maxim Cournoyer writes:
>
>> Hi,
>>
>> When booting my Guix System with linux-libre 6.0.8, nouveau silently
>> fails to render OpenGL. It includes symptoms such as:
>>
>> 1. Getting stuck on the GDM screen, which makes use of OpenGL
>> 2. Not being able to use Qt5 or Qt6 applications, which renders via
>> OpenGL.
>> 3. the 'glxgears' program from mesa-utils displays frozen gears (not
>> turning)
>>
>> My graphic card is an old nvidia 8800 GTS with 640 MiB of video RAM.
>>
>> Workaround: Adding the '(kernel linux-libre-5.15)' to my OS definition
>> fixes it.
>
> Now reported upstream at
> https://gitlab.freedesktop.org/drm/nouveau/-/issues/192.
The commit that regressed was found via git bisect, by using the
following in my system configuration:
--8<---cut here---start->8---
modified guix/hurd.scm
@@ -1,6 +1,7 @@
(use-modules (gnu)
+ (guix git)
(guix modules)
(guix store)
(srfi srfi-1)
@@ -98,6 +99,21 @@
+(define make-linux-libre* (@@ (gnu packages linux) make-linux-libre*))
+
+(define (linux-source commit)
+ (git-checkout
+ (url "file:///home/maxim/src/linux")
+ (commit commit)))
+
+(define %linux-commit "889fcbe949bdd8470931a90b91f273ca18c510c1")
+
+(define-public %linux-kernel
+ (make-linux-libre* "5.19" "0" (linux-source %linux-commit) '("x86_64-linux")
+ #:configuration-file (@@ (gnu packages linux)
kernel-config)
+ #:extra-version "stock"
+ #:build-doc? #f))
+
(define %mapped-devices
(list (mapped-device
--8<---cut here---end--->8---
And changing the value of %linux-commit for each git bisect. The
original git-checkout clone took forever (multiple hours), but after the
initial clone done, each kernel build took about 20 minutes on a fast
machine.
The offending Linux commit is 889fcbe949bdd8470931a90b91f273ca18c510c1 [0]
[0]
https://gitlab.freedesktop.org/drm/nouveau/-/commit/889fcbe949bdd8470931a90b91f273ca18c510c1
--
Thanks,
Maxim
bug#59635: SDDM lacks a Guix theme
Hello, By default, SDDM ships a default theme which uses a picture from the Maldives as its background; this is in contrast to most other display managers packaged in Guix (at least GDM, lightdm, slim) for which we set the background to an image from the Guix-artwork project. We should package our own SDDM theme to have offer a more integrated look out of the box! -- Thanks, Maxim
bug#59632: SDDM display manager keyboard selection doesn't work
Hi, When using SDDM, there's a dropdown menu to choose the keyboard layout; it displays the wrong keyboard in my case (showing "us" while my configured layout is dvorak), although dvorak is in effect. It also won't allow me to change the layout (there's no other choices than "us"). -- Thanks, Maxim
bug#59598: "Unsupported manifest format" error
Hi, On Fri, 25 Nov 2022 at 22:06, Tyler Wolf via Bug reports for GNU Guix wrote: > I then can see that my ~/.guix-profile/manifest is empty, thus I think > it is safe to say that this is where the issue is originating, however > I am unable to rewrite this file, so I was wondering if there was any > fix to this? This file lives in the store. Hum, I am surprised that a power shutdown removed this file. Well, I do not know if you can recover this empty file. At least, you can the previous generation; e.g., guix package --roll-back. Or you can extract a previous manifest with, guix package -p /var/guix/profiles/per-user//guix-profile--link \ --export-manifest > /tmp/manifest-.scm where and depends on. Then, guix package -m /tmp/manifest-scm will reinstall the same list of packages but at their current version (the ones of current Guix revision; guix describe). Cheers, simon
