From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Tom=C3=A1=C5=A1_?= =?UTF-8?Q?=C4=8Cech?= Subject: bug#20067: fix interpretation of grub configuration Date: Wed, 14 Sep 2016 18:16:29 +0200 Message-ID: <20160914161558.yqhld3ragclyra2h@venom> References: <20150309203443.GA3438@venom> <874mczk0an.fsf@gnu.org> <87vay4rarp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="atbvpbomdu77ssmh" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkDGC-0006jN-HP for bug-guix@gnu.org; Wed, 14 Sep 2016 12:42:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkDG6-0005gv-I9 for bug-guix@gnu.org; Wed, 14 Sep 2016 12:42:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:33760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkDG6-0005gp-Ew for bug-guix@gnu.org; Wed, 14 Sep 2016 12:42:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bkDG6-00014R-9l for bug-guix@gnu.org; Wed, 14 Sep 2016 12:42:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87vay4rarp.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 20067@debbugs.gnu.org --atbvpbomdu77ssmh Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 10, 2016 at 12:03:38AM +0200, Ludovic Court=C3=A8s wrote: >Good news! Good news indeed! > >ludo@gnu.org (Ludovic Court=C3=A8s) skribis: > >> Tom=C3=A1=C5=A1 =C4=8Cech skribis: >> >>> Grub configuration interpretes `linux' as directory where is located >>> bzImage. If I enter file name instead, result configuration will be >>> wrong. >> >> The solution will be to not automatically append =E2=80=9C/bzImage=E2=80= =9D (and >> likewise for the initrd.) >> >> We could change places where =E2=80=98menu-entry=E2=80=99 is instantiate= d to: >> >> #~(string-append #$kernel "/bzImage") >> >> However, there=E2=80=99s the problem that the image name appears in the >> =E2=80=98parameters=E2=80=99 file of the system (as seen in the output o= f =E2=80=98guix system >> build foo.scm=E2=80=99), where it is unevaluated. If we use =E2=80=98st= ring-append=E2=80=99 as >> above, a raw (string-append =E2=80=A6) sexp will appear in there, which = is not >> nice. >> >> To address this, an idea is to add =E2=80=9Cexpanders=E2=80=9D for gexps= : gexps already >> have =E2=80=9Ccompilers=E2=80=9D, and expanders would be similar except = that they would >> produce something possibly different from just the derivation=E2=80=99s = output >> file name. For instance, we could write: >> >> (file-append kernel "/bzImage") >> >> and that would expand directly to: >> >> "/gnu/store/=E2=80=A6/bzImage" > >AFAICS this is finally fixed! > > expanders in commit ebdfd776f4504c456d383ee8afa59fc6fdfc6756 > =E2=80=98file-append=E2=80=99 in commit a9e5e92f940381e3a4ee828c6d8ff22a= 73067e17 > kernel file name in commit 44d5f54e31039d78f156bd9562dca293124eaa76 > >Please let me know how it goes! In particular, does it work for the >dual-boot scenario you were interested in? It is almost perfect. Configuration excerpt... (bootloader (grub-configuration (device "/dev/sda") (menu-entries (list (menu-entry (label "openSUSE") (linux "(hd0,msdos1)/vmlinuz") (linux-arguments (list "root=3D/dev/venom/opensuse" "init=3D/usr/lib/systemd/systemd")) (initrd "(hd0,msdos1)/initrd")))))) =2E..transforms into menuentry "openSUSE" { search --file --set (hd0,msdos1)/vmlinuz linux (hd0,msdos1)/vmlinuz root=3D/dev/venom/opensuse init=3D/usr/lib/sy= stemd/systemd initrd (hd0,msdos1)/initrd } I think that if linux contains prefix '(.*)/', there should be no search for kernel. Thank you very much for fixing this bug (especially when I wasn't able). I believe that fixing this bug is big step in more friendly behavior to other OS. Best regards, S_W --atbvpbomdu77ssmh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX2XfdAAoJEEoj40+gM0NtbAAP/0PBkrVeMBGrUopWmp5mxcTz 3iuz3mpKLjIzGu9XiLr9XymvKoZVvF2N+/Xp6Mqrt6UFsa4z0kA4d6oEq+8kslgL /RCFi20kvD7lA0MtGJmZl4VX3xiL8aZimfTVgAR2KdSiz4r1XHdnzoNZ68D+qssq 7NWQmlwJ5MIbUame1txbdOdPW6Zb9vikpH/vcFcKt4P96nCyDakOq0h5MlMrq3p3 y/L8vYu3xt2loPHnUUlUUuHr2qIEjbGLv1ePTslFYNKR21wUTXb4R50k8oxW1maY wu+xB7N0Tj9mrjnrMcAdMRhYWVpvl9UUHtAgKrEeFgtPwyobNJ1RvFpT38LBkLzl 6UC02CN9eYfl0nBlafsOsnTbsM+5Zrx+SMenANPHOZDCRaj3EHcvn5XWjWk2ptnu dsslrjVyCBffHmvGqgDV4r2wwWBCC5/q9zz5L40AsBzCsM+Si4/YA1BfaKrgP6AX BNb8wgZZig0jT7wx37geVKVFOVo+NwID6lBU8QDe6eKN/IlE+8UhPL9zao1gusJo xDUGjoBQ5FgY7KZoGXDsHcioyMMs/uSWSGZKu+rq4lHgnosX8ZYlVfe+nJ09wn4R VuXYbKYRPIEPVemqbnP85vX7rDeU3Nj9D6gtxFmjJUiWtjU6v1NzrC3bkpPWNzEg CoGp9sqlENaRLawtHvCy =O2b3 -----END PGP SIGNATURE----- --atbvpbomdu77ssmh--