Re: Seeding the Linux RNG at first boot
Leo Famulari skribis: > On Thu, Dec 07, 2017 at 10:07:38PM +0100, Ludovic Courtès wrote: >> Leo Famulari skribis: >> > On the guest side, we would extend urandom-seed-service to also draw on >> > /dev/hwrng, which is where virtio-rng-pci makes the data from the host >> > available. >> >> Maybe ‘virtualized-operating-system’ in (gnu system vm) could >> automatically customize ‘rngd-service-type’ (or add it)? > > Yes, we could do that, although I don't think it's necessary to run a > daemon continuously. It is enough to seed the RNG once. > > At the same time we handle the random seed, we could also try reading > from /dev/hwrng and, if the read is successful, copy some bytes into > /dev/urandom. We'd have to try reading and handle failure since we > always create /dev/hwrng regardless of whether the Linux kernel module > is loaded or not. OK. >> > I have an idea for another improvement: to add an argument like >> > "--entropy-seed=" to `guix system` that could place the value in >> > '/var/lib/random-seed', where it would be used on first boot. >> >> We could do that, though I very much prefer the idea of a “backdoor” à >> la virtio-rng-pci, because it allows to stick to bit-reproducible images >> (well, they’re not bit-reproducible yet I suppose, but let’s not add to >> it.) > > I think it would be most useful for disk images, for which there is no > host. OK, in that case the “backdoor” isn’t an option. > If one always passes the same value to --entropy-seed, it will not > negatively affect the reproducibility of the image ;) > > This would not be something we do for the official release image, but > merely an optional tool. Yeah it’d be OK to add this as an option. When the option is present, ‘guix system’ would hook into the VM creation code somehow, or to extend ‘activation-service-type’ with code to create the file. Maybe we could provide a more generic --copy-file=SOURCE[=DEST] option? Like --copy-file=./my-seed=/var/lib/random-seed or --copy-file=$HOME/.ssh/authorized_keys. Thoughts? Ludo’.
Re: Iso image size
Hello, Gábor Boskovits skribis: > I don't know what we are currently doing to get the installer iso image > sized down, but I caught some discussion yesterday on irc, that the image > is actually very well compressible, and checking the sizes it really is. > > Might that be possible to do something like compressing the root filesystem > image on the iso image, and decompress it from initrd before mounting? Wouldn’t it be complex and memory-intensive? To me the efforts should go into reducing the size of our packages. For example, in ‘core-updates’, guile, glibc, and guix are already noticeably smaller; likewise, the recently-introduced ‘groff-minimal’ allowed us to get rid of Perl in the installation system closure. We should keep working in that direction IMO. Ludo’.
Reproducible installation images
Hi Mark, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Here are the bootable USB installation images and their signatures[*]: >> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.i686-linux.iso.xz >> >> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.i686-linux.iso.xz.sig >> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz >> >> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz.sig >> >> Here is the QCOW2 virtual machine (VM) image and its signature: >> https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz >> https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz.sig >> >> Here are the binary tarballs and their signatures[*]: >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.i686-linux.tar.xz >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.i686-linux.tar.xz.sig >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.x86_64-linux.tar.xz >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.x86_64-linux.tar.xz.sig >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.armhf-linux.tar.xz >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.armhf-linux.tar.xz.sig >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.aarch64-linux.tar.xz >> >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.aarch64-linux.tar.xz.sig > > To enable independent verification of these installer images, it would > be helpful to include the precise commands needed to reproduce these > images, and the git commit to run them on. > > What do you think? The manual already gives those commands: https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html (bottom) https://www.gnu.org/software/guix/manual/html_node/Building-the-Installation-Image.html Do you think we should show them more prominently? However, disk images are likely not bit-reproducible currently, primarily due to non-determinism in how file systems populate the disk. They might be reproducible if ‘guix system’ always creates files in the same order, which is something we could enforce (perhaps that’s already the case). If it’s not sufficient, then we should look at what others in the reproducible-builds.org effort have been doing (Tails achieved reproducible ISO images, for instance, and I think OpenWrt people were looking at ext2 reproducibility.) There may also be lingering non-reproducibility issues in some of the packages included that need to be addressed. It would be good to investigate! Ludo’.
Re: 03/03: gnu: libinput: Update to 1.9.3.
Hi,
Efraim Flashner skribis:
> On Fri, Dec 08, 2017 at 08:36:27PM -0500, Mark H Weaver wrote:
>> efr...@flashner.co.il (Efraim Flashner) writes:
>>
>> > efraim pushed a commit to branch master
>> > in repository guix.
>> >
>> > commit 5f5083749c1ff2731e84fa7d8eea182ad45c18a5
>> > Author: Efraim Flashner
>> > Date: Fri Dec 8 09:25:40 2017 +0200
>> >
>> > gnu: libinput: Update to 1.9.3.
>> >
>> > * gnu/packages/freedesktop.scm (libinput): Update to 1.9.3.
>> > [build-system]: Switch to meson-build-system.
>>
>> FYI, switching to 'meson-build-system' here caused around 120+ more
>> dependency failures on armhf-linux, including xf86-input-libinput, since
>> we've never successfully built 'ninja' on armhf-linux. So, we've
>> essentially just lost graphics support on armhf-linux.
>>
>>Mark
>
> 1.8.3 is the last version that still has autotools support, it was
> removed in the 1.9 branch. Unfortunately I don't have access to an armhf
> machine to try to fix the armhf build of ninja. I suspect that this is
> going to be an issue going forward, as more packages move to a meson
> build system.
>
> I'm not against downgrading to 1.8.3 in the mean time to keep the
> packages that depend on libinput{,-minimal} available to armhf users,
> but it is something that's going to need to be addressed sooner rather
> than later.
Maybe the safe approach is to revert now so armhf users get graphics
back, take time to investigate and fix the Ninja build failures on ARM
(surely there are patches floating around on the intertubes), and then
reinstate the upgrade.
How does that sound?
(Note that I’m volunteering, but hey! ;-))
Ludo’.
Re: Reproducible installation images
Ludovic Courtès transcribed 2.6K bytes: > Hi Mark, > > Mark H Weaver skribis: > > > l...@gnu.org (Ludovic Courtès) writes: > > > >> Here are the bootable USB installation images and their signatures[*]: > >> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.i686-linux.iso.xz > >> > >> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.i686-linux.iso.xz.sig > >> > >> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz > >> > >> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz.sig > >> > >> Here is the QCOW2 virtual machine (VM) image and its signature: > >> https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz > >> > >> https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz.sig > >> > >> Here are the binary tarballs and their signatures[*]: > >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.i686-linux.tar.xz > >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.i686-linux.tar.xz.sig > >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.x86_64-linux.tar.xz > >> > >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.x86_64-linux.tar.xz.sig > >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.armhf-linux.tar.xz > >> > >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.armhf-linux.tar.xz.sig > >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.aarch64-linux.tar.xz > >> > >> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.aarch64-linux.tar.xz.sig > > > > To enable independent verification of these installer images, it would > > be helpful to include the precise commands needed to reproduce these > > images, and the git commit to run them on. > > > > What do you think? > > The manual already gives those commands: > > https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html > (bottom) > > https://www.gnu.org/software/guix/manual/html_node/Building-the-Installation-Image.html > > Do you think we should show them more prominently? > > However, disk images are likely not bit-reproducible currently, > primarily due to non-determinism in how file systems populate the disk. > > They might be reproducible if ‘guix system’ always creates files in the > same order, which is something we could enforce (perhaps that’s already > the case). If it’s not sufficient, then we should look at what others > in the reproducible-builds.org effort have been doing (Tails achieved > reproducible ISO images, for instance, and I think OpenWrt people were > looking at ext2 reproducibility.) > > There may also be lingering non-reproducibility issues in some of the > packages included that need to be addressed. > > It would be good to investigate! Definitely, I agree. Should we open a new bug ticket to track this effort? > Ludo’. > > -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
Re: Dualbooting with guixsd not handling grub installation
Hello, Mathieu Othacehe skribis: >>> This could be done by adding a cli argument for reconfigure or allowing >>> an empty string in (grub-configuration (target "")). >>> >>> WDYT? >>> > > An already available option would be to override the grub-installer like > this : > > (define no-op-installer > #~(lambda (bootloader device mount) > (display "no op"))) > > (bootloader (bootloader > (inherit grub-bootloader) > (installer no-op-installer)) We could even define and document it as ‘no-bootloader’ or something like that. > I admit this is not ideal, so I would propose two options : > > * Allow for target field to be #f and do not call the installer when > this happends. Sounds reasonable. > * Precise the --no-bootloader parameter of guix system to deal with > multiple cases, for example : > > --bootloader=[default|no-config-file|no-install|...] > > WDYT ? What would it do in the ‘no-config-file’ case? Run ‘grub-install’ (or similar) without regenerating ‘grub.cfg’? Does that make sense? Thanks, Ludo’.
Problems updating guix to 0.14.0 using guix pull.
Hi, I try updating guix to 0.14.0 using guix pull. This fails # guix --version guix (GNU Guix) 20170924.19 # guix pull … error-message suggesting to run guix package -i guile-git # guix package -i guile-git … done # … set environment variables # guix pull … Updating from Git repository at 'https://git.savannah.gnu.org/git/guix.git Building from Git commit 8be84d31… … -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Problems updating guix to 0.14.0 using guix pull (solved)
Hi, Sorry, I just sent the message unfinished, here is the complete one. When I tried to reproduce this problem, it was gone. Fine for me :-) but no problem report any more :-( -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
Needs enhancement: "is my guix current?"
Hi, on my effort to solve the problems when updating to guix 0.14.0, I stepped over this simple question: Is the installed guix the current one, resp. the current one my guix knows of? Is there anyway to find out whether 20170924.19 or 0.13.0-6.a9468b4 is newer? guix installed: # guix --version guix (GNU Guix) 20170924.19 guix knows to my guix: # guix package -A guix guix 0.13.0-6.a9468b4 From the usability point of view, this information needs to be ovbiously available. Users should easily be able to to determine which version is the newer one. Since I do not know how these different version numbers are generated, I can't make any suggestions, though. Sorry. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Reproducible installation images
ng0 skribis: > Ludovic Courtès transcribed 2.6K bytes: [...] >> However, disk images are likely not bit-reproducible currently, >> primarily due to non-determinism in how file systems populate the disk. >> >> They might be reproducible if ‘guix system’ always creates files in the >> same order, which is something we could enforce (perhaps that’s already >> the case). If it’s not sufficient, then we should look at what others >> in the reproducible-builds.org effort have been doing (Tails achieved >> reproducible ISO images, for instance, and I think OpenWrt people were >> looking at ext2 reproducibility.) >> >> There may also be lingering non-reproducibility issues in some of the >> packages included that need to be addressed. >> >> It would be good to investigate! > > Definitely, I agree. Should we open a new bug ticket to track this effort? Sure, two even: one for the binary tarball, one for the GuixSD ISO image. Ludo’.
Re: Needs enhancement: "is my guix current?"
Hi, Hartmut Goebel skribis: > Is the installed guix the current one, resp. the current one my guix > knows of? Is there anyway to find out whether 20170924.19 or > 0.13.0-6.a9468b4 is newer? > > guix installed: > > # guix --version > guix (GNU Guix) 20170924.19 Nowadays a Git commit is recorded, not a date. Currently ‘guix package’ et al. simply warn you if you haven’t run ‘guix pull’ in seven days. It could also check the upstream Git repo for the latest commit, though that wouldn’t provide much more information, I think. Ludo’.
Re: FOSDEM 2018 and announcing a GNU Guix/Guile day!
Hi Manolis, I'll be in Brussels for FOSDEM and will join you :) Cheers, Mark On Tue, Dec 5, 2017, at 18:59, Manolis Ragkousis wrote: > Hello everyone, > > We now have a wiki page for our FOSDEM GNU Guix/Guile day. [1] > > If you are going to attend please add your name to the wiki, or just > respond to this email, so we can order enough lunches! Of course > everyone is welcome to come whether they register or not! > > Also if you know anyone wanting to sponsor the event, please do tell him > to contact me or Pjotr! > > Looking forward to seeing everyone there! > > Manolis > > [1] https://libreplanet.org/wiki/Group:Guix/FOSDEM2018 > -- Mark Meyer m...@ofosos.org
Re: Seeding the Linux RNG at first boot
On Mon, Dec 11, 2017 at 10:16:42AM +0100, Ludovic Courtès wrote: > Leo Famulari skribis: > > At the same time we handle the random seed, we could also try reading > > from /dev/hwrng and, if the read is successful, copy some bytes into > > /dev/urandom. We'd have to try reading and handle failure since we > > always create /dev/hwrng regardless of whether the Linux kernel module > > is loaded or not. > > OK. Okay, I'll work on adding this to the urandom-seed-service. > > If one always passes the same value to --entropy-seed, it will not > > negatively affect the reproducibility of the image ;) > > > > This would not be something we do for the official release image, but > > merely an optional tool. > > Yeah it’d be OK to add this as an option. > > When the option is present, ‘guix system’ would hook into the VM > creation code somehow, or to extend ‘activation-service-type’ with code > to create the file. > > Maybe we could provide a more generic --copy-file=SOURCE[=DEST] option? > Like --copy-file=./my-seed=/var/lib/random-seed or > --copy-file=$HOME/.ssh/authorized_keys. > > Thoughts? That sounds good to me. I'll try implementing it. signature.asc Description: PGP signature
Re: FOSDEM 2018 and announcing a GNU Guix/Guile day!
Pjotr Prins transcribed 1.0K bytes: > We are hosting a GNU Guix and Guile day on Friday before FOSDEM (that > is Feb 2nd.). We have a large room for 40 people at http://icab.be/ > for the whole day. In the morning we'll have talks - and in the > afternoon it is free discussion and hacking. > > Write Manolis, Ludo or me if you would like to give a talk. > > We'll want to record them, so if anyone here has a camera and is > willing to help out we will be very grateful! > > We'll set up a registration page a few weeks in advance because we > need to know how many lunches to order. Note you can also stay at > ICAB. It is not expensive and I have heard it is pretty good. > > FOSDEM is one of the greatest free software events in the world with 2 > days of talks on some 30 tracks https://fosdem.org/2018/! You should > consider going. Almost everyone I know who attends FOSDEM keeps coming > back. There is something for everyone! Personally, I get inspired > *every* time (sometimes detrimental to my free time the rest of the > year). > > It is how I got to be part of Guix - it was a talk by Ludo. Hope to > see you there! > > Pj. For those who can not make it to the meeting - I'm still not sure if it'll be financially and timewise good for me to attend - could you try to hook the meeting / talk parts into mumble? In other words, have one laptop joined on a mumble server and (ideally) let those back at home participate. We've done this with at least the last GNUnet eV meeting and a couple of secushare meetings. You can use our mumble server on gnunet.org for this. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
Re: Guix - installation script
On 10/02/2017 at 09:15 Pjotr Prins writes: > A script that would install the binary install package of Guix would > be very useful. It should unpack the tarball into /gnu/store and > /var/guix (checking nothing is there), set the keys and (optionally) > the build users. Ideally we should have: > >wget install.sh >sudo sh install.sh > - fetchin' guix... > - unpacking guix... > - installing guix... > - fetching keys... > - set build users... > - running guix pull... >guix package -i hello >(binary installs...) > > They keys of main substitute servers should just work. > > I just went through helping someone install Guix remotely and it is > *too* painful. He is an experienced devop(!) It took hours, mostly > because he forgot to set the keys correctly (Guix gives no proper > feedback). [...] I don't see how we can recommend Guix with a clear conscience if we don't automate these tedious steps, at least for a few popular distributions. FWIW, the last time I grappled with a binary install (guix-0.9.0 in Mar 2016 on Debian), I found a makefile to be the most handy way to automate install/uninstall. I'm not posting it because it doesn't work w/ Guix 0.15.0, but happy to provide to anyone interested. - George
Re: Reproducible installation images
l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Here are the bootable USB installation images and their signatures[*]: >>> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.i686-linux.iso.xz >>> >>> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.i686-linux.iso.xz.sig >>> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz >>> >>> https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz.sig >>> >>> Here is the QCOW2 virtual machine (VM) image and its signature: >>> https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz >>> >>> https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz.sig >>> >>> Here are the binary tarballs and their signatures[*]: >>> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.i686-linux.tar.xz >>> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.i686-linux.tar.xz.sig >>> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.x86_64-linux.tar.xz >>> >>> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.x86_64-linux.tar.xz.sig >>> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.armhf-linux.tar.xz >>> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.armhf-linux.tar.xz.sig >>> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.aarch64-linux.tar.xz >>> >>> https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.aarch64-linux.tar.xz.sig >> >> To enable independent verification of these installer images, it would >> be helpful to include the precise commands needed to reproduce these >> images, and the git commit to run them on. >> >> What do you think? > > The manual already gives those commands: > > https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html > (bottom) > > https://www.gnu.org/software/guix/manual/html_node/Building-the-Installation-Image.html They give the commands, but they do not provide the git commit that you ran these commands on. > However, disk images are likely not bit-reproducible currently, > primarily due to non-determinism in how file systems populate the disk. That's true, but it would still allow us to independently create images as close as possible to the ones you created, and it would allow us to compare the images and see how they differ. Mark
