From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: MacBook2,1 keyboard and touchpad issues on GuixSD Date: Thu, 28 Jan 2016 15:33:49 +0100 Message-ID: <87egd1bwoi.fsf@gnu.org> References: <56A5714B.80804@fripost.org> <87bn88s9lc.fsf@gnu.org> <56A7CE99.6030507@fripost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOne3-0003tk-Ak for help-guix@gnu.org; Thu, 28 Jan 2016 09:34:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOne0-0003qR-1C for help-guix@gnu.org; Thu, 28 Jan 2016 09:33:59 -0500 In-Reply-To: <56A7CE99.6030507@fripost.org> (albin@fripost.org's message of "Tue, 26 Jan 2016 20:52:57 +0100") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org To: Albin Cc: help-guix@gnu.org Saluton! Albin 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 =C2=B4hid=C2=B4) I can now type in the LUKS password with both keyboa= rds. OK, I=E2=80=99ll 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. >>=20 >> OK. Someone=E2=84=A2 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=E2=80=99re willing to learn, there=E2=80=99s 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 =E2=80=9Cworking=E2=80=9D 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/mprcc74fj5vzircprywnc6s3an4= b2jxd-xf86-video-vesa-2.3.3/lib/xorg/modules/drivers,/gnu/store/q8ff6i8dvcx= rsrqmm8sfbna946hkhfdz-xf86-video-fbdev-0.4.4/lib/xorg/modules/drivers,/gnu/= store/fjpacfpkm8pwm25phf8z8cdib8xz7w55-xf86-video-modesetting-0.9.0/lib/xor= g/modules/drivers,/gnu/store/vkpm70m5c5w2c533v1saasgz3wxp6xb9-xf86-video-ci= rrus-1.5.2/lib/xorg/modules/drivers,/gnu/store/7wh7w20x065g8pak0nb9hfqv9m3l= 7cwl-xf86-video-intel-2.21.15/lib/xorg/modules/drivers,/gnu/store/agcf29wg9= z6xr0wcnqizwxhdj565fqh1-xf86-video-mach64-6.9.4/lib/xorg/modules/drivers,/g= nu/store/nyihy6as2rmzf2mwikr77ma6r2nk2by9-xf86-video-nouveau-1.0.11/lib/xor= g/modules/drivers,/gnu/store/d5r9dp2n22i9gnl0217ckqdhq1hv0210-xf86-video-nv= -2.1.20/lib/xorg/modules/drivers,/gnu/store/w25s3lhxyifczfbfczlmk68v9sa4x1j= v-xf86-video-sis-0.10.7/lib/xorg/modules/drivers,/gnu/store/wv9ss3lc1wl4pii= 3p6rmnlb3ag9skn5s-xf86-input-libinput-0.8.0/lib/xorg/modules/input,/gnu/sto= re/r2lpnq5jq0nnq6lgi5rh9f7m6ddp44iq-xf86-input-evdev-2.8.4/l --8<---------------cut here---------------end--------------->8--- The line is truncated, and the Synaptics driver doesn=E2=80=99t show up bec= ause of that. AFAICS, this is a false alarm and comes from the fact that =E2=80=98LogVMessageVerb=E2=80=99 in xorg-server uses a 1024-byte buffer; =E2=80=98xf86parseFilesSection=E2=80=99 does seem to make the module search= path as long as needed.) So, I don=E2=80=99t 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 =E2=80=98reconfigure=E2=80= =99 from there? > No, it's fully encrypted including /boot. > >> Does the grub.cfg generated by =E2=80=98guix system=E2=80=99 work for yo= u? > > 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 =E2=80=98insmod=E2=80=99 and =E2=80=98cryptomount=E2=80=99 co= mmands in GRUB as reported at >> ? > > 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 =E2=80=9Cnot readable by GRUB=E2=80=9D comes from =E2=80=98grub-install= =E2=80=99, which uses =E2=80=98grub-probe=E2=80=99 to determine the device on which a given direc= tory 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__7= mm_128GB_S0NRNEAB613713', skipping. grub-probe: info: Cannot stat `/dev/disk/by-id/usb-2.0_Flash_Disk_31172800A= 387B500-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=20 grub-probe: info: Cannot stat `/dev/disk/by-id/ata-SAMSUNG_SSD_PM810_2.5__7= mm_128GB_S0NRNEAB613713', skipping. grub-probe: info: Cannot stat `/dev/disk/by-id/usb-2.0_Flash_Disk_31172800A= 387B500-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=E2=80=A6 > 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=E2=80=99s best= to file individual bug reports to bug-guix@gnu.org, or to complement existing ones by email NNN@debbugs.gnu.org where NNN is the bug report number. See for the list of open bugs. Thanks, Ludo=E2=80=99.