Re: MacBook2,1 keyboard and touchpad issues on GuixSD

[Ludovic Courtès]

Saluton!

Albin <address@hidden> skribis:

> I've now reconfigured the OS with just `hid-apple` added and can
> confirm that only this module was necessary to get the built-in keyboard
> to work.  However, using an external USB keyboard to type in the
> password doesn't work with this configuration.  Having reconfigured a
> second time with the modules `hid-generic` and `hid-apple` added (but
> not ´hid´) I can now type in the LUKS password with both keyboards.

OK, I’ll add these two and make sure nothing breaks on my non-Apple
laptop.

>>> 4. The media keys that control e.g. LCD brightness and sound level don't
>>> work out of the box.  I haven't found a solution to this yet but maybe
>>> `pommed` (not yet packaged in GuixSD) could take care of this.
>> 
>> OK.  Someone™ should package it, then.
>
> I'm completely new to GuixSD but would be happy to learn how to add
> packages like this one.

If you’re willing to learn, there’s material at:

  https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html

and

  http://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf

And everyone on #guix would be happy to help I guess.  :-)

>> No idea about that one.  Could it be that our Xorg is not loading the
>> right input driver(s)?  Could you compare /var/log/Xorg.0.log with what
>> you get on a “working” distro?
>
> Yes, I think so. I've attached one /var/log/Xorg.0.log file for the
> Parabola MATE live USB where the touchpad is working perfectly and two
> from GuixSD+Xfce where the first one has only basic functionality and
> the second one that "strange" behaviour I explained in my last email.
> (Sometimes when I boot GuixSD I get the first touchpad behaviour and
> sometimes the other.) As can be seen in the Xorg logs, Parabola MATE
> uses the synaptics driver whereas the Guix system uses evdev.

(The GuixSD logs shows this (same on my GuixSD laptop):

--8<---------------cut here---------------start------------->8---
[    21.746] (**) ModulePath set to 
"/gnu/store/mprcc74fj5vzircprywnc6s3an4b2jxd-xf86-video-vesa-2.3.3/lib/xorg/modules/drivers,/gnu/store/q8ff6i8dvcxrsrqmm8sfbna946hkhfdz-xf86-video-fbdev-0.4.4/lib/xorg/modules/drivers,/gnu/store/fjpacfpkm8pwm25phf8z8cdib8xz7w55-xf86-video-modesetting-0.9.0/lib/xorg/modules/drivers,/gnu/store/vkpm70m5c5w2c533v1saasgz3wxp6xb9-xf86-video-cirrus-1.5.2/lib/xorg/modules/drivers,/gnu/store/7wh7w20x065g8pak0nb9hfqv9m3l7cwl-xf86-video-intel-2.21.15/lib/xorg/modules/drivers,/gnu/store/agcf29wg9z6xr0wcnqizwxhdj565fqh1-xf86-video-mach64-6.9.4/lib/xorg/modules/drivers,/gnu/store/nyihy6as2rmzf2mwikr77ma6r2nk2by9-xf86-video-nouveau-1.0.11/lib/xorg/modules/drivers,/gnu/store/d5r9dp2n22i9gnl0217ckqdhq1hv0210-xf86-video-nv-2.1.20/lib/xorg/modules/drivers,/gnu/store/w25s3lhxyifczfbfczlmk68v9sa4x1jv-xf86-video-sis-0.10.7/lib/xorg/modules/drivers,/gnu/store/wv9ss3lc1wl4pii3p6rmnlb3ag9skn5s-xf86-input-libinput-0.8.0/lib/xorg/modules/input,/gnu/store/r2lpnq5jq0nnq6lgi5rh9f7m6ddp44iq-xf86-input-evdev-2.8.4/l
--8<---------------cut here---------------end--------------->8---

The line is truncated, and the Synaptics driver doesn’t show up because
of that.  AFAICS, this is a false alarm and comes from the fact that
‘LogVMessageVerb’ in xorg-server uses a 1024-byte buffer;
‘xf86parseFilesSection’ does seem to make the module search path as long
as needed.)

