* GNU Guix 1.2.0rc1 available for testing! @ 2020-11-13 17:07 Ludovic Courtès 2020-11-15 16:19 ` zimoun ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Ludovic Courtès @ 2020-11-13 17:07 UTC (permalink / raw) To: guix-devel [-- Attachment #1: Type: text/plain, Size: 2853 bytes --] Hello Guix! I’m happy to announce a release candidate for 1.2.0: source: https://alpha.gnu.org/gnu/guix/guix-1.2.0rc1.tar.gz binary tarball (to install on a “foreign distro”): https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc1.aarch64-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc1.armhf-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc1.i686-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc1.x86_64-linux.tar.xz system installation: https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.i686-linux.iso.xz https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz virtual machine image: https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.2.0rc1.x86_64-linux.xz SHA256 hashes: ac85dbfa17bfb582c91b867928bd1eebc4dc36b61fca2d8014ba0e8c83879932 guix-1.2.0rc1.tar.gz 83996dad6ec4d1a0ee59ee2eab37cc2398e0d894fb942c67347009a37250be02 guix-binary-1.2.0rc1.aarch64-linux.tar.xz ee2071da2640843977c56cfc9fdf7c346c9c88f250b1f20baff27731e4a3ff5a guix-binary-1.2.0rc1.armhf-linux.tar.xz b7174db2faaf2d7fad74ab5c06b635f39d38f3f80b023f3de8e4c0d30bd84cf9 guix-binary-1.2.0rc1.i686-linux.tar.xz 625f57a7a16118a98330a3f03d0d63509a0b4a61e56a179f1a2c0ca1e00de3b6 guix-binary-1.2.0rc1.x86_64-linux.tar.xz f4dc25282cfcb5f9426c17cf0d18984846595cf6815ffd87315596e3514a5d71 guix-system-install-1.2.0rc1.i686-linux.iso.xz 8478f762146bcbc0ce7683395a846b6cbcf6002107e71df4248bf9d8699d52e2 guix-system-install-1.2.0rc1.x86_64-linux.iso.xz 8bd4e9cbb4e218ca5afa02d5f7e8bc70d4b3ed1c19b6576488051ed61a5cfc89 guix-system-vm-image-1.2.0rc1.x86_64-linux.xz All these files have an associated ‘.sig’, an OpenPGP signature that you can verify as explained at <https://guix.gnu.org/manual/en/html_node/Binary-Installation.html>. You can help by: 1. Testing the binary tarball on the distro of your choice. You can download <https://guix.gnu.org/install.sh> and tweak it so it fetches 1.2.0rc1 (patch not included :-)). 2. Testing the graphical installer of Guix System. 3. Testing the VM image. 4. Testing the bug fix for <https://issues.guix.gnu.org/35594>: in GNOME, Xfce, and other GLib-based desktop environment, the application menu should now be automatically updated as soon as ‘guix install’, ‘guix remove’, etc. complete. You can also test this without going through a full system installation by running: guix time-machine --branch=version-1.2.0 \ system reconfigure /etc/config.scm In any case, please report success, failure, and annoyances in this thread. It would be nice to release 1.2.0 before the Guix Day and the Guix anniversary (Nov. 23). Thanks in advance! Ludo’. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 853 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-13 17:07 GNU Guix 1.2.0rc1 available for testing! Ludovic Courtès @ 2020-11-15 16:19 ` zimoun 2020-11-15 19:16 ` pelzflorian (Florian Pelz) 2020-11-16 0:10 ` Oleg Pykhalov 2 siblings, 0 replies; 26+ messages in thread From: zimoun @ 2020-11-15 16:19 UTC (permalink / raw) To: Ludovic Courtès, guix-devel Hi Ludo. On Fri, 13 Nov 2020 at 18:07, Ludovic Courtès <ludo@gnu.org> wrote: > In any case, please report success, failure, and annoyances in this thread. Everything looks fine for me. Even the ’r-*’ packages are there. It is not finished yet but I would like to have a script that check the availability build-system per build-system. Something really better than: --8<---------------cut here---------------start------------->8--- $ pkgs=$(guix time-machine --branch=version-1.2.0 -- package -A ^sbcl- |cut -f1) Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... $ guix time-machine --branch=version-1.2.0 -- weather $pkgs Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... computing 455 package derivations for x86_64-linux... looking for 456 store items on https://ci.guix.gnu.org... updating substitutes from 'https://ci.guix.gnu.org'... 100.0% https://ci.guix.gnu.org 71.3% substitutes available (325 out of 456) at least 214.3 MiB of nars (compressed) 431.6 MiB on disk (uncompressed) 0.023 seconds per request (10.4 seconds in total) 43.0 requests per second 0.0% (0 out of 131) of the missing items are queued at least 1,000 queued builds x86_64-linux: 495 (49.5%) i686-linux: 355 (35.5%) aarch64-linux: 126 (12.6%) armhf-linux: 24 (2.4%) build rate: 32.11 builds per hour i686-linux: 10.53 builds per hour x86_64-linux: 13.04 builds per hour aarch64-linux: 4.63 builds per hour armhf-linux: 4.16 builds per hour --8<---------------cut here---------------end--------------->8--- Thank you for the release candidate and all the under-the-hood work. Cheers, simon ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-13 17:07 GNU Guix 1.2.0rc1 available for testing! Ludovic Courtès 2020-11-15 16:19 ` zimoun @ 2020-11-15 19:16 ` pelzflorian (Florian Pelz) 2020-11-15 21:53 ` Marius Bakke 2020-11-16 0:10 ` Oleg Pykhalov 2 siblings, 1 reply; 26+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-11-15 19:16 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 458 bytes --] On Fri, Nov 13, 2020 at 06:07:32PM +0100, Ludovic Courtès wrote: > system installation: > […] > https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz Sorry for testing so late. For me the graphical installer crashes when doing a Manual Partitioning with an encrypted partition. I attach the last-installer-error after Manual Partitioning. Can others successfully use encryption with the installer? Regards, Florian [-- Attachment #2: last-installer-error --] [-- Type: text/plain, Size: 1949 bytes --] In ./gnu/installer/newt/partition.scm: 785:4 19 (run-partitioning-page) In srfi/srfi-1.scm: 634:9 18 (for-each #<procedure 7f09c7a2b3d8 at ./gnu/installer/parted.scm:1392:14 (file-name)> ("/dev/sda" "/dev/sdb")) In ./gnu/installer/parted.scm: 1395:23 17 (_ _) In ice-9/boot-9.scm: 1669:16 16 (raise-exception _ #:continuable? _) 1667:16 15 (raise-exception _ #:continuable? _) 1667:16 14 (raise-exception _ #:continuable? _) 1667:16 13 (raise-exception _ #:continuable? _) 1667:16 12 (raise-exception _ #:continuable? _) 1667:16 11 (raise-exception _ #:continuable? _) 1667:16 10 (raise-exception _ #:continuable? _) 1667:16 9 (raise-exception _ #:continuable? _) 1667:16 8 (raise-exception _ #:continuable? _) 1667:16 7 (raise-exception _ #:continuable? _) 1764:13 6 (_ #<&compound-exception components: (#<&error> #<&origin origin: #f> #<&message message: "~A"> #<&irritants irritants: ("Device /dev/sda is still in use.")> #<&exception-with-kind-an…>) In ice-9/eval.scm: 619:8 5 (_ #(#(#<directory (guile-user) 7f09d2bc2f00> #<<installer> name: newt init: #<procedure init ()> exit: #<procedure exit ()> exit-error: #<procedure exit-error (file key args)> f…>) …)) 619:8 4 (_ #(#(#(#<directory (guile-user) 7f09d2bc2f00> #<<installer> name: newt init: #<procedure init ()> exit: #<procedure exit ()> exit-error: #<procedure exit-error (file key arg…>) …) #)) In ice-9/ports.scm: 463:17 3 (call-with-output-file _ _ #:binary _ #:encoding _) In ice-9/eval.scm: 619:8 2 (_ #(#(#<directory (guile-user) 7f09d2bc2f00> misc-error (#f "~A" ("Device /dev/sda is still in use.") #f)) #<output: /tmp/last-installer-error 19>)) 159:9 1 (_ #(#(#<directory (guile-user) 7f09d2bc2f00> misc-error (#f "~A" ("Device /dev/sda is still in use.") #f)) #<output: /tmp/last-installer-error 19>)) In unknown file: 0 (make-stack #t) ice-9/eval.scm:159:9: Device /dev/sda is still in use. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-15 19:16 ` pelzflorian (Florian Pelz) @ 2020-11-15 21:53 ` Marius Bakke 2020-11-15 23:16 ` pelzflorian (Florian Pelz) 0 siblings, 1 reply; 26+ messages in thread From: Marius Bakke @ 2020-11-15 21:53 UTC (permalink / raw) To: pelzflorian (Florian Pelz), Ludovic Courtès; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 808 bytes --] "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes: > On Fri, Nov 13, 2020 at 06:07:32PM +0100, Ludovic Courtès wrote: >> system installation: >> […] >> https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz > > Sorry for testing so late. For me the graphical installer crashes > when doing a Manual Partitioning with an encrypted partition. > I attach the last-installer-error after Manual Partitioning. > > Can others successfully use encryption with the installer? I have just installed a system using manual partitioning through the installer, with encryption. Everything worked like a charm. Can you provide more details about the steps you did to arrive at the error? And information about the (new and old) partition layout? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 507 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-15 21:53 ` Marius Bakke @ 2020-11-15 23:16 ` pelzflorian (Florian Pelz) 2020-11-16 9:12 ` Mathieu Othacehe 2020-11-16 15:39 ` Miguel Ángel Arruga Vivas 0 siblings, 2 replies; 26+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-11-15 23:16 UTC (permalink / raw) To: Marius Bakke; +Cc: guix-devel On Sun, Nov 15, 2020 at 10:53:29PM +0100, Marius Bakke wrote: > I have just installed a system using manual partitioning through the > installer, with encryption. Everything worked like a charm. > > Can you provide more details about the steps you did to arrive at the > error? And information about the (new and old) partition layout? Thank you for trying. Hmm strange. I tried once again (I think I did the same steps as before) and it worked. Maybe I forgot something? Maybe it depends on how fast the machine completes a formatting task? So I tried again two more times and it failed again, I got the error again both times during partition formatting. So all the partitioning is already done except for the encryption. /dev/sdc is the install USB drive. /dev/sda is the hard disk. /dev/sda1 is the EFI system partition; I do not format it. /dev/sda5 is the partition I try to put the encrypted root fs on. I check encryption and set its mount point to “/”. /var/log/messages has the following log for the installer: Nov 15 23:49:30 localhost installer[259]: Display is 128x42. Nov 15 23:49:30 localhost installer[259]: running step 'locale' Nov 15 23:49:30 localhost installer[259]: running step 'language' Nov 15 23:49:31 localhost installer[259]: running form #<newt-form 771a60> ("Locale language") with 0 clients Nov 15 23:49:40 localhost vmunix: [ 56.102132] tg3 0000:03:00.0 enp3s0: Link is down Nov 15 23:49:40 localhost connmand[210]: enp3s0 {RX} 24 packets 3438 bytes Nov 15 23:49:40 localhost connmand[210]: enp3s0 {TX} 31 packets 3795 bytes Nov 15 23:49:40 localhost connmand[210]: enp3s0 {update} flags 36867 <UP> Nov 15 23:49:40 localhost connmand[210]: enp3s0 {newlink} index 2 address 10:9A:DD:46:4F:9F mtu 1500 Nov 15 23:49:40 localhost connmand[210]: enp3s0 {newlink} index 2 operstate 2 <DOWN> Nov 15 23:49:40 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to Nov 15 23:49:40 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} address 192.168.178.74/24 label enp3s0 Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route 192.168.178.0 gw 0.0.0.0 scope 253 <LINK> Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route fd00:: gw :: scope 0 <UNIVERSE> Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route fe80:: gw :: scope 0 <UNIVERSE> Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} address fd00::129a:ddff:fe46:4f9f/64 label (null) Nov 15 23:50:23 localhost installer[259]: running step 'territory' Nov 15 23:50:23 localhost installer[259]: running form #<newt-form 771ab0> ("Locale location") with 0 clients Nov 15 23:50:26 localhost installer[259]: running step 'codeset' Nov 15 23:50:26 localhost installer[259]: running step 'modifier' Nov 15 23:50:26 localhost shepherd[1]: Service console-font-tty2 has been stopped. Nov 15 23:50:26 localhost shepherd[1]: Service term-tty2 has been stopped. Nov 15 23:50:26 localhost shepherd[1]: Service host-name has been started. Nov 15 23:50:26 localhost shepherd[1]: Service term-tty2 has been started. Nov 15 23:50:26 localhost installer[259]: running step 'welcome' Nov 15 23:50:26 localhost installer[259]: running form #<newt-form 788ea0> ("GNU Guix install") with 0 clients Nov 15 23:50:27 localhost installer[259]: running step 'timezone' Nov 15 23:50:27 localhost installer[259]: running form #<newt-form 789640> ("Timezone") with 0 clients Nov 15 23:50:32 localhost installer[259]: running form #<newt-form 7859b0> ("Timezone") with 0 clients Nov 15 23:50:34 localhost installer[259]: running step 'keymap' Nov 15 23:50:34 localhost installer[259]: running step 'layout' Nov 15 23:50:34 localhost installer[259]: running form #<newt-form 783e40> ("Layout") with 0 clients Nov 15 23:50:36 localhost installer[259]: running step 'variant' Nov 15 23:50:36 localhost installer[259]: running form #<newt-form 7842a0> ("Variant") with 0 clients Nov 15 23:50:41 localhost installer[259]: running step 'hostname' Nov 15 23:50:41 localhost installer[259]: running form #<newt-form 785dd0> ("Hostname") with 0 clients Nov 15 23:50:53 localhost installer[259]: running step 'network' Nov 15 23:50:53 localhost installer[259]: running step 'select-technology' Nov 15 23:50:53 localhost installer[259]: running step 'power-technology' Nov 15 23:50:54 localhost installer[259]: running step 'connect-service' Nov 15 23:50:54 localhost installer[259]: running form #<newt-form 7e5590> ("No service") with 0 clients Nov 15 23:51:00 localhost vmunix: [ 135.760473] tg3 0000:03:00.0 enp3s0: Link is up at 100 Mbps, full duplex Nov 15 23:51:00 localhost vmunix: [ 135.760478] tg3 0000:03:00.0 enp3s0: Flow control is on for TX and on for RX Nov 15 23:51:00 localhost vmunix: [ 135.760598] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route fe80:: gw :: scope 0 <UNIVERSE> Nov 15 23:51:00 localhost connmand[210]: enp3s0 {RX} 24 packets 3438 bytes Nov 15 23:51:00 localhost connmand[210]: enp3s0 {TX} 31 packets 3795 bytes Nov 15 23:51:00 localhost connmand[210]: enp3s0 {update} flags 102467 <UP,RUNNING,LOWER_UP> Nov 15 23:51:00 localhost connmand[210]: enp3s0 {newlink} index 2 address 10:9A:DD:46:4F:9F mtu 1500 Nov 15 23:51:00 localhost connmand[210]: enp3s0 {newlink} index 2 operstate 6 <UP> Nov 15 23:51:00 localhost connmand[210]: Setting domainname to fritz.box Nov 15 23:51:00 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} address 192.168.178.74/24 label enp3s0 family 2 Nov 15 23:51:00 localhost connmand[210]: ntp: adjust (slew): +0.137667 sec Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route 192.168.178.0 gw 0.0.0.0 scope 253 <LINK> Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route 192.168.178.1 gw 0.0.0.0 scope 253 <LINK> Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route 0.0.0.0 gw 192.168.178.1 scope 0 <UNIVERSE> Nov 15 23:51:00 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to Nov 15 23:51:00 localhost last message repeated 5 times Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route 212.227.81.55 gw 192.168.178.1 scope 0 <UNIVERSE> Nov 15 23:51:01 localhost connmand[210]: enp3s0 {del} route 212.227.81.55 gw 192.168.178.1 scope 0 <UNIVERSE> Nov 15 23:51:01 localhost installer[259]: running step 'select-technology' Nov 15 23:51:01 localhost installer[259]: running step 'power-technology' Nov 15 23:51:02 localhost connmand[210]: enp3s0 {add} route fd00:: gw :: scope 0 <UNIVERSE> Nov 15 23:51:02 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to Nov 15 23:51:02 localhost installer[259]: running step 'connect-service' Nov 15 23:51:03 localhost installer[259]: running step 'wait-online' Nov 15 23:51:04 localhost installer[259]: running step 'user' Nov 15 23:51:04 localhost installer[259]: running form #<newt-form 857f70> ("System administrator password") with 0 clients Nov 15 23:51:04 localhost connmand[210]: enp3s0 {add} address fd00::129a:ddff:fe46:4f9f/64 label (null) family 10 Nov 15 23:51:04 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to Nov 15 23:51:04 localhost last message repeated 5 times Nov 15 23:51:15 localhost installer[259]: running form #<newt-form 85c870> ("Password confirmation required") with 0 clients Nov 15 23:51:23 localhost installer[259]: running form #<newt-form 85c820> (add-users) with 0 clients Nov 15 23:51:45 localhost installer[259]: running form #<newt-form 859770> ("Password confirmation required") with 0 clients Nov 15 23:51:54 localhost installer[259]: running form #<newt-form 858770> (add-users) with 0 clients Nov 15 23:51:55 localhost installer[259]: running step 'services' Nov 15 23:51:55 localhost installer[259]: running form #<newt-form 859480> ("Desktop environment") with 0 clients Nov 15 23:52:01 localhost installer[259]: running form #<newt-form 8594d0> ("Network service") with 0 clients Nov 15 23:52:02 localhost installer[259]: running step 'partition' Nov 15 23:52:04 localhost vmunix: [ 199.938163] sda: sda1 sda2 sda3 sda4 sda5 sda7 Nov 15 23:52:04 localhost vmunix: [ 200.195324] sdc: sdc2 Nov 15 23:52:04 localhost installer[259]: running form #<newt-form 8592a0> ("Partitioning method") with 0 clients Nov 15 23:52:08 localhost installer[259]: running form #<newt-form 8594d0> ("Manual partitioning") with 0 clients Nov 15 23:52:08 localhost vmunix: [ 203.706965] sda: sda1 sda2 sda3 sda4 sda5 sda7 Nov 15 23:52:08 localhost vmunix: [ 203.715838] sdc: sdc2 Nov 15 23:52:12 localhost installer[259]: running form #<newt-form 859910> ("Partition edit") with 0 clients Nov 15 23:52:15 localhost installer[259]: running form #<newt-form 86f5f0> ("Encryption label") with 0 clients Nov 15 23:52:24 localhost installer[259]: running form #<newt-form 86ee10> ("Partition edit") with 0 clients Nov 15 23:52:26 localhost installer[259]: running form #<newt-form 864610> ("Mounting point") with 0 clients Nov 15 23:52:28 localhost installer[259]: running form #<newt-form 8643a0> ("Partition edit") with 0 clients Nov 15 23:52:30 localhost installer[259]: running form #<newt-form 864450> ("Manual partitioning") with 0 clients Nov 15 23:52:33 localhost installer[259]: running form #<newt-form 86f730> ("Password required") with 0 clients Nov 15 23:52:45 localhost installer[259]: running form #<newt-form 870810> ("Password confirmation required") with 0 clients Nov 15 23:52:55 localhost installer[259]: running form #<newt-form 8643a0> ("Format disk?") with 0 clients Nov 15 23:53:01 localhost vmunix: [ 257.244569] sdc: sdc2 Nov 15 23:53:03 localhost installer[259]: crashing due to uncaught exception: misc-error (#f "~A" ("Device /dev/sda is still in use.") #f) Nov 15 23:53:03 localhost installer[259]: running form #<newt-form 865370> ("Unexpected problem") with 0 clients I assume some formatting step had not completed in time. Regards, Florian ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-15 23:16 ` pelzflorian (Florian Pelz) @ 2020-11-16 9:12 ` Mathieu Othacehe 2020-11-16 11:47 ` pelzflorian (Florian Pelz) ` (2 more replies) 2020-11-16 15:39 ` Miguel Ángel Arruga Vivas 1 sibling, 3 replies; 26+ messages in thread From: Mathieu Othacehe @ 2020-11-16 9:12 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 825 bytes --] Hello Florian, > Nov 15 23:53:03 localhost installer[259]: crashing due to uncaught exception: misc-error (#f "~A" ("Device /dev/sda is still in use.") #f) > Nov 15 23:53:03 localhost installer[259]: running form #<newt-form 865370> ("Unexpected problem") with 0 clients Many thanks (again) for your help here! According to the backtrace you sent earlier in this thread, it looks like the crash occurs in the "free-parted" procedure. This procedure tries to unallocate Parted resources and waits for the partition table changes to be synchronized to disk. The "with-delay-device-in-use?" tries 4 times every 250ms to detect if the device is still in use. Maybe it takes longer on your HW to synchronize the partition tables. If you could test the attached patch on top of 1.2.0 it would be terrific. Thanks, Mathieu [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Increase-device-use-delay.patch --] [-- Type: text/x-diff, Size: 908 bytes --] From 6fec27303d0f8767ed48c507af67908a0fcf17a0 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe <othacehe@gnu.org> Date: Mon, 16 Nov 2020 10:10:56 +0100 Subject: [PATCH] Increase device use delay. --- gnu/installer/parted.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnu/installer/parted.scm b/gnu/installer/parted.scm index f2352c5779..ed3af6af85 100644 --- a/gnu/installer/parted.scm +++ b/gnu/installer/parted.scm @@ -318,7 +318,7 @@ PARTED-OBJECT field equals PARTITION, return #f if not found." fail. See rereadpt function in wipefs.c of util-linux for an explanation." ;; Kernel always return EINVAL for BLKRRPART on loopdevices. (and (not (string-match "/dev/loop*" file-name)) - (let loop ((try 4)) + (let loop ((try 16)) (usleep 250000) (let ((in-use? (device-in-use? file-name))) (if (and in-use? (> try 0)) -- 2.29.2 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-16 9:12 ` Mathieu Othacehe @ 2020-11-16 11:47 ` pelzflorian (Florian Pelz) 2020-11-17 9:02 ` Mathieu Othacehe 2020-11-16 15:49 ` Miguel Ángel Arruga Vivas 2020-11-17 9:30 ` Ludovic Courtès 2 siblings, 1 reply; 26+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-11-16 11:47 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: guix-devel On Mon, Nov 16, 2020 at 10:12:09AM +0100, Mathieu Othacehe wrote: > Many thanks (again) for your help here! According to the backtrace you > sent earlier in this thread, it looks like the crash occurs in the > "free-parted" procedure. > > This procedure tries to unallocate Parted resources and waits for the > partition table changes to be synchronized to disk. The > "with-delay-device-in-use?" tries 4 times every 250ms to detect if the > device is still in use. > > Maybe it takes longer on your HW to synchronize the partition tables. If > you could test the attached patch on top of 1.2.0 it would be terrific. > > Thanks, > > Mathieu Thank you for the quick patch! Clearly you have been spot-on. “Partition formatting is in progress, please wait” is displayed considerably longer but eventually succeeds. I tried 3 times successfully with your patch. I tried again without your patch and it failed. I tried once more with your patch and formatting succeeded again. (Install failed due to a loss of network connectivity and restarting is impossible, but that is less important, normally all works.) Regards, Florian ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-16 11:47 ` pelzflorian (Florian Pelz) @ 2020-11-17 9:02 ` Mathieu Othacehe 2020-11-17 12:13 ` pelzflorian (Florian Pelz) 0 siblings, 1 reply; 26+ messages in thread From: Mathieu Othacehe @ 2020-11-17 9:02 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 696 bytes --] Hello Florian, > Thank you for the quick patch! Clearly you have been spot-on. > “Partition formatting is in progress, please wait” is displayed > considerably longer but eventually succeeds. I tried 3 times > successfully with your patch. I tried again without your patch and it > failed. I tried once more with your patch and formatting succeeded > again. That's good news! Here's a more complete patch that I intend to push on the 1.2.0 branch. It logs the time spent waiting for disk synchronization. It would be great if you could test it one more time, so that we know if 4 seconds is enough or if we should use an even higher delay. Thanks again, Mathieu [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-installer-Fix-device-synchronization.patch --] [-- Type: text/x-diff, Size: 4887 bytes --] From f3d41cff6704ad748d51e4dd548c045034656b66 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe <othacehe@gnu.org> Date: Tue, 17 Nov 2020 09:50:01 +0100 Subject: [PATCH] installer: Fix device synchronization. Reported by Florian Pelz: https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00326.html. * gnu/installer/utils.scm (call-with-time): New procedure, (let/time): new macro. * gnu/installer/parted.scm (with-delay-device-in-use?): Increase the retry count to 16. (non-install-devices): Remove the call to with-delay-device-in-use? as it doesn't return the expected result, and would block much longer now. (free-parted): Log the time required to sync each device. --- gnu/installer/parted.scm | 27 ++++++++++++++------------- gnu/installer/utils.scm | 14 ++++++++++++++ 2 files changed, 28 insertions(+), 13 deletions(-) diff --git a/gnu/installer/parted.scm b/gnu/installer/parted.scm index f2352c5779..3ad1721795 100644 --- a/gnu/installer/parted.scm +++ b/gnu/installer/parted.scm @@ -41,6 +41,7 @@ #:use-module (ice-9 regex) #:use-module (rnrs io ports) #:use-module (srfi srfi-1) + #:use-module (srfi srfi-19) #:use-module (srfi srfi-26) #:use-module (srfi srfi-34) #:use-module (srfi srfi-35) @@ -318,7 +319,7 @@ PARTED-OBJECT field equals PARTITION, return #f if not found." fail. See rereadpt function in wipefs.c of util-linux for an explanation." ;; Kernel always return EINVAL for BLKRRPART on loopdevices. (and (not (string-match "/dev/loop*" file-name)) - (let loop ((try 4)) + (let loop ((try 16)) (usleep 250000) (let ((in-use? (device-in-use? file-name))) (if (and in-use? (> try 0)) @@ -339,15 +340,12 @@ fail. See rereadpt function in wipefs.c of util-linux for an explanation." (define (non-install-devices) "Return all the available devices, except the busy one, allegedly the install device. DEVICE-IS-BUSY? is a parted call, checking if the device is -mounted. The install image uses an overlayfs so the install device does not -appear as mounted and won't be considered as busy. So use also DEVICE-IN-USE? -from (guix build syscalls) module, who will try to re-read the device's -partition table to determine whether or not it is already used (like sfdisk -from util-linux)." +mounted." + ;; FIXME: The install image uses an overlayfs so the install device does not + ;; appear as mounted and won't be considered as busy. (remove (lambda (device) (let ((file-name (device-path device))) - (or (device-is-busy? device) - (with-delay-device-in-use? file-name)))) + (device-is-busy? device))) (devices))) \f @@ -1368,9 +1366,12 @@ the devices not to be used before returning." (let ((device-file-names (map device-path devices))) (for-each force-device-sync devices) (for-each (lambda (file-name) - (let ((in-use? (with-delay-device-in-use? file-name))) - (and in-use? - (error - (format #f (G_ "Device ~a is still in use.") - file-name))))) + (let/time ((time in-use? + (with-delay-device-in-use? file-name))) + (if in-use? + (error + (format #f (G_ "Device ~a is still in use.") + file-name)) + (syslog "Syncing ~a took ~a seconds.~%" + file-name (time-second time))))) device-file-names))) diff --git a/gnu/installer/utils.scm b/gnu/installer/utils.scm index 5f8fe8ca01..a7fa66a199 100644 --- a/gnu/installer/utils.scm +++ b/gnu/installer/utils.scm @@ -22,6 +22,7 @@ #:use-module (guix build utils) #:use-module (guix i18n) #:use-module (srfi srfi-1) + #:use-module (srfi srfi-19) #:use-module (srfi srfi-34) #:use-module (ice-9 match) #:use-module (ice-9 rdelim) @@ -36,6 +37,8 @@ syslog-port syslog + call-with-time + let/time with-server-socket current-server-socket @@ -117,6 +120,17 @@ COMMAND exited successfully, #f otherwise." ;;; Logging. ;;; +(define (call-with-time thunk kont) + "Call THUNK and pass KONT the elapsed time followed by THUNK's return +values." + (let* ((start (current-time time-monotonic)) + (result (call-with-values thunk list)) + (end (current-time time-monotonic))) + (apply kont (time-difference end start) result))) + +(define-syntax-rule (let/time ((time result exp)) body ...) + (call-with-time (lambda () exp) (lambda (time result) body ...))) + (define (open-syslog-port) "Return an open port (a socket) to /dev/log or #f if that wasn't possible." (let ((sock (socket AF_UNIX SOCK_DGRAM 0))) -- 2.29.2 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 9:02 ` Mathieu Othacehe @ 2020-11-17 12:13 ` pelzflorian (Florian Pelz) 0 siblings, 0 replies; 26+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-11-17 12:13 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: guix-devel On Tue, Nov 17, 2020 at 10:02:33AM +0100, Mathieu Othacehe wrote: > That's good news! Here's a more complete patch that I intend to push on > the 1.2.0 branch. It logs the time spent waiting for disk > synchronization. > > It would be great if you could test it one more time, so that we know if > 4 seconds is enough or if we should use an even higher delay. > > Thanks again, > > Mathieu It succeeded three times in a row. Regards, Florian ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-16 9:12 ` Mathieu Othacehe 2020-11-16 11:47 ` pelzflorian (Florian Pelz) @ 2020-11-16 15:49 ` Miguel Ángel Arruga Vivas 2020-11-17 9:06 ` Mathieu Othacehe 2020-11-17 9:30 ` Ludovic Courtès 2 siblings, 1 reply; 26+ messages in thread From: Miguel Ángel Arruga Vivas @ 2020-11-16 15:49 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: guix-devel Hi, I didn't update my mail so often and you've already solved it... Sorry for the noise and thank you for the patch. :-) Happy hacking! Miguel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-16 15:49 ` Miguel Ángel Arruga Vivas @ 2020-11-17 9:06 ` Mathieu Othacehe 0 siblings, 0 replies; 26+ messages in thread From: Mathieu Othacehe @ 2020-11-17 9:06 UTC (permalink / raw) To: Miguel Ángel Arruga Vivas; +Cc: guix-devel Hello Miguel, > I didn't update my mail so often and you've already solved it... Sorry > for the noise and thank you for the patch. :-) Thanks for having a look to this :). I sent an updated patch because the first one could cause a regression in "non-install-devices" procedure I think. This procedure tries to find the install device by checking which devices are busy using "with-delay-device-in-use?". Turns out it doesn't work for me, plus it would now took a longer time if the delay is higher. In the updated patch, I removed the "with-delay-device-in-use?" call from "non-install-devices", adding a note saying that it would be nice to fix this procedure anyway. What do you think about that? Thanks, Mathieu ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-16 9:12 ` Mathieu Othacehe 2020-11-16 11:47 ` pelzflorian (Florian Pelz) 2020-11-16 15:49 ` Miguel Ángel Arruga Vivas @ 2020-11-17 9:30 ` Ludovic Courtès 2020-11-17 9:38 ` Mathieu Othacehe 2 siblings, 1 reply; 26+ messages in thread From: Ludovic Courtès @ 2020-11-17 9:30 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: guix-devel Hi Mathieu, Mathieu Othacehe <othacehe@gnu.org> skribis: > From 6fec27303d0f8767ed48c507af67908a0fcf17a0 Mon Sep 17 00:00:00 2001 > From: Mathieu Othacehe <othacehe@gnu.org> > Date: Mon, 16 Nov 2020 10:10:56 +0100 > Subject: [PATCH] Increase device use delay. > > --- > gnu/installer/parted.scm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gnu/installer/parted.scm b/gnu/installer/parted.scm > index f2352c5779..ed3af6af85 100644 > --- a/gnu/installer/parted.scm > +++ b/gnu/installer/parted.scm > @@ -318,7 +318,7 @@ PARTED-OBJECT field equals PARTITION, return #f if not found." > fail. See rereadpt function in wipefs.c of util-linux for an explanation." > ;; Kernel always return EINVAL for BLKRRPART on loopdevices. > (and (not (string-match "/dev/loop*" file-name)) > - (let loop ((try 4)) > + (let loop ((try 16)) > (usleep 250000) > (let ((in-use? (device-in-use? file-name))) > (if (and in-use? (> try 0)) Should we go ahead and apply this one? Not polling would be nicer, but maybe there’s no real way to do that? BTW: (string-match "/dev/loop*" file-name) should almost certainly be: (string-prefix? "/dev/loop" file-name) The regexp above would match “/dev/loo”, “qux/dev/looppppppppabc”, etc. WDYT? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 9:30 ` Ludovic Courtès @ 2020-11-17 9:38 ` Mathieu Othacehe 2020-11-17 14:41 ` Ludovic Courtès 0 siblings, 1 reply; 26+ messages in thread From: Mathieu Othacehe @ 2020-11-17 9:38 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel Hey Ludo, > Should we go ahead and apply this one? Not polling would be nicer, but > maybe there’s no real way to do that? I proposed a variant of this patch a few minutes ago. I added some time logging and I would like to see what's the result on Florian machine to see if the new delay is large enough. > BTW: > > (string-match "/dev/loop*" file-name) > > should almost certainly be: > > (string-prefix? "/dev/loop" file-name) > > The regexp above would match “/dev/loo”, “qux/dev/looppppppppabc”, etc. Oh you're right, I'll fix it. Thanks, Mathieu ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 9:38 ` Mathieu Othacehe @ 2020-11-17 14:41 ` Ludovic Courtès 2020-11-17 15:26 ` zimoun ` (3 more replies) 0 siblings, 4 replies; 26+ messages in thread From: Ludovic Courtès @ 2020-11-17 14:41 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: guix-devel Hi, Mathieu Othacehe <othacehe@gnu.org> skribis: >> Should we go ahead and apply this one? Not polling would be nicer, but >> maybe there’s no real way to do that? > > I proposed a variant of this patch a few minutes ago. I added some time > logging and I would like to see what's the result on Florian machine to > see if the new delay is large enough. Awesome. One this patch is in, I think we’re ready for either an RC2 or the real thing. WDYT? Ludo’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 14:41 ` Ludovic Courtès @ 2020-11-17 15:26 ` zimoun 2020-11-17 21:19 ` Ludovic Courtès 2020-11-17 15:41 ` pelzflorian (Florian Pelz) ` (2 subsequent siblings) 3 siblings, 1 reply; 26+ messages in thread From: zimoun @ 2020-11-17 15:26 UTC (permalink / raw) To: Ludovic Courtès, Mathieu Othacehe; +Cc: guix-devel Hi, On Tue, 17 Nov 2020 at 15:41, Ludovic Courtès <ludo@gnu.org> wrote: > Mathieu Othacehe <othacehe@gnu.org> skribis: > >>> Should we go ahead and apply this one? Not polling would be nicer, but >>> maybe there’s no real way to do that? >> >> I proposed a variant of this patch a few minutes ago. I added some time >> logging and I would like to see what's the result on Florian machine to >> see if the new delay is large enough. > > Awesome. > > One this patch is in, I think we’re ready for either an RC2 or the real > thing. Real thing potential means “1.0.1” troubles. On the other hand, I will not have time to test more. So… :-) BTW, I am failing with Docker [1,2]. And aside, skopeo (the tool that avoid the duplication of the image) seems broken. Therefore, provide an experimental Docker image should be postponed to the next release. 1: <https://yhetil.org/guix-devel/86pn4esca3.fsf@gmail.com> 2: <https://yhetil.org/guix-devel/86k0ums3xw.fsf@gmail.com> All the best, simon ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 15:26 ` zimoun @ 2020-11-17 21:19 ` Ludovic Courtès 0 siblings, 0 replies; 26+ messages in thread From: Ludovic Courtès @ 2020-11-17 21:19 UTC (permalink / raw) To: zimoun; +Cc: guix-devel, Mathieu Othacehe Hi, zimoun <zimon.toutoune@gmail.com> skribis: > BTW, I am failing with Docker [1,2]. And aside, skopeo (the tool that > avoid the duplication of the image) seems broken. Therefore, provide an > experimental Docker image should be postponed to the next release. Yes, that was my understanding. Ludo’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 14:41 ` Ludovic Courtès 2020-11-17 15:26 ` zimoun @ 2020-11-17 15:41 ` pelzflorian (Florian Pelz) 2020-11-17 18:13 ` Mathieu Othacehe 2020-11-17 23:12 ` Mark H Weaver 3 siblings, 0 replies; 26+ messages in thread From: pelzflorian (Florian Pelz) @ 2020-11-17 15:41 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, Mathieu Othacehe On Tue, Nov 17, 2020 at 03:41:34PM +0100, Ludovic Courtès wrote: > One this patch is in, I think we’re ready for either an RC2 or the real > thing. > > WDYT? > > Ludo’. With the patch I see no problems on x86_64 Guix system, install script or VM, but I have no idea of current Guix bugs. Regards, Florian ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 14:41 ` Ludovic Courtès 2020-11-17 15:26 ` zimoun 2020-11-17 15:41 ` pelzflorian (Florian Pelz) @ 2020-11-17 18:13 ` Mathieu Othacehe 2020-11-25 18:26 ` Tobias Platen 2020-11-17 23:12 ` Mark H Weaver 3 siblings, 1 reply; 26+ messages in thread From: Mathieu Othacehe @ 2020-11-17 18:13 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel Hey, > One this patch is in, I think we’re ready for either an RC2 or the real > thing. Pushed to 1.2.0 and master. Thanks Florian for all the testing! No objections to make the rc2 the final one. Thanks, Mathieu ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 18:13 ` Mathieu Othacehe @ 2020-11-25 18:26 ` Tobias Platen 2020-11-27 10:10 ` Ludovic Courtès 0 siblings, 1 reply; 26+ messages in thread From: Tobias Platen @ 2020-11-25 18:26 UTC (permalink / raw) To: guix-devel On Tue, 17 Nov 2020 19:13:28 +0100 Mathieu Othacehe <othacehe@gnu.org> wrote: Just saw that GNU Guix 1.2.0 released was recently released. In the Ode to 1.2.0 the back vocals are done by Festival (likely singing-mode.scm). Can I have the XML file that that was given to Festival. > > Hey, > > > One this patch is in, I think we’re ready for either an RC2 or the real > > thing. > > Pushed to 1.2.0 and master. Thanks Florian for all the testing! > > No objections to make the rc2 the final one. > > Thanks, > > Mathieu > -- Tobias Platen <guix@platen-software.de> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-25 18:26 ` Tobias Platen @ 2020-11-27 10:10 ` Ludovic Courtès 2020-11-27 11:09 ` Ricardo Wurmus 0 siblings, 1 reply; 26+ messages in thread From: Ludovic Courtès @ 2020-11-27 10:10 UTC (permalink / raw) To: Tobias Platen; +Cc: guix-devel Hi Tobias, Tobias Platen <guix@platen-software.de> skribis: > Just saw that GNU Guix 1.2.0 released was recently released. > In the Ode to 1.2.0 the back vocals are done by Festival (likely singing-mode.scm). > Can I have the XML file that that was given to Festival. That’s a question for Ricardo. Do not miss Ricardo’s excellent writeup on that story: https://guix.gnu.org/en/blog/2020/music-production-on-guix-system/ It’s entertaining and yet is a great demonstration of what can be achieved with free software and dedication. Ludo’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-27 10:10 ` Ludovic Courtès @ 2020-11-27 11:09 ` Ricardo Wurmus 0 siblings, 0 replies; 26+ messages in thread From: Ricardo Wurmus @ 2020-11-27 11:09 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel Hello there, Ludovic Courtès <ludo@gnu.org> writes: > Tobias Platen <guix@platen-software.de> skribis: > >> Just saw that GNU Guix 1.2.0 released was recently released. >> In the Ode to 1.2.0 the back vocals are done by Festival (likely singing-mode.scm). >> Can I have the XML file that that was given to Festival. > > That’s a question for Ricardo. I didn’t give it any XML file, but I can share my ~/.festivalrc: --8<---------------cut here---------------start------------->8--- (Parameter.set 'Audio_Method 'Audio_Command) ;; This is "play" from the "sox" package. (Parameter.set 'Audio_Command "play -q -t snd $FILE") (Parameter.set 'Audio_Required_Format 'snd) (Parameter.set 'Audio_Required_Rate 24000) ;; Alternatively, after "modprobe snd-pcm-oss" this would work: ;;(Parameter.set 'Audio_Method 'linux16audio) ;;(Parameter.set 'Audio_Device "/dev/dsp1") (set! voice-path (cons "/home/rekado/vox/festival/lib/voices" voice-path)) (require 'voices) ;; Print all voices that have been found (set! voice-location-trace t) (search-for-voices) (set! voice_default 'voice_cmu_us_fem_cg) --8<---------------cut here---------------end--------------->8--- You may need to download the cmu_us_fem_cg voice data set from the Festival website first. I don’t think it’s included in the output of the Festival installation in Guix. With the lyrics in “poem.txt” you can then do: text2wave -otype snd -o poem.wav poem.txt I then chopped it up in Ardour to align individual chunks to the beat by hand, applied some detuning with GxDetune (that’s why it sounds a little like the Borg), and that’s pretty much it. I added all these effects to distract from the big quality difference that results from the low sampling frequency of the generated file (I use 48kHz as the working sampling frequency for all my audio projects). I intend to publish more source files (e.g. Hydrogen patterns, Ardour session file, etc) on my blog within the next month or so, perhaps even including a Lilypond score (the output of the file I used had been modified so much that I don’t think publishing it as is will be useful to anyone). -- Ricardo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-17 14:41 ` Ludovic Courtès ` (2 preceding siblings ...) 2020-11-17 18:13 ` Mathieu Othacehe @ 2020-11-17 23:12 ` Mark H Weaver 3 siblings, 0 replies; 26+ messages in thread From: Mark H Weaver @ 2020-11-17 23:12 UTC (permalink / raw) To: Ludovic Courtès, Mathieu Othacehe; +Cc: guix-devel Ludovic Courtès <ludo@gnu.org> writes: > One this patch is in, I think we’re ready for either an RC2 or the real > thing. > > WDYT? FYI, within 8 hours I expect to push the IceCat 78.5 security update, in case you'd like that to be in 1.2.0, but perhaps it doesn't matter much. Regards, Mark ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-15 23:16 ` pelzflorian (Florian Pelz) 2020-11-16 9:12 ` Mathieu Othacehe @ 2020-11-16 15:39 ` Miguel Ángel Arruga Vivas 1 sibling, 0 replies; 26+ messages in thread From: Miguel Ángel Arruga Vivas @ 2020-11-16 15:39 UTC (permalink / raw) To: pelzflorian (Florian Pelz); +Cc: guix-devel, Mathieu Othacehe Hallo, Leute! "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes: > On Sun, Nov 15, 2020 at 10:53:29PM +0100, Marius Bakke wrote: >> I have just installed a system using manual partitioning through the >> installer, with encryption. Everything worked like a charm. [...] > Maybe it depends on how fast the machine completes a formatting task? > So I tried again two more times and it failed again, I got the error > again both times during partition formatting. [...] > I assume some formatting step had not completed in time. From your log, the format didn't even took place, as it is the following step from run-partitioning-page (at gnu/installer/newt/partition.scm), but it was writing the partitions to the disk. I think this comment from free-parted (at gnu/installer/parted.scm) tells the same problem you're hitting: ----------------------------------8<-------------------------------------- ;; XXX: Formatting and further operations on disk partition table may fail ;; because the partition table changes are not synced, or because the device ;; is still in use, even if parted should have finished editing ;; partitions. This is not well understood, but syncing devices and waiting ;; them to stop returning EBUSY to BLKRRPART ioctl seems to be enough. The ;; same kind of issue is described here: ;; https://mail.gnome.org/archives/commits-list/2013-March/msg18423.html. ---------------------------------->8-------------------------------------- Nonetheless, we're only waiting 1 second + processing time to timeout the lookup for EBUSY at 'with-delay-device-in-use?'. Should we extend that timeout? I don't think waiting even minutes at this stage would be a big issue, as formatting an encrypted partition may take hours and will be performed just after that. WDYT? Happy hacking! Miguel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-13 17:07 GNU Guix 1.2.0rc1 available for testing! Ludovic Courtès 2020-11-15 16:19 ` zimoun 2020-11-15 19:16 ` pelzflorian (Florian Pelz) @ 2020-11-16 0:10 ` Oleg Pykhalov 2020-11-16 9:06 ` Ludovic Courtès 2 siblings, 1 reply; 26+ messages in thread From: Oleg Pykhalov @ 2020-11-16 0:10 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 1495 bytes --] Hello, Yeeeho! I've installed Guix 1.2.0rc1 system on a KVM virtual machine. 1. Because of DHCP server is not exist on a network I cannot use TUI installer. When I installed via shell, I need manually stop “networking” service with herd. Otherwise “ip address” shows “169.254.182.22/16” assigned to “eht0” and “ip route” shows “default dev eth0 scope link” which breaks a network on automatically before “guix system init”. 2. “emacs-guix” is broken out of the box, because of incompatible “geiser”. On my machine I have a dirty hack with “module-set!”, but I assume we could specify “emacs-geiser-0.10” in “propagated-inputs” until somebody have a fix :-) , but it will trigger errors if you will want to install “emacs-geiser” in the same profile AFAIK. --8<---------------cut here---------------start------------->8--- (define-public emacs-geiser-0.10 (package (inherit emacs-geiser) (version "0.10") (source (origin (method url-fetch) (uri (string-append "mirror://savannah/geiser/" version "/geiser-" version ".tar.gz")) (sha256 (base32 "0pj3l7p8d60c9b4vfprnv6g5l61d74pls4b5dvd84cn4ky9mzwjv")))))) (module-set! (resolve-module '(gnu packages emacs-xyz)) 'emacs-geiser emacs-geiser-0.10) --8<---------------cut here---------------end--------------->8--- Regardless, Oleg. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 861 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-16 0:10 ` Oleg Pykhalov @ 2020-11-16 9:06 ` Ludovic Courtès 2020-11-16 16:24 ` John Soo 0 siblings, 1 reply; 26+ messages in thread From: Ludovic Courtès @ 2020-11-16 9:06 UTC (permalink / raw) To: Oleg Pykhalov; +Cc: guix-devel Hi Oleg, Oleg Pykhalov <go.wigust@gmail.com> skribis: > Yeeeho! I've installed Guix 1.2.0rc1 system on a KVM virtual machine. Yay! > 1. Because of DHCP server is not exist on a network I cannot use TUI > installer. Right, it very much assumes DHCP. > When I installed via shell, I need manually stop “networking” service > with herd. Otherwise “ip address” shows “169.254.182.22/16” assigned to > “eht0” and “ip route” shows “default dev eth0 scope link” which breaks a > network on automatically before “guix system init”. OK. > 2. “emacs-guix” is broken out of the box, because of incompatible > “geiser”. On my machine I have a dirty hack with “module-set!”, but I > assume we could specify “emacs-geiser-0.10” in “propagated-inputs” until > somebody have a fix :-) , but it will trigger errors if you will want to > install “emacs-geiser” in the same profile AFAIK. > > (define-public emacs-geiser-0.10 > (package > (inherit emacs-geiser) > (version "0.10") > (source (origin > (method url-fetch) > (uri (string-append "mirror://savannah/geiser/" version > "/geiser-" version ".tar.gz")) > (sha256 > (base32 > "0pj3l7p8d60c9b4vfprnv6g5l61d74pls4b5dvd84cn4ky9mzwjv")))))) > > (module-set! (resolve-module '(gnu packages emacs-xyz)) 'emacs-geiser emacs-geiser-0.10) It would be nice to include a fix, either a patch or explicitly depending on the previous Geiser version. (Cc: John Soo who might have suggestions.) Thanks! Ludo’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: GNU Guix 1.2.0rc1 available for testing! 2020-11-16 9:06 ` Ludovic Courtès @ 2020-11-16 16:24 ` John Soo 0 siblings, 0 replies; 26+ messages in thread From: John Soo @ 2020-11-16 16:24 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix-Devel [-- Attachment #1: Type: text/plain, Size: 193 bytes --] Hello, I have a fix for emacs-guix. Once I make the repository on savannah, that patch should be easy to make. I may be able to get to that around Wednesday. - John [-- Attachment #2: Type: text/html, Size: 353 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2020-11-27 11:07 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-11-13 17:07 GNU Guix 1.2.0rc1 available for testing! Ludovic Courtès 2020-11-15 16:19 ` zimoun 2020-11-15 19:16 ` pelzflorian (Florian Pelz) 2020-11-15 21:53 ` Marius Bakke 2020-11-15 23:16 ` pelzflorian (Florian Pelz) 2020-11-16 9:12 ` Mathieu Othacehe 2020-11-16 11:47 ` pelzflorian (Florian Pelz) 2020-11-17 9:02 ` Mathieu Othacehe 2020-11-17 12:13 ` pelzflorian (Florian Pelz) 2020-11-16 15:49 ` Miguel Ángel Arruga Vivas 2020-11-17 9:06 ` Mathieu Othacehe 2020-11-17 9:30 ` Ludovic Courtès 2020-11-17 9:38 ` Mathieu Othacehe 2020-11-17 14:41 ` Ludovic Courtès 2020-11-17 15:26 ` zimoun 2020-11-17 21:19 ` Ludovic Courtès 2020-11-17 15:41 ` pelzflorian (Florian Pelz) 2020-11-17 18:13 ` Mathieu Othacehe 2020-11-25 18:26 ` Tobias Platen 2020-11-27 10:10 ` Ludovic Courtès 2020-11-27 11:09 ` Ricardo Wurmus 2020-11-17 23:12 ` Mark H Weaver 2020-11-16 15:39 ` Miguel Ángel Arruga Vivas 2020-11-16 0:10 ` Oleg Pykhalov 2020-11-16 9:06 ` Ludovic Courtès 2020-11-16 16:24 ` John Soo
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).