IRC channel logs
2025-12-04.log
back to list of logs
<mwette>Q: On foreign distro, how do I set up my personal account? I assume something needs to appear under /var/guix/profiles/per-user. <mwette>I cleaned out guix and reinstalled via guix-install.sh and then converted to unpriv'd daemon. It seems to be working now (for root). yay! <apteryx>ACTION ponders about a gnu-team to maintain the official gnu packages not already covered by some team (e.g. emacs-team); would someone be interested to join it? <mwette>w/ foreign distro, now I get, during guix pull: error (ignored): program `newgidmap' failed with exit code 1 <mwette>journalctl shows this: Dec 03 16:10:48 bluefin guix-daemon[6483]: newgidmap: gid range [40000-40001) -> [993-994) not allowed <mwette>--disable-chroot seems to fix above newgidmap issue <Kaizer>Hey guys, hope you're well. I'm having a strange issue, when I launch emacs with a shepherd service, I cannot use gpg. But when I launch it with an app launcher gpg works just fine. Any ideas on how I can fix it? <ieure>Kaizer, Probably an issue with your environment variables. <ieure>Are you using gpg-agent? I'm not sure how to make all that work with a Shepherd service. <Kaizer>Hey ieure, I'm using gpg-agent home service. When you say environment variables do you mean that my shepherd service does not have access to my environment? <ieure>Kaizer, Are you getting an error of some sort when you try to use GPG? <ieure>Kaizer, I'm not sure of the order of things here, but if you have stuff in your shell dotfiles which Emacs or GPG need to work, those likely won't be visible in the emacs service. <Kaizer>ieure: I get one of two errors either the screen is too small one or bad session key. I never get a chance to input my password in both instances <Kaizer>ieure: Let me check my shell dotfiles but this is very strange, can I ask why this is the case? <ieure>Kaizer, because environment variables only propagate down the process tree, so for shepherd to see them, it has to spawn from bash, after they've been set by bash. <ieure>Herd spawns bash? It cannot know about the environment of a child process. Bash spawns herd, but before evaluating your config with the variables? They didn't exist when it was fork()ed, so it cannot see them. <Kaizer>ieure: Okay, if I understand what is going on correctly, shepherd is PID 1, shouldn't all processes spawn from shepherd? And if that's the case, then you're saying that emacs doesn't have access to the environment? For reference, I am using sway and I only just switched recently, I didn't have this issue under hyprland even when I launched emacs using a shepherd service. The only thing that has changed is my display manager and some <Kaizer>environment variables like XDG_SESSION_DESKTOP, XDG_CURRENT_DESKTOP, DESKTOP_SESSION and WAYLAND_DISPLAY. <Kaizer>Personally now, that you've mentioned environment variables, I suspect this WAYLAND_DISPLAY variable because it is set by sway and it doesn't exist in my bash_profile. This is probably the issue <apteryx>does anyone know how to use #:configure-flags with pyproject-build-system? <apteryx>Doesn't seem to work with meson-python, nor with python-pypa-build <apteryx>looks like mesonpy.build_wheel should honor the config_settings argument <untrusem>apteryx: hmm we should have a gotcha file to list some of these tnings <apteryx>I think just the doc of pyproject-build-system could give an example, and cross-ref guile-json <Rutherther>sneek, later tell Kaizer: could you clarify what shepherd instance you're using for starting emacs? If it's the user shepherd, then that one probably has most of your environment. (assuming default guix home setup). True that not WAYLAND_DISPLAY. <csantosb>Wow, Codeberg is waving over a serious storm today ... <jlicht>is there anything guix system-specific I have to do in order to get kernel console output over a USB serial device? <flurando>jlicht: no idea how to implement that even in normal distros, but if it is about grub, you can set grub terminal to series, if it is about agetty or mingetty, you can find relevant system services of them in %base-services. <civodul>Rutherther: hey! is the release team planning to provide AArch64 ISOs? (i forgot the details) <Rutherther>civodul: definitely. I already do have one working in vm. Had to fix couple of issues. If anyone had real hw with uefi, it would be great if they could test <hanker>> civodul: definitely. I already do have one working in vm. Had to fix couple of issues. If anyone had real hw with uefi, it would be great if they could test <hanker>i have a pinephone with allwinner a64, wonder if that qualifies <ieure>hanker, I don't think we're going to be making images for specific devices, ARM systems are too fragmented and it'd be impossible to test on every platform, or even a significant fraction of them. <ieure>hanker, There's some PinePhone-related stuff in gnu/system/images/pine64.scm <ieure>I have a PinePhone, but haven't tried this. <hanker>oh no i was proposing to test the ISO <hanker>the pinephone has been lying in my drawer for the better part of this year <Kaizer>Hey guys, hope you are well, I'm having a small challenge. I'm using a shepherd service to launch emacs. However, I am using sway and sway sets $WAYLAND_DISPLAY and $DISPLAY variables by itself and so pinentry-gtk cannot launch, hence I cannot use gpg from this instance of emacs. When I launch emacs from a terminal or from an app launcher everything is fine. Any ideas on how I could solve this? The main problem is that shepherd starts <Kaizer>before sway so it doesn't inherit the $WAYLAND_DISPLAY variable. How can I get around this? <sneek>Kaizer, Rutherther says: could you clarify what shepherd instance you're using for starting emacs? If it's the user shepherd, then that one probably has most of your environment. (assuming default guix home setup). True that not WAYLAND_DISPLAY. <Kaizer>Hey sneek, I'm using a guix home shepherd service to launch emacs <civodul>is this something you already observed on Codeberg? <mwette>Sorry to keep bugging: `mwette$ guix pull' generates ~ "error, insufficient priv's to create /var/guix/profiles/per-user/mwette". Is this because profiles/ is not owned by guix-daemon? <civodul>hi mwette! that’s on a distro other than Guix System, right? <civodul>and guix-daemon is running without root privileges <civodul>can you confirm guix-daemon.service has “AmbientCapabilities=CAP_CHOWN”? <civodul>that’s what allows guix-daemon to create /var/…/per-user/$USER on behalf of users <ieure>civodul, It's because the branch was force-pushed after the comments were left. <civodul>ieure: i thought about it, but the force-push didn’t shift lines (and it was before those comments) <civodul>mwette: so what happens if you run “guix build hello” as a user? <civodul>normally guix-daemon would create /var/…/per-user/$USER <civodul>anything in “journalctl -u guix-daemon.service”? <mwette>I did add --disable-chroot on the daemon, becasue it was giving issues with newgidmap <civodul>and install the ‘uidmap’ package instead <ieure>civodul, At least the Codeberg "compare" to show the diff between the before/after force push states disagrees: "260 changed files with 89036 additions and 8408 deletions." Or you may have had a tab open with the pre-force-push state. Basically, yes, I have seen this (not just on Codeberg), but the only times I have is when force-pushing. <civodul>ieure: hmm ok, i’ll pay more attention next time <mwette>uidmap was already installed (via ubuntu apt install) <mwette>profiles/ should be owned by root, right? (not mentioned in the guix manual) <nckx>Kaizer: sneek is a bot; the nick before ‘says’ is the human who left the message. (I assume that they are human. They are very good if not.) <Kaizer>Rutherther: I'm using a guix home shepherd service to launch emacs <mwette>civodul: journalctl says only `guile: warning: failed to install locale' <civodul>mwette: profiles/ should be owned by “guix-daemon”, not by root <mwette>civodul: I used guix-install.sh. Then I went through manual instructions "Micrating to the Unprivileged Daemon". Root was able to build hello fine. <mwette>above migration after guix pull as root, daemon running as root <nckx>civodul: Mine isn't [owned by guix-daemon], is that because it's old? <mwette>civodul: the migration instructions in the manual do not say to chown profiles/, unless I missed it <mwette>For some reason guix-install.sh did not install as unpriv'd user. I had to migrate <mwette>Is userpool/ supposed to be owned by guix-daemon as well? That was not mentioned in the manual. <basicnpc>Do G-expressions get compiled to (safe, hopefully) bash code? <gabber>you can "compile" them to any sort of file <basicnpc>I meant to ask what guix actually does to it in low-level. <ieure>basicnpc, I believe gexps are transported across the client<->guix-daemon process boundary and evaluated (in Guile) in the build environment. I do not believe it is feasible or a good idea to compile them to bash. <cbaines>It's run like other Guile code, but often later <ieure>They get compiled to Guile bytecode, like any other Guile code. <basicnpc>Hmm but the guile bytecode machine must perform standard operations like make.. etc. <basicnpc>And the only interface I know of is shell code. So I wonder if that's what the bytecode machine is secretly doing. <ieure>basicnpc, No. There's a Guile function execute a process. <gabber>basicnpc: shell is just a text interface to the kernel <ieure>Many, many languages have a similar facility. <gabber>we can do the same operations without shells (by directly addressing the kernel's ABI) <cbaines>gabber, you're not running system calls in a shell... <cbaines>gabber, Guile's also not interfacing with the kernel, it uses glibc <basicnpc>Yes, most operations like symlink or file-append do not have to go through bash. <basicnpc>What if one wants to invoke `$ make all`..? <gabber>ok sorry, i meant "interfacing the kernel with extra steps" <identity>which starts the make program with one argument <gabber>basicnpc: we tell the system to execute the program "make" with the argument "all" <identity>we do it (i assume) the same way bash does, without bash getting involved <ieure>Yes, fork+exec, same way everything does it. <identity>there is also (system "make all") which *actually* invokes bash (or i guess /bin/sh or something) to then execute the command <basicnpc>Nix seems to like partial lang (nix) and love other scriting lang (like shell). <basicnpc>I'm not clever enough to understand why they like that. <cbaines>I think people like the Nix language's ability to generate strings, which are often bash scripts to be run at build time <gabber>basicnpc: i think this happened by chance, not by design <cbaines>But since code staging in Guile is comparably easier to implement compared to implementing something similar in Nix, using G-expressions is a great benefit of using Guile <basicnpc>I also don't understand why guix didn't aim to work for a more general audience. <gabber>basicnpc: may i inquire what thought provoked such a statement? <Kaizer>I don't want to be that guy, but from my own experience, people just don't get the "why" of guix leave alone having to learn guile to use it and why guile is the best choice <basicnpc>That guix the pkg manager wasn't designed to work nicely with macos. <Kaizer>I came to guix only after using debian and arch extensively and them failing me consistently led me to use guix. That combined with SICP made me understand the "why" of guix <basicnpc>Kaizer: Well.. to edit any lisp it's almost necessary to use emacs, and that has some stepth. <basicnpc>ACTION just looked up in the urban dictionary.. <cbaines>basicnpc, Guix is a free software project, why would it be designed to work nicely with proprietary MacOS? <basicnpc>Then why should unfree channels be allowed? If guix wants to go to the exteme, there should be more enforced policing. <basicnpc>Why not making it so that only the censored channels are allowed? <cbaines>Once again, Guix is a free software project, you can use the software for any purpose, that's freedom 0 <Kaizer>basicnpc: That too, that combo of emacs, lisp and declarative/transactional/reproducible distro combo makes it a non-starter for most people cause it's a lot of work to get started despite the strong benefits <basicnpc>But it's hard to use it on macos. Don't you think this may be violating it? <cbaines>The Guix project doesn't participate in packaging or providing non-free software, but there's no limitation of use on Guix itself, there can't be, it's free software <Kaizer>And then also guix is not that discoverable and llms won't help you at all :) <cbaines>basicnpc, no, being hard to use does not make software non-free. I think you're conflating usability with legality. <basicnpc>cbaines: Even if we ban the uncensored channels, it's still free. One can argue the code is there, and whoever wants to use uncensored channels, they can freely modify it. <basicnpc>In that way, it's still free, and it's actively making the world more aligned to such freeness. <cbaines>basicnpc, I don't understand what you mean, who "we" is or what "uncensored channels" are <gabber>Kaizer: i think that addressing the useless ness of auto-correct software on steroids™ is beyond the scope of our project <ieure>basicnpc, I think most Guix people are content to have a thing they enjoy using and hacking on, and aren't in this to "win" against Nix/Homebrew/whatever. There's plenty of users to go around. <basicnpc>I just don't understand how they justify themselves. <ieure>And you cannot make Guix work on macOS without compromising two of its fundamental goals. That's not on Guix, it's on Apple, for having built the closed system that makes it impossible. <basicnpc>But I guess that applies to everyone. Everyone has their own comfort zone. <basicnpc>Making it work on macOS compromises which goal? I will read it up. <ieure>basicnpc, I linked you to the discussion a couple days ago, did you read it? <Kaizer>gabber: To be fair, nothing can fix the ultimate stonks go up machine <basicnpc>Is the goal embedded in that discussion? <ieure>basicnpc, No, this has nothing to do with VMs. <gabber>basicnpc: that being said i doubt that a MacOS port would intensify Guix' popularity that much <basicnpc>But I wonder in principle how, ieure.. The root human-readable program must be compiled to machine code by some other program, right? <basicnpc>So one needs to make that other program as a result of compiling another program.. and so on. <basicnpc>But now they don't just want to make it 99% perfect; it seems they want 100% perfection. <ieure>basicnpc, It's explained in the blog post. <ieure>basicnpc, "For x86-linux... this means this program hex0-seed, with ASCII-equivalent hex0_x86.hex0. Hex0 is self-hosting and its source looks like this:" <ieure>But tl;dr the seed is a literate programming style binary with the source in comments, which can be trivially mechanically converted to pure binary and executed. <basicnpc>I don't really understand.. eventually some thing must be used to convert that to a binary. <ieure>basicnpc, The seed is 357 bytes of hand-audited machine code with the full source in the comments. It's small enough for anyone to audit, and you can key it in yourself. <ieure>I would encourage you to read both that and the Guix blog post and, if you have specific questions not answered there, ask them. <ieure>But so far, most of your questions have had answers in there. <basicnpc>Thanks! They look promising. I will read them after work. <basicnpc>Well I start to see the point. It's small and simple enough for anyone to hand compile it to binary. <basicnpc>So one just have to check whether their computed binary is the same as the actually compiled binary. <basicnpc>The next question is.. should we trust that the machine actually acts faithfully under the machine code? <ieure>How would the machine work at all if it couldn't execute that code? <basicnpc>I mean, we have to trust that the machine is actually acting as how it's documented. <basicnpc>Namely, if viewing the machine as a 'compiler' from machine code to 'effect', we must trust that 'compiler.' <ieure>Yes, but as far as that goes, inability to execute this code means it is malfunctioning. <basicnpc>It could still be able to execute, but in some unfaithful way. <basicnpc>ACTION doesn't understand the question.. <ieure>In what way would it execute code unfaithfully? <basicnpc>I don't know. I can't think of any, but that doesn't mean they don't exist. <lilyp>well, you could imagine a cpu that takes way too long for a specific instruction, thus introducing a side channel for your code ;) <ieure>But it's impossible to refuse a hypothetical scenario. <basicnpc>that if there's a way to examine the cpu as a physical hardware. <basicnpc>to see how it's designed and whether it matches its documentation. <basicnpc>(then the next problem is 'can we trust physics', but I'd leave that to philosophers. I will be comfortable enough at that stage.) <basicnpc>ieure: I don't know about how hardware works.. so I'm curious. Really..? There's no way? <gabber>basicnpc: my basic drunk experience is clear: i can't trust physics <ieure>basicnpc, The documentation is incomplete, and the only way to "examine" the CPU is to decap it, which destroys it. <ieure>basicnpc, Also, nearly every CPU has bugs where its behavior doesn't match its documentation. Super common. <basicnpc>ieure: If it's destroyed after examination, that's ok. <ieure>basicnpc, Used to be that you'd have to rev hardware for that, Intel called them "steppings." Modern CPUs use microcode; you don't actually write code for the real CPU, you write it for the ISA which is implemented as microcode on a completely different underlying architecture. And the microcode gets updated to fix issues. <basicnpc>We can examine the cpu producing company, by randomly examining their sold product. <ieure>basicnpc, Not really. The M3 Ultra CPU has 184 billion transistors on it, far too many for anyone to reasonably audit. And the actual ISA is microcode, which is written in an unknown language, compiled or assembled with secret tools, signed by cryptographic keys we cannot access, targeting an undocumented architecture. <ieure>If you're paranoid to the level of wanting to audit your CPU, something like RISC-V is probably your best bet. <identity>maybe we should go back to z80 with 8500 transistors <csantosb>Is this a bug or a feature ? `sshfs server:/toto ~/here/titi` gives `fuse: failed to exec fusermount3: No such file or directory` <csantosb>I need to install `fuse` to make it work <gabber>csantosb: i guess it's mostly a fact (: <Rutherther>it's not an easy thing to solve. In order to work properly (without root), fusermount3 has to be a setuid binary. While part of guix source patches directly to /run/privileged/bin/<binary>, it's not done for every case and probably rightfully so as it would disallow the packages working on foreign distros. I have came up with a generic way - https://codeberg.org/guix/guix/pulls/2223, but haven't received much feedback for now <gabber>csantosb: i take it `sshfs' is part of the openssh package? <csantosb>I had it wrong, on Arch foreign, installing fuse with guix is not enough, I had to install `fuse3` with pacman <Rutherther>Yes, that is a limitation we won't be able to overcome <Rutherther>or like... we could make privileged service also for foreign distros with simple activation system, but that's the most we could do <Rutherther>Guix itself can't produce setuid binaries by design, it would lead to privilege escalation <csantosb>No problem from my side, just wanted to be sure this is something we understand, not something unexpected <csantosb>By the way, the # of pr lowered considerably, congratulations to the people involved ! <PotentialUser-95>this is not the full backtrace but this is the key part, how can i fix it? i can share my guix home config or /etc/config.scm <vagrantc>PotentialUser-95: is the clock on your system reasonably accurate? <ieure>Was about to ask the same thing. <vagrantc>ACTION has walked around the block more than a few times <mwette>apteryx: If OK with you, I'll send an email with my ubuntu install issues to figure how to disposition. I saw on codeberg that you are working several issues on that front. <ieure>PotentialUser-95, Does it work if you try again? <ieure>PotentialUser-95, Multiple times, I've had SSL issues from clock skew (not just in Guix), then retried and found that ntp had fixed the clock in between runs. <PotentialUser-95>Are there any other discussions where I can get help? Like discourse.nixos.org, but for guix. <identity>PotentialUser-95: why would you remove NTP from your config? <PotentialUser-95>Well, maybe this will help me with the error, although I tried and no, I have no ideas. <Rutherther>do you happen to have the file "/run/current-system/profile/etc/ssl/certs/ca-certificates.crt"? and if so, is SSL_CERT_FILE env var pointing to it? <PotentialUser-95>ls: cannot access '/run/current-system/profile/etc/ssl/certs': No such file or directory <Rutherther>please don't send multiple lines like that, use a paste site <Rutherther>because a bot is treating you as a spammer. Also it's very inconvenient as each line is a message... <Rutherther>did you manage to reconfigure your system at any point, or is this new installation? <Rutherther>okay. I am suspecting you have removed nss-certs from your system, then <Rutherther>what generations do you have available - "guix system list-generations" <PotentialUser-95>41st generation, Could it be because I got rid of %base-services yesterday or the day before? I just didn't want to have settings I don't control or can't see clearly <PotentialUser-95>I partially transferred the services that were included in %base-services <Rutherther>nss-certs is part of %base-packages, it is not provided through services <Rutherther>no, I am not asking what generatrion you are on. I am asking what generations you have available. Because you will need to use ssl cert file from one of the previous generations <Rutherther>or alternatively switch/boot to a previous one, but just using the ca cert file from an older one should suffice <PotentialUser-95>Maybe I can find the part of the code that was included in %base-services and was responsible for updating the certificate so I can add it to my config? Like grep -r "nss-certs" or something similar <Rutherther>available on the command line? what do you mean, it doesn't provide any binaries <Rutherther>no you do not have it installed as part of your system. If you did, you would have /run/current-system/profile/etc/ssl/certs <mwette>progress: I updated /etc/subgid per install.sh and executed the apparmor help from launchpad. I can `guix build hello' and `guix install hello' as mwette. But there is no current in .config/guix or in per-user/mwette/ <Rutherther>there should be no .config/guix in per-user/mwette <Rutherther>yes and it should ink to current-guix at /var/guix/profiles/per-user/mwette <mwette>$HOME/.config/guix is empty. /var/guix/profiles/per-user/mwette has only guix-profile entries <mwette>My reboot didn't go well. Gotta check that. <mwette>Ah. Is that in the manual? If so, I missed it. <Rutherther>I am not sure if it's in the manual, but the manual definitely states to update guix you use guix pull. So I don't think it matters if it mentions the implementation details or not <mwette>I think the context here is adding new user on foreign distros. <mwette>I mean getting new guix (existing) user hooked in. <Rutherther>it doesn't matter if they are new user or not. You should not need any operations for new users, it should all happen automatically. Both existing and new users do guix pull to update guix <Rutherther>mwette: could you elaborate on 'executed the apparmor help from launchpad'? <mwette>OK. I get it now. I think issues happened becuase I went through complicated path to get where I am (e.g., trying to build from tarball, then git, etc). <Rutherther>mwette: does Ubuntu come with this enabled by default or does one have to do something to enable apparmor plicies? <mwette>I tried `/etc/init.d/apparmor status' and got "enabled, active" <mwette>My ubuntu is vendor provided, so not sure that is default, but I guess it is. <mwette>box is System76 Thelio-Astra aarch64 <postroutine>Hello. I'm trying to install Guix System on a laptop. During the installation, I got an error: <postroutine>cannot build derivation '...-font-abattis-cantarell-....drv': 1 dependencies couldn't be built <postroutine>It's a freshly installation image built with the command `guix system image -t iso9660 gnu/system/install.scm` from my desktop. Is there a current problem with the Cantarell font ? <identity>postroutine: do not paste multiple lines in the channel, thanks <postroutine>I have found a bug from 2022, but I could install Guix system with Gnome sooner this year. <Rutherther>mwette: oh that's nice, would you consider trying guix system iso on that? <mwette>I don't think so. I paid $$ for it and want to use it for number crunching. <Rutherther>alright... just trying to find testers of aarch64 iso <mwette>Also, I'm guessing Guix System will does not like nvidia RTX 5070? <postroutine>identity, it just say the build of the derivation failed and that I can found the compilation log in a file. <identity>postroutine: so? anything interesting in the log? <postroutine>Is it possible to read the log during the installation process ? When I pressed enter, I got back to the graphical installer. <identity>postroutine: you can switch to a different tty with C-M-<f#> <Rutherther>mwette: not sure what you mean exactly. Should be fine to run terminal with nomodeset at least <postroutine>identity: The manual talk about it only for the manual installation. I though it would not be available with the guided graphical installation. <identity>why would it not be available during manual installation? <mwette>Rutherther: Then I'm not sure what you mean by "try ISO". Just boot thumbdrive and see if it works? <Rutherther>mwette: that's definitely the first step, yes. Also trying to install from it would be a plus, doesn't have to be a full environment, even the most minimal works. Mostly to know it can successfully boot <Rutherther>really the boot process is what I would be mostly worried about. The install process itself I can't see why that would be failing <postroutine>identity, the log say it cannot resolve gitlab.gnome.org. I can from my desktop. I need to check the dns setting of the installer. <mwette>The nvidia drivers seem to come from system76 (ppa.launchpad.net/system76-dev), but they do have a vga for primal boots I think. <postroutine>Ok, the network cable don't hold in place. The plastique piece that keep it connected is broken. My bad. Sorry for it. <hanker>> hanker: does the pinephone you have use uefi? <basicnpc>If there's no true sandboxing, couldn't a package definition that works almost everywhere have the chance to fail because one dependency of a package could be looking at some external data when random(0,10000000) is less than 2? <Rutherther>not sure what true sandboxing means nor how it relates to this <basicnpc>Say when you are packaging, the shell is really in a chrooted environment, then it truly cannot see anything outside it union the nix-store. <basicnpc>But if it's not sandboxed in that way, even while the $HOME and friends are changed, a program still choose to affect the outside world when random(0,1000000) <2. <basicnpc>This will not be visible most of the time. Until it breaks on someone's machine :-) <basicnpc>In that case that person just have to try again. <ieure>What does "when you are packaging" mean? <ieure>When I am creating a package definition? <basicnpc>So if guix want reproducible packaging then sandboxed packing is a must. <basicnpc>ieure: Yeah, and also when that package definition is sent to the official channel to be examined. <basicnpc>(ieure btw thanks for the good read. it went over my head for its depth, but it's still good to skim thu) <ieure>basicnpc, The builds themselves are sandboxed. <Rutherther>that's not a valid argument, because it assumes that packages do such stuff. They don't and if they do, that's what's wrong, not that it's not sandboxed. Apart from that guix builds in a sandbox already <basicnpc>guix builds in a sandbox already? By changing env vars? <ieure>basicnpc, I want to say that I appreciate your curiosity. But you are also inventing a bunch of impossible situations to get worked up about. <ieure>And it is starting to wear a bit thin. Please go read some of the Guix documentation.l <basicnpc>ieure: That's what stupid theorists like me do :-/ sorry for the loading.. <Rutherther>basicnpc: I wouldn't say changing env vars is sandboxing. Chrooting is what I would call sandboxing <ieure>We are happy to answer questions about actual behavior of Guix! But knocking down a series of impossible hypotheticals is not much fun. <basicnpc>Thanks! I was misled to believe that there's no proper sandboxing. <postroutine>The installation ended with success, but when I rebooted I get direct access to the grub shell. <basicnpc>ieure I forgot. Thanks for your time answering and pulling that up. I also found that a few minutes ago. <basicnpc>I did read the doc a few years ago, but it's a big thing, and I don't have good memory. <basicnpc>Plus being misled somehow, perhaps reading some blogposts or comments somewhere. <basicnpc>Maybe I'm also misled by some nix people, because I was trying to compare both. <ieure>Guix is based on Nix, and shares much of its fundamental functionality. <basicnpc>I still do believe Nix has no proper sandboxing. But maybe I'm wrong. I also heard that both don't have good documentations. <basicnpc>There are many rumors that newcomers have to rely on. Hopefully this channel is going to help some of us from that. <ieure>Guix has an extensive manual. It does have gaps, of course, but is quite comprehensive. <ieure>I don't know if Nix has sandboxing or not, but I would be surprised if it didn't. <basicnpc>This is different from, again, my impression. But yes, I found it much clearer than nix's. <postroutine>I have done a fresh install of Guix System that end with success. Default config with Gnome, CUPS and an encrypted root partition. When I boot, I directly got the GRUB shell with no error message. Do I miss a step on the installation ? <ieure>postroutine, Any messages or anything helpful? Or just a bare Grub prompt? <ieure>postroutine, Any other disks in your system? Install media still plugged in? <postroutine>No, I removed it. When I do a `ls` from grub, it see memdisk, proc, hd0, hd0.gpt2 and hd0.gpt1 <ieure>postroutine, If you `insmod chain', can you chainload the Grub EFI payload? Should be on (hd0,gpt1). <postroutine>ieure, I tried to do a `insmod chain` then a `chainloader (hd0.gpt1)/enf/Guix/grubx64.efi`. But nothing happen. <postroutine>Sorry, I mean `chainloader (hd0.gpt1)/efi/Guix/grubx64.efi` <postroutine>In the `efi/` directory, I can also see the old fedora directory. It seems the installer disk didn't format this partition. <postroutine>ieure, no, nothing. I'm still on the grub shell and it wait my next command. <postroutine>It ask me the passphrase for the encrypted disk. But grub is in US keyboard layout, not the one I use. <ieure>postroutine, You could wipe the partition table and try the install again. Also sometimes helps on UEFI systems to restore the BIOS defaults, that can clear out old UEFI menu entries. <ieure>postroutine, I think Grub not setting up the correct layout is a known issue, I've seen it come up here before. <Rutherther>postroutine: if you enter wrong passphrase I think it's expected nothing happens afterwards <Rutherther>I am not sure if guix sets up grub in a way that it could set up the layout before asking for passphrase for disk where the config is located at <Rutherther>if you cannot write the passphrase in US layout maybe you could add a second passphrase you will be able to write on a us layout <postroutine>After grub asking me the passphrase, and me give it the correct on: I have the grub menu with the Guix theme. And now, the kernel ask me for the encrypted partition passphrase. <postroutine>> I am not sure if guix sets up grub in a way that it could set up the layout before asking for passphrase for disk where the config is located at <postroutine>On Fedora, it's not grub that ask for the passphrase but the kernel (I think). <postroutine>Not: On my fresh Guix System installation, the second asking for my disk passphrase is in the correct keyboard layout. <Rutherther>guix stores the kernel etc. in the gnu store that you probably have on an encrypted partition. Also I suspect you have /boot on encrypted partition. And if this is all the case, then grub needs to ask you the passphrase, because otherwise it can't boot <Rutherther>the second passphrase is then from the initrd where it needs to open the disk by itself