So, I don’t know!  The list of drivers we use for Xorg is currently
hard-coded (bah!) in gnu/services/xorg.scm.  You could try playing with
them, such as moving Synpatics before evdev and ‘reconfigure’ from
there?

> No, it's fully encrypted including /boot.
>
>> Does the grub.cfg generated by ‘guix system’ work for you?
>
> Yes, I can access it from the Libreboot GRUB command line by entering
> `configfile (crypto0)/boot/grub.cfg (after having unlocked
> the device (see below).
>
>> Did you have
>> to run the ‘insmod’ and ‘cryptomount’ commands in GRUB as reported at
>> <http://bugs.gnu.org/21843>?
>
> I run `cryptomount -a` from GRUB in libreboot and type in the LUKS
> password there. Then I need to type it in a second time during the
> initial boot process. For Trisquel and Parabola there are instructions
> how to include the LUKS password as a key file inside the initial RAM
> disk. (See "Using a key file to unlock /boot/" on
> https://libreboot.org/docs/gnulinux/encrypted_parabola.html)
> I'd like to do this in GuixSD but don't know how.
>
> There is ongoing work, initiated by Petter, on a guide for installing
> GuixSD with full-disk encryption including /boot. Hopefully we can have
> this ready very soon. How to include the password in the initial RAM
> disk is one thing I'd like to have in there. More important though is
> finding a solution to this error:
>
>> making '/gnu/store/bla bla bla-system' the current system...
>> Path `/boot/grub/` is not readable by GRUB on boot. Installation is
>> impossible. Aborting
>> guix system: error: failed to install GRUB on device '/dev/sda'

The “not readable by GRUB” comes from ‘grub-install’, which uses
‘grub-probe’ to determine the device on which a given directory lies.

On my laptop where /home is LUKS-encrypted, I get:

--8<---------------cut here---------------start------------->8---
$ sudo grub-probe -v /home
grub-probe: info: Cannot stat 
`/dev/disk/by-id/ata-SAMSUNG_SSD_PM810_2.5__7mm_128GB_S0NRNEAB613713', skipping.
grub-probe: info: Cannot stat 
`/dev/disk/by-id/usb-2.0_Flash_Disk_31172800A387B500-0:0', skipping.
grub-probe: info: changing current directory to /dev/mapper.
grub-probe: info: opening lvm/home.
grub-probe: error: disk `lvm/home' not found.
$ sudo grub-probe -v -d /dev/mapper/home 
grub-probe: info: Cannot stat 
`/dev/disk/by-id/ata-SAMSUNG_SSD_PM810_2.5__7mm_128GB_S0NRNEAB613713', skipping.
grub-probe: info: Cannot stat 
`/dev/disk/by-id/usb-2.0_Flash_Disk_31172800A387B500-0:0', skipping.
grub-probe: info: opening lvm/home.
grub-probe: error: disk `lvm/home' not found.
--8<---------------cut here---------------end--------------->8---

So the thing seems to wrongfully assume that the device is
/dev/mapper/lvm/home, when it really is in /dev/mapper/home.

Hmm we should try with GRUB 2.02beta2 to begin with…

> The message above is printed at the end of every installation or
> reconfiguration process. The installation doesn't really fail but it
> isn't complete. Running the garbage collector can mess up the system for
> example.
>
> As mark_weaver explained:
>
>> [I]n order to avoid garbage-collecting the resources needed by
>> grub.cfg, there needed to be a GC "root" installed in
>> /var/guix/gcroots and that's the last step of "guix system init"
>> and "guix system reconfigure", done after grub is installed,
>> but because the grub install failed that last step was never done
> ...so the GC root was not installed to protect the grub.cfg resources.

Indeed, I see.

Anyway, thank you for your feedback!  From there, I think it’s best to
file individual bug reports to address@hidden, or to complement
existing ones by email address@hidden where NNN is the bug report
number.  See <http://bugs.gnu.org/guix> for the list of open bugs.

Thanks,
Ludo’.