bug#48974: A possible shepherd bug (it's very minor)
June 12, 2021 5:13 PM, "Leo Prikler" wrote: > Hi, > > Am Samstag, den 12.06.2021, 20:09 + schrieb jbra...@dismail.de: > >> June 12, 2021 3:39 PM, "Leo Prikler" >> wrote: >> >> Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson: >> > > I'm pretty sure that the actual bug also exists, just not sure whether > that's on your config or on shepherd. Using TTY1 for graphical stuff > is also somewhat rare in Guix land, I presume. (Or rather, I can't > think of it as anything but a container for debug output spam :D) So...whay tty should I auto login to start my sway session? tty2? tty3? > > As for getting this to work only on TTY1, you do get the config object, > so you can do stuff like > (if (is-tty1? config) (inherit+autologin config) config) > Note of course, that is-tty1? is not a procedure that's ready-made, but > one that you'd need to build from primitives such as record accessors. Thanks! > > Regards, > Leo
bug#44872: Installer crash: 'uuid->string' is passed #f in lieu of a UUID
Hey Mathieu! Mathieu Othacehe writes: > I improved the install device detection with > 154a4e046281c28e39b5016e965d3d937a2ea4a1 by removing the device with the > default Guix System image ISO label. Works perfectly for me now, the USB installation device doesn't show up in the device list anymore! I've installed Guix about 5 times after building an image from the latest changes, works perfectly for me both with encrypted and unencrypted root partitions. Thanks a lot for your help! David
bug#48974: A possible shepherd bug (it's very minor)
Hi, Am Samstag, den 12.06.2021, 20:09 + schrieb jbra...@dismail.de: > June 12, 2021 3:39 PM, "Leo Prikler" > wrote: > > > Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson: > > > > > Hello! > > > > > > I've had this issue every since I enabled automatic login on my > > > guix > > > system like so: > > > > > > #+BEGIN_SRC scheme > > > (define %my-desktop-services > > > (modify-services > > > %desktop-services > > > (mingetty-service-type config => > > > (mingetty-configuration > > > (inherit config) > > > ;;auto login as joshua > > > (auto-login "joshua") > > > > > > (operating-system > > > ... > > > (services (list %my-desktop-services))) > > > #+END_SRC > > > > I am sorry to say this, but rather than this being (just) a bug > > with > > Thank you for speaking so gently! :) > > > shepherd, your config looks seriously borked. Why are you asking > > Guix > > to autologin you on *every available console*? > > HAHAHA! That's what I'm doing! I forgot that! Honestly, I did that, > because I > couldn't figure out how to code "just auto log into console 1 ONLY". > :) > > Would you mind explaining how bad of a decision this is? Is this a > BAD security practice? It is seriously bad practice. With just one TTY, you can usually suspend it with programs such as vlock, plus it's expected that you actually sit in front of the given TTY when the autologin happens. With all TTYs though, anyone could switch to the other and "lol, now I'm jbranso". The only configuration, that could possibly be worse is autologin root :P (Granted, it probably still takes physical access to exploit, but it's something your family/friends could likely do just to troll you.) > I'll tell you what, why don't we leave this "bug" open for a > week...I'll try to write > the code that does what I want, and I'll email the answer. > > Then I'll edit the manual to provide an example! I'm pretty sure that the actual bug also exists, just not sure whether that's on your config or on shepherd. Using TTY1 for graphical stuff is also somewhat rare in Guix land, I presume. (Or rather, I can't think of it as anything but a container for debug output spam :D) As for getting this to work only on TTY1, you do get the config object, so you can do stuff like (if (is-tty1? config) (inherit+autologin config) config) Note of course, that is-tty1? is not a procedure that's ready-made, but one that you'd need to build from primitives such as record accessors. Regards, Leo
bug#48973: An early booting warning message
June 12, 2021 11:46 AM, "Tobias Geerinckx-Rice" wrote: > This is a cross-distro annoyance; Guix doesn't explicitly load or even > mention pcspkr. > > One very common work-around is > > (kernel-arguments (list "modprobe.blacklist=pcspkr" …)) > > For the 6 people who actually want the infernal demented shofar that is the > ‘PC speaker’, I'm not > sure what the solution is. Or if one is even needed, since the ‘error’ is > indeed 100% harmless. > > Kind regards, > > T G-R > > Sent from a Web browser. Excuse or enjoy my brevity.
bug#48974: A possible shepherd bug (it's very minor)
June 12, 2021 3:39 PM, "Leo Prikler" wrote: > Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson: > >> Hello! >> >> I've had this issue every since I enabled automatic login on my guix >> system like so: >> >> #+BEGIN_SRC scheme >> (define %my-desktop-services >> (modify-services >> %desktop-services >> (mingetty-service-type config => >> (mingetty-configuration >> (inherit config) >> ;;auto login as joshua >> (auto-login "joshua") >> >> (operating-system >> ... >> (services (list %my-desktop-services))) >> #+END_SRC > > I am sorry to say this, but rather than this being (just) a bug with Thank you for speaking so gently! :) > shepherd, your config looks seriously borked. Why are you asking Guix > to autologin you on *every available console*? HAHAHA! That's what I'm doing! I forgot that! Honestly, I did that, because I couldn't figure out how to code "just auto log into console 1 ONLY". :) Would you mind explaining how bad of a decision this is? Is this a BAD security practice? I'll tell you what, why don't we leave this "bug" open for a week...I'll try to write the code that does what I want, and I'll email the answer. Then I'll edit the manual to provide an example! Thanks Leo (You sir, are a superstar!), Joshua > Regards, > Leo
bug#48973: An early booting warning message
Thanks for the help! June 12, 2021 11:46 AM, "Tobias Geerinckx-Rice" wrote: > This is a cross-distro annoyance; Guix doesn't explicitly load or even > mention pcspkr. > > One very common work-around is > > (kernel-arguments (list "modprobe.blacklist=pcspkr" …)) > > For the 6 people who actually want the infernal demented shofar that is the > ‘PC speaker’, I'm not > sure what the solution is. Or if one is even needed, since the ‘error’ is > indeed 100% harmless. > > Kind regards, > > T G-R > > Sent from a Web browser. Excuse or enjoy my brevity.
bug#48974: A possible shepherd bug (it's very minor)
Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson: > Hello! > > I've had this issue every since I enabled automatic login on my guix > system like so: > > #+BEGIN_SRC scheme > (define %my-desktop-services > (modify-services > %desktop-services > (mingetty-service-type config => >(mingetty-configuration > (inherit config) > ;;auto login as joshua > (auto-login "joshua") > > (operating-system >... >(services (list %my-desktop-services))) > #+END_SRC I am sorry to say this, but rather than this being (just) a bug with shepherd, your config looks seriously borked. Why are you asking Guix to autologin you on *every available console*? Regards, Leo
bug#44872: Installer crash: 'uuid->string' is passed #f in lieu of a UUID
Hey, > It seems that for some reason the installer has automatically picked a > mount point of `/boot/efi' for `/dev/sda2' in addition to the mount > points on my actual hard drive. I now see an error dialog saying that > it can't retrieve the UUID of /dev/sda2 when I try to proceed past the > partitioning page. If I clear the mount point for /dev/sda2, I am now > able to proceed to the page to with the generated system configuration! Oh, I understand! The installation device is not detected by the non-install-devices procedure, as it often happens. Hence, the create-special-user-partitions finds two ESP partitions. The one on your main hard drive and the one on the installation ISO. Reading the UUID of the ESP partition of the installation ISO returns false, not sure why, but this is not the central issue. I improved the install device detection with 154a4e046281c28e39b5016e965d3d937a2ea4a1 by removing the device with the default Guix System image ISO label. This is quite fragile and if someone has a better idea, please feel free to share it :). In the meantime, it should completely fix your issue. Thanks a lot for your help, Mathieu
bug#48973: An early booting warning message
This is a cross-distro annoyance; Guix doesn't explicitly load or even mention pcspkr. One very common work-around is (kernel-arguments (list "modprobe.blacklist=pcspkr" …)) For the 6 people who actually want the infernal demented shofar that is the ‘PC speaker’, I'm not sure what the solution is. Or if one is even needed, since the ‘error’ is indeed 100% harmless. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
bug#44872: Installer crash: 'uuid->string' is passed #f in lieu of a UUID
Hey Mathieu, thanks for looking into this!
Mathieu Othacehe writes:
> I fixed this issue with f5d9d6ec68f78f5651bd5a698f489ab57bf77d5d. The
> rationale is that any partition that will be mounted and not formatted
> ("Format the partition? No) must have a valid UUID. The installer
> now prevents going further if this is not the case.
>
> That said, I think you are experiencing a different issue. The REPL
> commands you ran show that your nvme0n1p1 and nvme0n1p6 partitions have
> valid UUIDs.
Your change seems to have exposed the real (and totally unexpected)
problem! For some reason, the installer is trying to get the UUID of
a partition on my USB stick that contains the installer.
It seems that for some reason the installer has automatically picked a
mount point of `/boot/efi' for `/dev/sda2' in addition to the mount
points on my actual hard drive. I now see an error dialog saying that
it can't retrieve the UUID of /dev/sda2 when I try to proceed past the
partitioning page. If I clear the mount point for /dev/sda2, I am now
able to proceed to the page to with the generated system configuration!
At this point I think I should be able to proceed with making the
installation video I was working on, I'll just let viewers know that
they may need to clear that mount point if the same thing happens for
them.
> I'm not sure if you are aware of this feature, but generating
> uncompressed ISO9660 image is a serious time saver when debugging the
> installer:
>
> --8<---cut here---start->8---
> guix system image -t uncompressed-iso9660 gnu/system/install.scm
> --8<---cut here---end--->8---
I wasn't aware, thanks for letting me know! Creating the image was a
lot faster this time :)
David
bug#48974: A possible shepherd bug (it's very minor)
Hello! I've had this issue every since I enabled automatic login on my guix system like so: #+BEGIN_SRC scheme (define %my-desktop-services (modify-services %desktop-services (mingetty-service-type config => (mingetty-configuration (inherit config) ;;auto login as joshua (auto-login "joshua") (operating-system ... (services (list %my-desktop-services))) #+END_SRC This is the "error message" #+BEGIN_SRC sh This is the GNU system. Welcome dobby login: joshua (automatic login) This is the GNU operating system, welcome! Cannot make/remove an entry for the specified session #+END_SRC Essentially, mingetty tries to auto log me in, but I am using desktop services. So mingetty tries to log me in, before many of the desktop services are started. However, I guess this doesn't work. Meaning, my autostart sway script is NOT run, until AFTER all of the desktop services are started. WHICH IS PROBABLY A GOOD IDEA. I would rather log in, when my desktop services have started, not before. BUT the minor issue is that after I log in, =users= reports: #+BEGIN_SRC sh joshua@dobby ~> users joshua joshua joshua joshua joshua joshua #+END_SRC So it looks like 6 versions of myself are logged in by the time I am officially logged in and I auto start sway via .bash_profile: #+BEGING_SRC sh # Honor per-interactive-shell startup file if [ -f ~/.bashrc ]; then . ~/.bashrc; fi # shepherd if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]]; then export MOZ_ENABLE_WAYLAND=1 export GUIX_PACKAGE_PATH=/home/joshua/prog/gnu/guix/guix-packages/ XDG_DATA_DIRS=/var/lib/flatpak/exports/share:/home/joshua/.local/share/flatpak/exports/share:$XDG_DATA_DIRS # this may fix a bug that I have with termite confusing backspace as space in guix environment # export TERM=linux shepherd -c /home/joshua/.config/shepherd/init.scm & exec dbus-run-session sway fi #+END_SRC I'm guessing the root cause is that the shepherd starts most services sequentially at the moment. Anyway, I thought I'd share a minor issue with you all! Thanks! Joshua Branson
bug#48973: An early booting warning message
Hello! I've seen this warning message from my boot screen pretty much every time I boot guix system on my T400. [ 36.909489] Error: Driver 'pcspkr' is already registered, aborting... The system boots just fine, but I figured I'd report this error message. Thanks! Joshua
bug#48972: Early guile repl is giving me some GC Warnings
Hello! My librebooted Thinkpad T400 has been giving me the same GC warning for about 2 years now: 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... I system boots just fine, but I figured that I should mention this! Thanks, Joshua
bug#45238: The section [[info:guix#Invoking guix package]] contradicts itself
Hi, Em [2021-06-10 qui 13:33:53+0200], zimoun escreveu: > I think it is fixed with the recent version of the manual. Could you > confirm? Yes, the problem I reported is fixed in the latest version of the manual. Thank you! -- - https://stallmansupport.org "In Support of Richard Stallman" - I am Brazilian. I hope my English is correct and I welcome feedback. - Free Software Supporter: https://www.fsf.org/free-software-supporter - If an email of mine arrives at your spam box, please notify me.
bug#48965: filter-dkimsign tarball not available
Brendan Tildesley 写道： https://imperialat.at/releases/ works fine for me. Thanks. Thanks for confirming! Case closed. Kind regards, T G-R signature.asc Description: PGP signature
bug#48965: filter-dkimsign tarball not available
https://imperialat.at/releases/ works fine for me. Thanks.
bug#48965: filter-dkimsign tarball not available
> On 06/12/2021 11:36 AM Tobias Geerinckx-Rice wrote: > > > Brendan, > > Brendan Tildesley 写道： > > Yep. I downloaded 3000 source tarballs with -S and just this one > > didn't > > work for some reason. I'm in Tasmania, Australia. > > Wait, so libopensmtpd *did* work? It uses the exact same server, > with HTTPS :-/ That one fails too. It seems to take 5-10 minutes + to time out. There is a substitute available so my guix is able to download that.
bug#48965: filter-dkimsign tarball not available
Brendan, Brendan Tildesley 写道： Yep. I downloaded 3000 source tarballs with -S and just this one didn't work for some reason. I'm in Tasmania, Australia. Wait, so libopensmtpd *did* work? It uses the exact same server, with HTTPS :-/ Could you verify that before pulling to test… Doesn't work with guix, wget, or curl. Just hangs after connected for a while. Hmkay… I have a ‘free’ VPN lying around somewhere but I don't think I'll bother. I've added another URI in 7479124cd7030b9b303420cb28585bac4331daaf. If that one also fails stranger things are afoot. Kind regards, T G-R signature.asc Description: PGP signature
bug#48965: filter-dkimsign tarball not available
> On 06/12/2021 10:17 AM Tobias Geerinckx-Rice wrote: > > > Brendan, > > Brendan Tildesley 写道： > > Starting download of > > /gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz > > From https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz... > > Throw to key `gnutls-error' with args `(# > Error in the pull function.> handshake)'. > > ~ λ guix download > https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz > […] > /gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz > 0jwp47ixibnz8rghn193bk2hxh1j1zfrnidml18j7d7cylxfrd55 > > Can you guix download other https:// sources without problems? Yep. I downloaded 3000 source tarballs with -S and just this one didn't work for some reason. I'm in Tasmania, Australia. Doesn't work with guix, wget, or curl. Just hangs after connected for a while. We should have a mirror of it anyway as backup on the CI to ensure it works anyway.
bug#48966: svt-hevc sha256 missmatch.
Brendan, Brendan Tildesley 写道： Tobias, are you able to figure out what changed? I updated svt-hevc to the v1.5.1 tag on 29 May. On 2 June, upstream noticed that they (I guess, by their standards) made a mistake, fixed it[0], and moved the v1.5.1 tag to point to it. That's bad practice but it happens. Fixed in 00727470b92e0b8ab0e00dd2cd87495c0c136341. Thanks for the puz, cuz, T G-R PS: Did you send this bug mail differently? Only bug-guix@gnu.org was in Cc:, I had to add [-done]@ myself. Could just be Debbugs weirdness of course. [0]: https://github.com/OpenVisualCloud/SVT-HEVC/commit/b65eba07e6dee37407631cc441561960838b0333 signature.asc Description: PGP signature
bug#48965: filter-dkimsign tarball not available
Tobias Geerinckx-Rice 写道： https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz …and/or does this URL work for you with cURL/a browser, wherever you are? I'm physically next door to .nl, so that makes me mildly suspicious. Kind regards, T G-R signature.asc Description: PGP signature
bug#48965: filter-dkimsign tarball not available
Brendan, Brendan Tildesley 写道： Starting download of /gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz From https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz... Throw to key `gnutls-error' with args `(#Error in the pull function.> handshake)'. ~ λ guix download https://distfiles.sigtrap.nl/filter-dkimsign-0.5.tar.gz […] /gnu/store/kd1kbq1anb7iy7ig999i7zq16m8pzayk-filter-dkimsign-0.5.tar.gz 0jwp47ixibnz8rghn193bk2hxh1j1zfrnidml18j7d7cylxfrd55 Can you guix download other https:// sources without problems? Kind regards, T G-R signature.asc Description: PGP signature
bug#44872: Installer crash: 'uuid->string' is passed #f in lieu of a UUID
Hello David,
>> I'm using manual partitioning with the first partition mounted as the
>> ESP partition and the sixth partition as the root directory.
My issue here is that those partitions were never formatted. The
read-partition-uuid method returns #f on unformatted partitions, causing
the installer crash.
I fixed this issue with f5d9d6ec68f78f5651bd5a698f489ab57bf77d5d. The
rationale is that any partition that will be mounted and not formatted
("Format the partition? No) must have a valid UUID. The installer
now prevents going further if this is not the case.
That said, I think you are experiencing a different issue. The REPL
commands you ran show that your nvme0n1p1 and nvme0n1p6 partitions have
valid UUIDs.
That's why I also pushed this commit:
1a0a18d0ccc6cb6c7f4e42a0d659340f13b206c5 that prints in the syslog the
internal list, hoping that it will help us understand
what's going on.
It would be great if you could build a new installer image on top of
master, try reproducing the crash and attach the content of the
"/var/log/messages" file. You can for instance scp it to another machine
of your local network running an SSH server.
I'm not sure if you are aware of this feature, but generating
uncompressed ISO9660 image is a serious time saver when debugging the
installer:
--8<---cut here---start->8---
guix system image -t uncompressed-iso9660 gnu/system/install.scm
--8<---cut here---end--->8---
Thanks,
Mathieu
bug#48967: No newline after substitution of ~a complete line.
I get output that looks like this: substitution of /gnu/store/g26z8hhqagcsiwz611jwhyj7rk6zywqg-python-pybigwig-0.3.17 completesubstituting /gnu/store/slxjk0sg8q85qk0l0dv5kv71z2l4pgv2-python-pybrowserid-0.14.0... downloading from https://ci.guix.gnu.org/nar/lzip/slxjk0sg8q85qk0l0dv5kv71z2l4pgv2-python-pybrowserid-0.14.0 ... Also, could the value of (simultaneous-jobs status) change between invocations in the code? It's ok not to use let? Adding a newline seems to fix it.From a2628f0565e0428af55ada53ac3826e9a855b022 Mon Sep 17 00:00:00 2001 From: Brendan Tildesley Date: Sat, 12 Jun 2021 15:58:13 +1000 Subject: [PATCH] status: Add missing (newline). * guix/status.scm: Add newline after substitution complete line. --- guix/status.scm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/guix/status.scm b/guix/status.scm index 1164c2a6e3..f351a56d92 100644 --- a/guix/status.scm +++ b/guix/status.scm @@ -558,7 +558,8 @@ substitutes being downloaded." ;; If there are no jobs running, we already reported download completion ;; so there's nothing left to do. (unless (zero? (simultaneous-jobs status)) - (format port (success (G_ "substitution of ~a complete")) item)) + (format port (success (G_ "substitution of ~a complete")) item) + (newline port)) (when (and print-urls? (zero? (simultaneous-jobs status))) ;; Leave a blank line after the "downloading ..." line and the -- 2.31.1
