bug#37021: GuixSD 1.01-i686 install DVD boot failure on Macbook1, 1: failed to resolve partition
Apologies for the formatting errors in the previous email. Hopefully this message is cleaner. GRUB loads. I add acpi=off to the boot options and boot. Otherwise, the screen goes black with a '-' symbol at the top left corner and freezes. So, after booting with acpi=off, the display shows the following lines (with timestamps on the left, but I had to manually transcribe so I left them off): %<---begin pasted text--- ehci-pci :00:1d.7: Found HC with no IRQ. Check BIOS/PCI :00:1d.7 setup! ehci-pci :00:1d.7: init :00:1d.7 fail, -19 ehci-pci :00:1d.0: Found HC with no IRQ. Check BIOS/PCI :00:1d.0 setup! ehci-pci :00:1d.0: init :00:1d.0 fail, -19 ehci-pci :00:1d.1: Found HC with no IRQ. Check BIOS/PCI :00:1d.1 setup! ehci-pci :00:1d.1: init :00:1d.1 fail, -19 ehci-pci :00:1d.2: Found HC with no IRQ. Check BIOS/PCI :00:1d.2 setup! ehci-pci :00:1d.2: init :00:1d.2 fail, -19 ehci-pci :00:1d.3: Found HC with no IRQ. Check BIOS/PCI :00:1d.3 setup! ehci-pci :00:1d.3: init :00:1d.7 fail, -19 GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread GC Warning: couldn't read /proc/stat Welcome, this is GNU's early boot Guile. Use '--repl' for an initrd REPL. loading kernel modules... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... waiting for partition '31393730-3031-3031-3139-343934363833' to appear... ERROR: In procedure scm-error: failed to resolve partition "31393730-3031-3031-3139-343934363833" %<-end paste- And then it enters the Guile 2.2.4 prompt, but the keyboard and USB ports are disabled at this stage, so I can't use it.
bug#36753: The GUI installer throws an error
Okay I've figured out what causes openssl build to fail - continuing installation without network connection. The installer told me network connection is required to install the system correctly, but I thought only packages will be outdated. Is it a bug?
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Hi Marius, Marius Bakke writes: > I wanted to check that the bootstrap-tarballs machinery still worked > after merging the branch, since it was non-trivial. Mainly to make the > commit that created them reachable forever, but maybe we don't need it. [...] > [...] I will do this in a 'core-updates-next' branch. I would also > like to merge wip-binaries into it as a final step, unless someone has > objections. I think that 'wip-binaries' (or something close to it) should be merged into 'master', rather than 'core-updates'. That would allow people to easily verify the new bootstrap binaries from 'master'. Of course, anything merged into 'master' will eventually be merged into 'core-updates' as well, but no one will be able to verify the new binaries from 'core-updates' anyway, because 'core-updates' has different versions of 'bash', 'guile', and maybe some other things. What do you think? Mark
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Mark H Weaver writes: > Hi Marius, > > Marius Bakke writes: > >> Marius Bakke writes: >> >>> Jan Nieuwenhuizen writes: >>> Mark H Weaver writes: Hi Mark, >> I called that `wip-binaries', @master from three weeks ago. > > Thank you, that was a good start. I found that some additional patches > were needed to match the bootstrap binaries that 'core-updates' is > currently based on. > > I ended up deleting and repushing a revised 'wip-binaries' to Savannah. > It includes slightly modified versions of the two commits you had > included, as well as some additional cherry-picked commits of yours to > update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a > few of my own. Very nice. > I built the new bootstrap tarballs at the new 'wip-binaries', commit > c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got: > > mhw@jojen ~/guix-wip-binaries$ git describe > v1.0.1-2404-gc67becb31c > mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build > --system=i686-linux bootstrap-tarballs > /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0 > mhw@jojen ~/guix-wip-binaries$ cd > /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0 > mhw@jojen > /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ > sha256sum * > 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b > guile-static-stripped-2.2.4-i686-linux.tar.xz > 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a > linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz > 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 > mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz > fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 > mes-minimal-stripped-0.19-i686-linux.tar.xz > c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 > static-binaries-0-i686-linux.tar.xz > Can you try "guix build --system=i686-linux bootstrap-tarballs" at the > new 'wip-binaries' branch and see if you get the same results? Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running "./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me exactly this, also for guile-static-stripped! \o/ > Also, I have a question: One of the changes I made to 'wip-binaries' was > to update mescc-tools to 0.5.2-0.bb062b0, to match the > %bootstrap-mescc-tools that's currently being used in 'core-updates'. > > However, I noticed that you have also apparently built the official > release of mescc-tools-0.5.2, which is on your site: > > > http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz > > and that this tarball is identical to the build output of the later git > commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz. > > With this in mind, could we just use 0.5.2? What changed between 0.5.2 > and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0? Good catch. We probably can, we might try that. I think the need for updating to bb062b0 has been removed during the review of the integration of the reduced binary seed bootstrap into core-updates by Ludovic. For historical reasons, I think this mescc-tools commit --8<---cut here---start->8--- commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke) Author: Jan Nieuwenhuizen Date: Thu Oct 4 22:03:31 2018 +0200 build.sh: Update for mes 0.18. --8<---cut here---end--->8--- was needed at a time that we did not have mescc-tools or mes in bootstrap tarballs. We built bootstrap variants of mescc-tools and mes using a externally (outside fo Guix) built mescc-tools-seed and (an almost pure ASCII) mes-seed. >>> >>> I tried building the i686 bootstrap tarballs from wip-binaries with this >>> additional patch: >>> >>> diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scm >>> index e298cb05c1..380cac6c88 100644 >>> --- a/gnu/packages/mes.scm >>> +++ b/gnu/packages/mes.scm >>> @@ -139,33 +139,31 @@ Guile.") >>> (license gpl3+))) >>> >>> (define-public mescc-tools >>> - (let ((commit "bb062b0da7bf2724ca40f9002b121579898d4ef7") >>> -(revision "0") >>> -(version "0.5.2")) >>> -(package >>> - (name "mescc-tools") >>> - (version (string-append version "-" revision "." (string-take commit >>> 7))) >>> - (source (origin >>> -(method url-fetch) >>> -(uri (string-append >>> - >>> "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/; >>> - name
bug#36942: Reconfigure broke GRUB
Hi ison,
ison writes:
> On Wed, Aug 07, 2019, Jakob L. Kreuze wrote:
>> I'll continue to investigate; perhaps I'll be able to reproduce if I
>> copy your exact partition scheme in the virtual machine. I'm sorry that
>> you had to go through that whole 'guix init' spiel again.
>
> No problem, it's a backup machine anyway, I've held off on updating
> my main (but it doesn't use efi so maybe I can). If this is a
> problem that only I'm having and nobody else then I wonder if a
> fresh install would fix it. Although I'm surprised nobody else seems to be
> experiencing it.
>
> The only unusual thing I did before it broke is that I tried to consolidate
> my configs from 2 machines into a single one by adding case statements.
> For example at the top I had (define local-profile 'laptop)
> and then my bootloader was something like:
> (bootloader (bootloader-configuration
> (case local-profile
> ((desktop)
>(bootloader grub-bootloader)
>...)
> ((laptop)
>(bootloader grub-efi-bootloader)
>...
>
> But I've since reverted back to my old config for all the subsequent
> "guix init" and reconfigures I've done, so it seems unlikely to be the
> cause but I thought I'd mention it anyway.
> Maybe having a BIOS boot partition on /dev/sda1 even though I'm using
> efi is somehow messing it up?
After some further research, I was able to create a virtual machine with
the partition scheme and bootloader configuration that you described.
;; This is an operating system configuration template
;; for a "bare bones" setup, with no X11 display server.
(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules screen)
(operating-system
(host-name "komputilo")
(timezone "Europe/Berlin")
(locale "en_US.utf8")
;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
;; target hard disk, and "my-root" is the label of the target
;; root file system.
(bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")))
(file-systems (cons* (file-system
(device "/dev/sda2")
(mount-point "/boot/efi")
(type "vfat"))
(file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
;; This is where user accounts are specified. The "root"
;; account is implicit, and is initially created with the
;; empty password.
(users (cons (user-account
(name "alice")
(comment "Bob's sister")
(group "users")
;; Adding the account to the "wheel" group
;; makes it a sudoer. Adding it to "audio"
;; and "video" allows the user to play sound
;; and access the webcam.
(supplementary-groups '("wheel"
"audio" "video")))
%base-user-accounts))
;; Globally-installed packages.
(packages (cons screen %base-packages))
;; Add services to the baseline: a DHCP client and
;; an SSH server.
(services (append (list (service dhcp-client-service-type)
(service openssh-service-type
(openssh-configuration
(port-number
%base-services)))
However, I still cannot seem to reproduce this issue with the most
recent master. Everything boots fine. I've extracted the bootloader
installation "script", and everything appears to be normal to me.
(begin
(use-modules (gnu build bootloader)
(gnu build install)
(guix build utils)
(guix store)
(guix utils)
(ice-9 binary-ports)
(srfi srfi-34)
(srfi srfi-35))
(let* ((gc-root (string-append "/" %gc-roots-directory "/bootcfg"))
(temp-gc-root (string-append gc-root ".new")))
(switch-symlinks temp-gc-root
"/gnu/store/xlb81742i5sb4cdmidfhabprc17ijwck-grub.cfg")
(install-boot-config "/gnu/store/xlb81742i5sb4cdmidfhabprc17ijwck-grub.cfg"
"/boot/grub/grub.cfg" "/")
(when #t
(catch #t
(lambda ()
((lambda (bootloader efi-dir mount-point)
(let ((grub-install (string-append bootloader
"/sbin/grub-install"))
(install-dir (string-append mount-point "/boot"))
(target-esp (if (file-exists? (string-append mount-point
efi-dir))
(string-append mount-point efi-dir)
efi-dir)))
(setenv "GRUB_ENABLE_CRYPTODISK" "y")
(invoke/quiet grub-install "--boot-directory" install-dir
"--bootloader-id=Guix"
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Hi Marius, Marius Bakke writes: > Marius Bakke writes: > >> Jan Nieuwenhuizen writes: >> >>> Mark H Weaver writes: >>> >>> Hi Mark, >>> > I called that `wip-binaries', @master from three weeks ago. Thank you, that was a good start. I found that some additional patches were needed to match the bootstrap binaries that 'core-updates' is currently based on. I ended up deleting and repushing a revised 'wip-binaries' to Savannah. It includes slightly modified versions of the two commits you had included, as well as some additional cherry-picked commits of yours to update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a few of my own. >>> >>> Very nice. >>> I built the new bootstrap tarballs at the new 'wip-binaries', commit c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got: mhw@jojen ~/guix-wip-binaries$ git describe v1.0.1-2404-gc67becb31c mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0 mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0 mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum * 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b guile-static-stripped-2.2.4-i686-linux.tar.xz 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xz c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 static-binaries-0-i686-linux.tar.xz >>> Can you try "guix build --system=i686-linux bootstrap-tarballs" at the new 'wip-binaries' branch and see if you get the same results? >>> >>> Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running >>> "./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me >>> exactly this, >>> also for guile-static-stripped! \o/ >>> Also, I have a question: One of the changes I made to 'wip-binaries' was to update mescc-tools to 0.5.2-0.bb062b0, to match the %bootstrap-mescc-tools that's currently being used in 'core-updates'. However, I noticed that you have also apparently built the official release of mescc-tools-0.5.2, which is on your site: http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz and that this tarball is identical to the build output of the later git commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz. With this in mind, could we just use 0.5.2? What changed between 0.5.2 and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0? >>> >>> Good catch. We probably can, we might try that. >>> >>> I think the need for updating to bb062b0 has been removed during the >>> review of the integration of the reduced binary seed bootstrap into >>> core-updates by Ludovic. >>> >>> For historical reasons, I think this mescc-tools commit >>> >>> --8<---cut here---start->8--- >>> commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke) >>> Author: Jan Nieuwenhuizen >>> Date: Thu Oct 4 22:03:31 2018 +0200 >>> >>> build.sh: Update for mes 0.18. >>> --8<---cut here---end--->8--- >>> >>> was needed at a time that we did not have mescc-tools or mes in >>> bootstrap tarballs. We built bootstrap variants of mescc-tools and mes >>> using a externally (outside fo Guix) built mescc-tools-seed and >>> (an almost pure ASCII) mes-seed. >> >> I tried building the i686 bootstrap tarballs from wip-binaries with this >> additional patch: >> >> diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scm >> index e298cb05c1..380cac6c88 100644 >> --- a/gnu/packages/mes.scm >> +++ b/gnu/packages/mes.scm >> @@ -139,33 +139,31 @@ Guile.") >> (license gpl3+))) >> >> (define-public mescc-tools >> - (let ((commit "bb062b0da7bf2724ca40f9002b121579898d4ef7") >> -(revision "0") >> -(version "0.5.2")) >> -(package >> - (name "mescc-tools") >> - (version (string-append version "-" revision "." (string-take commit >> 7))) >> - (source (origin >> -(method url-fetch) >> -(uri (string-append >> - >> "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/; >> - name "-" commit >> - ".tar.gz")) >> -(sha256 >> - (base32 >> -
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Marius Bakke writes:
> Jan Nieuwenhuizen writes:
>
>> Mark H Weaver writes:
>>
>> Hi Mark,
>>
I called that `wip-binaries', @master from three weeks ago.
>>>
>>> Thank you, that was a good start. I found that some additional patches
>>> were needed to match the bootstrap binaries that 'core-updates' is
>>> currently based on.
>>>
>>> I ended up deleting and repushing a revised 'wip-binaries' to Savannah.
>>> It includes slightly modified versions of the two commits you had
>>> included, as well as some additional cherry-picked commits of yours to
>>> update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a
>>> few of my own.
>>
>> Very nice.
>>
>>> I built the new bootstrap tarballs at the new 'wip-binaries', commit
>>> c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:
>>>
>>> mhw@jojen ~/guix-wip-binaries$ git describe
>>> v1.0.1-2404-gc67becb31c
>>> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build
>>> --system=i686-linux bootstrap-tarballs
>>> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>>> mhw@jojen ~/guix-wip-binaries$ cd
>>> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>>> mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$
>>> sha256sum *
>>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b
>>> guile-static-stripped-2.2.4-i686-linux.tar.xz
>>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a
>>> linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330
>>> mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
>>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0
>>> mes-minimal-stripped-0.19-i686-linux.tar.xz
>>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7
>>> static-binaries-0-i686-linux.tar.xz
>>
>>> Can you try "guix build --system=i686-linux bootstrap-tarballs" at the
>>> new 'wip-binaries' branch and see if you get the same results?
>>
>> Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running
>> "./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me
>> exactly this,
>> also for guile-static-stripped! \o/
>>
>>> Also, I have a question: One of the changes I made to 'wip-binaries' was
>>> to update mescc-tools to 0.5.2-0.bb062b0, to match the
>>> %bootstrap-mescc-tools that's currently being used in 'core-updates'.
>>>
>>> However, I noticed that you have also apparently built the official
>>> release of mescc-tools-0.5.2, which is on your site:
>>>
>>>
>>> http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>>
>>> and that this tarball is identical to the build output of the later git
>>> commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz.
>>>
>>> With this in mind, could we just use 0.5.2? What changed between 0.5.2
>>> and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?
>>
>> Good catch. We probably can, we might try that.
>>
>> I think the need for updating to bb062b0 has been removed during the
>> review of the integration of the reduced binary seed bootstrap into
>> core-updates by Ludovic.
>>
>> For historical reasons, I think this mescc-tools commit
>>
>> --8<---cut here---start->8---
>> commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke)
>> Author: Jan Nieuwenhuizen
>> Date: Thu Oct 4 22:03:31 2018 +0200
>>
>> build.sh: Update for mes 0.18.
>> --8<---cut here---end--->8---
>>
>> was needed at a time that we did not have mescc-tools or mes in
>> bootstrap tarballs. We built bootstrap variants of mescc-tools and mes
>> using a externally (outside fo Guix) built mescc-tools-seed and
>> (an almost pure ASCII) mes-seed.
>
> I tried building the i686 bootstrap tarballs from wip-binaries with this
> additional patch:
>
> diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scm
> index e298cb05c1..380cac6c88 100644
> --- a/gnu/packages/mes.scm
> +++ b/gnu/packages/mes.scm
> @@ -139,33 +139,31 @@ Guile.")
> (license gpl3+)))
>
> (define-public mescc-tools
> - (let ((commit "bb062b0da7bf2724ca40f9002b121579898d4ef7")
> -(revision "0")
> -(version "0.5.2"))
> -(package
> - (name "mescc-tools")
> - (version (string-append version "-" revision "." (string-take commit
> 7)))
> - (source (origin
> -(method url-fetch)
> -(uri (string-append
> -
> "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/;
> - name "-" commit
> - ".tar.gz"))
> -(sha256
> - (base32
> - "1h6j57wyf91i42b26f8msbv6451cw3nm4nmpl1fckp9c7vi8mwkh"
> - (build-system gnu-build-system)
> - (supported-systems '("i686-linux" "x86_64-linux"))
> -
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Jan Nieuwenhuizen writes:
> Mark H Weaver writes:
>
> Hi Mark,
>
>>> I called that `wip-binaries', @master from three weeks ago.
>>
>> Thank you, that was a good start. I found that some additional patches
>> were needed to match the bootstrap binaries that 'core-updates' is
>> currently based on.
>>
>> I ended up deleting and repushing a revised 'wip-binaries' to Savannah.
>> It includes slightly modified versions of the two commits you had
>> included, as well as some additional cherry-picked commits of yours to
>> update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a
>> few of my own.
>
> Very nice.
>
>> I built the new bootstrap tarballs at the new 'wip-binaries', commit
>> c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got:
>>
>> mhw@jojen ~/guix-wip-binaries$ git describe
>> v1.0.1-2404-gc67becb31c
>> mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux
>> bootstrap-tarballs
>> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>> mhw@jojen ~/guix-wip-binaries$ cd
>> /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0
>> mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$
>> sha256sum *
>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b
>> guile-static-stripped-2.2.4-i686-linux.tar.xz
>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a
>> linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330
>> mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz
>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0
>> mes-minimal-stripped-0.19-i686-linux.tar.xz
>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7
>> static-binaries-0-i686-linux.tar.xz
>
>> Can you try "guix build --system=i686-linux bootstrap-tarballs" at the
>> new 'wip-binaries' branch and see if you get the same results?
>
> Yes, on c67becb31c30a5cd7685f166970ac4793e3a34a9 running
> "./pre-inst-env guix build --system=i686-linux bootstrap-tarballs" gives me
> exactly this,
> also for guile-static-stripped! \o/
>
>> Also, I have a question: One of the changes I made to 'wip-binaries' was
>> to update mescc-tools to 0.5.2-0.bb062b0, to match the
>> %bootstrap-mescc-tools that's currently being used in 'core-updates'.
>>
>> However, I noticed that you have also apparently built the official
>> release of mescc-tools-0.5.2, which is on your site:
>>
>>
>> http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>
>> and that this tarball is identical to the build output of the later git
>> commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz.
>>
>> With this in mind, could we just use 0.5.2? What changed between 0.5.2
>> and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?
>
> Good catch. We probably can, we might try that.
>
> I think the need for updating to bb062b0 has been removed during the
> review of the integration of the reduced binary seed bootstrap into
> core-updates by Ludovic.
>
> For historical reasons, I think this mescc-tools commit
>
> --8<---cut here---start->8---
> commit c184e95096881a13f29ebd7fc507fe305d3d8de5 (gitlab/janneke, janneke)
> Author: Jan Nieuwenhuizen
> Date: Thu Oct 4 22:03:31 2018 +0200
>
> build.sh: Update for mes 0.18.
> --8<---cut here---end--->8---
>
> was needed at a time that we did not have mescc-tools or mes in
> bootstrap tarballs. We built bootstrap variants of mescc-tools and mes
> using a externally (outside fo Guix) built mescc-tools-seed and
> (an almost pure ASCII) mes-seed.
I tried building the i686 bootstrap tarballs from wip-binaries with this
additional patch:
diff --git a/gnu/packages/mes.scm b/gnu/packages/mes.scm
index e298cb05c1..380cac6c88 100644
--- a/gnu/packages/mes.scm
+++ b/gnu/packages/mes.scm
@@ -139,33 +139,31 @@ Guile.")
(license gpl3+)))
(define-public mescc-tools
- (let ((commit "bb062b0da7bf2724ca40f9002b121579898d4ef7")
-(revision "0")
-(version "0.5.2"))
-(package
- (name "mescc-tools")
- (version (string-append version "-" revision "." (string-take commit 7)))
- (source (origin
-(method url-fetch)
-(uri (string-append
- "https://git.savannah.nongnu.org/cgit/mescc-tools.git/snapshot/;
- name "-" commit
- ".tar.gz"))
-(sha256
- (base32
- "1h6j57wyf91i42b26f8msbv6451cw3nm4nmpl1fckp9c7vi8mwkh"
- (build-system gnu-build-system)
- (supported-systems '("i686-linux" "x86_64-linux"))
- (arguments
- `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
- #:test-target "test"
- #:phases (modify-phases %standard-phases
-
bug#36753: The GUI installer throws an error
> However, “failed to build openssh” looks like another failure worth > investigating. Do you have more info as to what happened exactly, > what was printed? Can you reproduce it? It would be great if you > could post a picture of the screen at that point. Sorry for the delay, I had no free hard drive do test installation again. The thing that failed to build was openssl, not openssh. The error message is "build of /gnu/store/long-sum-openssl-1.0.2p.drv failed". What I did during the installation: - whole disk with encryption - tor, mozilla nss - i3, xfce, enlightenment And when the installer asked me if I want to continue without network connection I plugged-in the ethernet cable.
