bug#37128: guix system reconfigure stops output after "Evaluating user expression..."
Pierre Neidhardt writes: > Isn't there a more extensive log for "guix system reconfigure"? You could look at the .scm files produced by "guix system reconfigure" (the store paths should be printed to stdout). I'm afraid that, aside from Shepherd's own messages, the console output is the canonical log for "guix system reconfigure" right now. Regards, Jakob signature.asc Description: PGP signature
bug#36855: guix system switch-generation doesn't
Hi Mark, Mark H Weaver writes: > Hi Jakob, > > zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes: > >> Thanks for the input; I wasn't aware that the activation process was >> taking so long for some people. One of Ludovic's suggestions was to >> create a single derivation, rather than three, to speed up system >> activation. I'll look into this further. > > To be clear, I don't care how long it takes to build these > derivations. However, I think they should all be built before starting > to activate the system. Does that make sense? Yes, and I agree that it would be ideal to have the derivations built prior to system activation -- that way, the activation scripts could be included in 'show-what-to-build*'. > On a side note, what would happen if one of those builds failed? Would > the system activation be left half-done? Yes. You raise another very good reason for why system activation should be carried out by a single, atomic activation script :) Regards, Jakob signature.asc Description: PGP signature
bug#36855: guix system switch-generation doesn't
Hi Mark, Mark H Weaver writes: > Hello again, > > Mark H Weaver writes: > >> As a bonus, this approach might solve another issue I've observed: on my >> Guix system, where I build everything locally, several derivations are >> built *during* activation. Based on the terminal output, I get the >> impression that the system is compiling things while the system in an >> intermediate state, when some of the activation steps have been done, >> but not all of them. >> >> As I recall, the derivations built during activation are limited to >> compiled modules for Guile, but it still sometimes takes on the order of >> a minute or two on my laptop to complete the "activating system" steps. >> This seems suboptimal. >> >> The next time I update my system, I'll try to remember to keep a >> transcript of this, so that I can be more specific. > > Here's a transcript: > > activating system... > building > /gnu/store/fbp6bbxw9cf617fmk57sddrz7zfsfw5p-module-import-compiled.drv... > building > /gnu/store/wfi6hnr9ggal0s1d32xx5wbl5k5wqlvx-switch-to-system.scm.drv... > making '/gnu/store/mjzk53ia3bajn08lscpyzz5apcw3r70g-system' the current > system... > setting up setuid programs in '/run/setuid-programs'... > populating /etc from /gnu/store/l7r1has973n26hfqrs6vxbi94xzgh360-etc... > building > /gnu/store/h2fqcxv3xx14lkdhyphm3lawkayw7sdl-module-import-compiled.drv... > building > /gnu/store/dar9smjyxmri6v6cchnmp5mpyiimyx64-install-bootloader.scm.drv... > guix system: bootloader successfully installed on '/dev/sda' > building > /gnu/store/vkk3h5p799lfpmf6msdhrzlq0wqvk3zq-module-import-compiled.drv... > building > /gnu/store/hn8sr8p13gg2mf379xawscabckp03fkb-upgrade-shepherd-services.scm.drv... > shepherd: Evaluating user expression (let* ((services (map primitive-load > (?))) # ?) ?). > guix system: warning: only 3.9% of free space available on /gnu/store > hint: Consider deleting old profile generations and collecting garbage, along > these lines: > > guix gc --delete-generations=1m > >Mark Thanks for the input; I wasn't aware that the activation process was taking so long for some people. One of Ludovic's suggestions was to create a single derivation, rather than three, to speed up system activation. I'll look into this further. Regards, Jakob signature.asc Description: PGP signature
bug#36855: guix system switch-generation doesn't
Hi Ludo, Ludovic Courtès writes: > Jakob, now that we generate scripts for the effectful bits of system > reconfiguration (one of these bits being service upgrades), couldn’t > we take it one step further and store those scripts in the “system” > derivation so we can run them eventually, notably upon > ‘switch-generation’? We'd need to find a way of serializing at least the relationships between services, but I think it's possible (albeit quite involved). I do really like the idea, though. That way, the system generation would fully encompass the desired state of the system. Regards, Jakob signature.asc Description: PGP signature
bug#36876: guix system delete-generations removes custom boot menu entries
Hi Ludo, Ludovic Courtès writes: > I agree with Danny here that parsing the GRUB config wouldn’t be great. > > We have information about the user’s extra menu entries. The issue, as > I see it, as that this information is lost once the system is > instantiated. > > But! We have the structure, that gets serialized with > the system, and which we could extend with those extra menu entries. > That way, the info would be preserved, and we can restore them upon > ‘delete-generations’. records are bootloader-independent, > which is good. > > How does that sound? Would that involve appending an additional field to for storing the previous entries? I think that would have the pleasant side-effect of making the code for deployment/reconfiguration simpler :) Regards, Jakob signature.asc Description: PGP signature
bug#36517: 'guix deploy' does not restart services
Hi Ludovic, Ludovic Courtès writes: > Unless I’m mistaken, this bug can be closed now, right? Yep! This can be closed now, since we're running the unified code and we have another ticket for tracking this in 'guix system reconfigure'. Regards, Jakob signature.asc Description: PGP signature
bug#36865: Guix gc breaks grub
Hi Ludovic, Apologies for not participating in this thread until just now. Ludovic Courtès writes: > Jakob, does that ring a bell? Yes, this was fixed by #36880. Regards, Jakob signature.asc Description: PGP signature
bug#36942: Reconfigure broke GRUB
ison writes: > So I attempted a re-install and surprisingly it still fails. > I attempted 3 times. Using the graphical installer without efi, > manual install without efi, manual install with efi. All downloaded > and built everything successfully only to fail at the bootloader. > If the problem was my config then I'd think my first attempt would > have succeeded because the graphical installation automatically > built the config file. > > At least it's giving an error this time: > error: '/gnu/store/drz35fc...-grub-efi-2.02/sbin/grub-install > --boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /boot/efi' > exited with status 1: output follows: > /gnu/store/drz35fc...-grub-efi-2.02/sbin/grub-install: error: > /gnu/store/drz35fc...-grub-efi-2.02/lib/grub/i386-pc/modinfo.sh doesn't > exist. Please specify --target or --directory. > > My bootloader is section is still: > (bootloader (bootloader-configuration >(bootloader grub-efi-bootloader) >(target "/boot/efi"))) This is perfect (I mean, not that it still doesn't work, but that we have some error output). I think I know what's going on. The new 'guix system reconfigure' uses G-Expressions, and it looks like Grub is being ungexp'd for the wrong architecture. To be sure, what's the architecture of this machine? I'll investigate further and let you know what I find. Thanks again for doing this. Regards, Jakob signature.asc Description: PGP signature
bug#36942: Reconfigure broke GRUB
ison writes: > I do have a /boot/grub actually. Is that strange? > It looks like a normal /boot/grub to me, and contains a grub.cfg I think that's normal -- my virtual machine had one, too. > Sounds good, I'll reinstall it over the weekend Thank you :) Regards, JAkob signature.asc Description: PGP signature
bug#36942: Reconfigure broke GRUB
ison writes: > Sorry it took me so long to reply, I didn't have access to the broken > machine until now. No worries :) > As you requested here is the partitions as listed by parted: > > Number Start End SizeFile system NameFlags > 1 1049kB 3046kB 2097kB grubbios_grub > 2 3146kB 540MB 537MB fat32 efi boot, esp > 3 540MB 2588MB 2048MB linux-swap(v1) swap > 4 2588MB 750GB 748GB ext4guixsd Hm. Nearly the same as what I had, though my partitions had different sizes and I didn't have a swap partition. I may try again with this exact setup when I get back to the United States just to see what happens. > /boot/efi looks ok as far as I can tell at least. It's tree is: > /boot/efi/ > └── EFI > ├── grub > │ └── grubx64.efi > ├── Guix > │ └── grubx64.efi > └── GuixSD > └── grubx64.efi > All 3 grubx64.efi files differ from each other and are around 120kb. Interesting... I only have '/boot/efi/EFI/Guix'. Do you have a '/boot/grub'? > But considering you can't reproduce the issue would it be a good > idea for me to reinstall and see if I can even reproduce it? > Although I think this time I would leave off the bios_grub partition > I'm willing to keep testing the current bug if it's important or > indicative of a more serious problem. But please don't feel > obligated to keep working on this just for me, I'm perfectly fine > just reinstalling. The issue doesn't seem to affect my desktop > anyway, I was able to upgrade it smoothly. > > It's always possible the issue was caused by some strange > combination involving the patched bug, from earlier in the > discussion, and my weird partition layout. Might not even be worth > investigating unless it happens to someone else > (or me again after a fresh install). I think it may be indicative of a more serious problem, since you mentioned that this was fine up until the commit refactoring 'guix system reconfigure'. If you're willing to reinstall and see if you can reproduce it, that maywould be helpful -- you could send me the relevant 'install-bootloader.scm' store item if it breaks again. Thank you very much, ison. I appreciate your cooperation here greatly. Regards, Jakob signature.asc Description: PGP signature
bug#36942: Reconfigure broke GRUB
Hi ison,
ison writes:
> On Wed, Aug 07, 2019, Jakob L. Kreuze wrote:
>> I'll continue to investigate; perhaps I'll be able to reproduce if I
>> copy your exact partition scheme in the virtual machine. I'm sorry that
>> you had to go through that whole 'guix init' spiel again.
>
> No problem, it's a backup machine anyway, I've held off on updating
> my main (but it doesn't use efi so maybe I can). If this is a
> problem that only I'm having and nobody else then I wonder if a
> fresh install would fix it. Although I'm surprised nobody else seems to be
> experiencing it.
>
> The only unusual thing I did before it broke is that I tried to consolidate
> my configs from 2 machines into a single one by adding case statements.
> For example at the top I had (define local-profile 'laptop)
> and then my bootloader was something like:
> (bootloader (bootloader-configuration
> (case local-profile
> ((desktop)
>(bootloader grub-bootloader)
>...)
> ((laptop)
>(bootloader grub-efi-bootloader)
>...
>
> But I've since reverted back to my old config for all the subsequent
> "guix init" and reconfigures I've done, so it seems unlikely to be the
> cause but I thought I'd mention it anyway.
> Maybe having a BIOS boot partition on /dev/sda1 even though I'm using
> efi is somehow messing it up?
After some further research, I was able to create a virtual machine with
the partition scheme and bootloader configuration that you described.
;; This is an operating system configuration template
;; for a "bare bones" setup, with no X11 display server.
(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules screen)
(operating-system
(host-name "komputilo")
(timezone "Europe/Berlin")
(locale "en_US.utf8")
;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
;; target hard disk, and "my-root" is the label of the target
;; root file system.
(bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")))
(file-systems (cons* (file-system
(device "/dev/sda2")
(mount-point "/boot/efi")
(type "vfat"))
(file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
;; This is where user accounts are specified. The "root"
;; account is implicit, and is initially created with the
;; empty password.
(users (cons (user-account
(name "alice")
(comment "Bob's sister")
(group "users")
;; Adding the account to the "wheel" group
;; makes it a sudoer. Adding it to "audio"
;; and "video" allows the user to play sound
;; and access the webcam.
(supplementary-groups '("wheel"
"audio" "video")))
%base-user-accounts))
;; Globally-installed packages.
(packages (cons screen %base-packages))
;; Add services to the baseline: a DHCP client and
;; an SSH server.
(services (append (list (service dhcp-client-service-type)
(service openssh-service-type
(openssh-configuration
(port-number
%base-services)))
However, I still cannot seem to reproduce this issue with the most
recent master. Everything boots fine. I've extracted the bootloader
installation "script", and everything appears to be normal to me.
(begin
(use-modules (gnu build bootloader)
(gnu build install)
(guix build utils)
(guix store)
(guix utils)
(ice-9 binary-ports)
(srfi srfi-34)
(srfi srfi-35))
(let* ((gc-root (string-append "/" %gc-roots-directory "/bootcfg"))
(temp-gc-root (string-append gc-root ".new")))
(switch-symlinks temp-gc-root
"/gnu/store/xlb81742i5sb4cdmidfhabprc17ijwck-grub.cfg")
(install-boot-config "/gnu/store/xlb81742i5sb4cdmidfhabprc17ijwck-grub.cfg"
"/boot/grub/grub.cfg" "/")
(when #t
(catch #t
(lambda ()
((lambda (bootloader efi-dir mount-point)
(let ((grub-install (string-append bootloader
"/sbin/grub-install"))
bug#36855: guix system switch-generation doesn't
Hi Chris, Christopher Lemmer Webber writes: > Could you look at bug #36878 and commit 1db6f137d... as of latest > master, is this fixed? Unfortunately, I don't think that 1db6f137d fixes this. The issue is a bit more structural as 'switch-to-system-generation' doesn't call out to 'upgrade-shepherd-services'. I'm not sure if this was an intentional decision or not (perhaps we can ask Ludo when he returns). Regards, Jakob signature.asc Description: PGP signature
bug#36942: Reconfigure broke GRUB
Hi ison, ison writes: > I'm sorry to report that it actually didn't fix the problem. I'll continue to investigate; perhaps I'll be able to reproduce if I copy your exact partition scheme in the virtual machine. I'm sorry that you had to go through that whole 'guix init' spiel again. > Also I don't know why it didn't occur to me to mention this detail > before, but the reason I previously thought the message mentioned in > bug#36878 was important is because it's actually the very last thing I > see on the command line after reconfiguring. The line I'm talking > about is of course: shepherd: Evaluating user expression (let* > ((services (map primitive-load (?))) # ?) ?) > > I'm pretty sure even if that message is normal, it's not normal for it > to be the last line you see. Perhaps the reconfigure is dying at that > point, or some point shortly after, without outputting any other > errors. Do you see a "bootloader successfully installed on ..." message earlier in the output? 5c8c8c455 changed the order that things are done in so that services are upgraded after the bootloader is installed. Regards, Jakob signature.asc Description: PGP signature
bug#36942: Reconfigure broke GRUB
Hi Danny, Danny Milosavljevic writes: > Hi, > > I've examined /var/guix/gcroots without #36947 and I get: > > lrwxrwxrwx 1 root root 18 24. Jul 11:32 profiles -> /var/guix/profiles > lrwxrwxrwx 1 root root 19 24. Jul 11:32 current-system -> > /run/current-system > lrwxrwxrwx 1 root root 18 24. Jul 11:32 booted-system -> /run/booted-system > lrwxrwxrwx 1 root root 26 29. Jul 22:26 bootcfg -> > //var/guix/gcroots/bootcfg > > So I guess I'm one "guix gc" away from also destroying my > installation. Was this fixed after applying #36947? > The double slash looks very suspicious... Any reason in particular? The second slash is there because '%gc-roots-directory' has a leading slash, and that gets appended to 'target', which in this case is '/'. Regards, Jakob signature.asc Description: PGP signature
bug#36876: guix system delete-generations removes custom boot menu entries
Hi Danny, Danny Milosavljevic writes: > Hi Jakob, > > keep in mind that switching back to a previous generation could also entail a > switch of bootloader projects. It does you no good to parse the grub config > to > find menu entries and then append them to u-boot. > > Fundamentally, it would be best if either the bootloader is part of the state > that guix manages (and each time uses), or it isn't; not both. > > Current situation: > > * If you select a previous generation in the boot menu, then the state that is > selected does NOT include the bootloader (i.e. it doesn't change the > bootloader > or the bootloader config). > > * If you do "guix system reconfigure", the state that is saved includes only > the bootloader in the boot sector (simplified) but not the bootloader > installer > or the bootloader derivation. > > * If you do "guix system delete-generations", the state that is restored does > not include the bootloader installer and previous bootloader configuration. > > Clearly, it's not nice to have these different things happen. > > It would be better if we retained the generation's bootloader installer > and bootloader config and reinstalled it on each of those. > > So, I would suggest to retain the following for each system generation: > > * The bootloader package derivation > * The bootloader config derivation > * The bootloader installer derivation > > And to install the bootloader each time using the latter. > > This introduces cycles--not sure whether that's a problem or not. > For the GC I think it's not a problem. Thank you for your comments -- after reading this and Jesse's suggestion, I'm quite confident that this is the way to go about it. Regards, Jakob signature.asc Description: PGP signature
bug#36942: Reconfigure broke GRUB
Hi ison, Thanks for opening a new ticket for tracking this. ison writes: > Continuing this issue from https://issues.guix.gnu.org/issue/36878 > > guix reconfigure recently broke GRUB for me. When rebooting I get > dropped to a "grub rescue>" shell with an error about > "grub_file_filters" being an unknown symbol. > If I try doing the usual commands to tell GRUB how to boot I just > see the above error repeated, or "unknown command" when I run > things such as insmod or "configfile". > > So to fix the problem I can boot to a Guix install disk and do > "guix init" which rebuilds the system using older package > definitions from the disk. > That allows me to get a working system, but if I do another > "guix pull" and reconfigure using the same config file it breaks > GRUB again when I reboot. "guix describe" shows that my latest > attempt was with commit 35600cd. > > Here is the bootloader and filesystem sections of my config: > (bootloader (bootloader-configuration > (bootloader grub-efi-bootloader) > (target "/boot/efi"))) > (file-systems (cons* (file-system > (device "/dev/sda2") > (mount-point "/boot/efi") > (type "vfat")) >(file-system > (device (file-system-label "guixsd-root")) > (mount-point "/") > (type "ext4")) >%base-file-systems)) This narrows it down quite a bit -- I suspect that we're broken for 'grub-efi-bootloader', since I've been able to successfully reconfigure with 'grub-bootloader' on both of my machines. > I should make a note that I usually don't use efi, and I'm not > completely confident it's all set up properly. I do have a > "BIOS boot" partition on /dev/sda1 too, is that even needed with > efi? I don't believe so. I think the ESP partition on /dev/sda2 is all you need. > Although, I have been using this setup, and the above > definitions, for about 6 months now without any bootloader or > filesystem issues. And the same config is being used to fix the > system when GRUB breaks as well as to reconfigure afterward > (causing the breakage). So my guess is some new update is the > culprit. It certainly sounds like it, and I'm the last person to have touched the bootloader installation code :) I'll look into this ASAP. Thanks again for the bug report! Regards, Jakob signature.asc Description: PGP signature
bug#36876: guix system delete-generations removes custom boot menu entries
Jesse Gibbons writes: > Alternatively, we could save in the store a derivation for the the grub > config generated from the bootloader of the configuration. When the > user calls "guix system delete-generations", the derivation can be run, > and the remaining system generations (if any) can be appended in a menu > like when the user calls "guix system reconfigure". (Although it does > not work for me right now, I'm assuming "guix system delete-generations > 2m" as described in the manual will be implemented in the future.) > > The immediate downsides I see to my solution: > > - It would take space in the store per generation, which can add up if > the user does not often call "guix system delete-generations" and calls > "guix system reconfigure" on a healthy basis. The user could just be > reminded to call "guix system delete-generations" occasionally, and any > official service that automatically updates the system via "guix > system reconfigure" can (and considering how large a generation with a > lot of updated system packages can get, probably should) also be > configured to call "guix system delete-generations". > > - If someone hand-edits the grub config the changes would be lost. This > is the case as it is right now, and grub options can be edited in the > configuration, so I'm not too concerned about this. > > -It would be much simpler to identify menu entries generated by guix > that are no longer in the store and remove them, and remove all empty > submenus. Parsing would make hand-editing grub.cfg more dangerous than > a solution that simply scraps the hand-made changes and rebuilds as I > propose, because the user doing the hand-editing would not necessarily > be aware what patterns the parser checks. It would also be > inconsitent: edits to grub.cfg being scrapped when "guix system > reconfigure" is called, but not when 'guix system delete-generations" > is called looks to me like a good way to introduce a bug to the more > adventurous "Murphy's Law"-type users down the road. I haven't tried it yet, but 'menuentry' seems as though it would be a fairly simple structure to parse. > These are just my thoughts. I would love to hear other downsides to my > solution. I prefer your suggestion to mine and think that the benefits may outweigh the costs in this case. This seems to fit into the Guix idea of purity a bit better than parsing a grub.cfg that may have been overwritten by another system. Regards, Jakob signature.asc Description: PGP signature
bug#36876: guix system delete-generations removes custom boot menu entries
Hi Jesse, Jesse Gibbons writes: > I dual-booted Guix with another gnu/linux-libre distro. > My configuration includes the other distro in the grub menu. When I run > "sudo guix system delete-generations" the changes to the grub menu drop > the other distro with the older system generations of guix. > > My current work-around for this is to run "guix system reconfigure ..." > which includes the boot menu entries specified in the configuration. Thanks for reporting this; it's a rather serious issue. The problem lies in the 'reinstall-bootloader' procedure. Chiefly, it uses the default bootloader configuration for whatever it can find using 'lookup-bootloader-by-name' and generates menu entries for the generations reachable from '%system-profile', which is quite a bit different from how 'guix system reconfigure' produces the bootloader configuration. It really isn't ideal. To quote a comment in 'system.scm': "[i]t will be enough to allow the system to boot." I don't think this should be _too_ hard to fix. To me, parsing the installed Grub configuration to get existing menu entries seems like a logical step forward. Thoughts from anyone else? Regards, Jakob signature.asc Description: PGP signature
bug#36878: guix system reconfigure broken
Hi ison and Ricardo, Ricardo Wurmus writes: > ison writes: > >> I made the mistake of rebooting my machine after I first got this >> error, I thought perhaps it was benign. But when it came back up I >> was dropped to a GRUB rescue shell with some error about >> "grub_file_filters" being an unknown symbol. > > This eems unrelated. The problem sounds like GRUB and its modules > aren’t found for some reason. It is unrelated to this specific issue, but it still does sound like my patch is the source of the problem. Would you be willing to open a separate ticket for tracking this, ison? >> When running grub commands like "insmod normal" would just repeat the error >> or say command not found. >> The only way I could think to repair it was to run the Guix install disk, >> mount my partitions, and do another "guix init" which allows me to boot into >> my machine again. However, when I run "guix pull" and then perform a >> reconfigure I still keep seeing the same line: >> shepherd: Evaluating user expression (let* ((services (map primitive-load >> (?))) # ?) ?) > > I reconfigured a workstation yesterday and also saw this line. It does > look like an error, but it seems to be completely harmless. I could > boot juts fine. I suppose that’s just the part where new service > definitions are loaded. > > The problem you’re seeing is unrelated to this output. Yes, this output is normal. Shepherd loads service files by evaluating Scheme expressions. I could have sworn that 'guix system reconfigure' showed the same line prior to my patch. ison -- I'm very sorry that you've had this experience. Would you be willing to share the 'bootloader' field of your operating system configuration so I can look into this? Regards, Jakob signature.asc Description: PGP signature
bug#36878: guix system reconfigure broken
zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes: > Great :) > > CC'ing Chris and Dave since I don't have write access -- can we > fast-track #36880 into master? I'd consider this to be a high-priority > bug fix. > > Regards, > Jakob The patch made it into master as 1db6f137d; thanks to Danny for signing off on it. Should we close this? Regards, Jakob signature.asc Description: PGP signature
bug#36878: guix system reconfigure broken
Robert Vollmert writes: > Yes, it seems it does! Great :) CC'ing Chris and Dave since I don't have write access -- can we fast-track #36880 into master? I'd consider this to be a high-priority bug fix. Regards, Jakob signature.asc Description: PGP signature
bug#36878: guix system reconfigure broken
Hi Robert, Robert Vollmert writes: > The concrete problem is this: > > 1. nginx is running with config file A > 2. make some change to nginx config > 3. run guix system reconfigure (which builds a new nginx config file B) > 4. run herd restart nginx > 5. nginx is still running with config file A > > After reverting this commit, if I perform these steps, I end up with > nginx running with config file B in 5. Okay, I see now. Thank you clarifying. Would you be willing to see if the patch provided by #36880 fixes this issue? > I still get a bootloader line. Great -- thanks for checking that for me! Regards, Jakob signature.asc Description: PGP signature
bug#36878: guix system reconfigure broken
Hi Robert, Robert Vollmert writes: > Hi, > > it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012 > > guix system: Reimplement 'reconfigure’. > > breaks guix system reconfigure. In particular, after reconfiguring, > shepherd doesn’t know about the updated versions of services. > > The usual output below is missing; after reverting the commit it’s > fine again. Could you please elaborate on what you mean by this? I can see that the ouput has changed, but is Shepherd doing something that indicates that it doesn't know about the new services? And is the line regarding bootloader installation also missing from 'guix system reconfigure' post-5c8c8c455? > I see that some system tests for “guix system reconfigure” were added > after this change. Might I suggest adding them before the change next > time around, and making sure they pass both before and after? Sure. My apologies for not having the foresight to do that. Regards, Jakob signature.asc Description: PGP signature
bug#36855: guix system switch-generation doesn't
Hi Robert, Robert Vollmert writes: > The line with “updated version” should not be there. > > Presumably, this is due to switch-generations not calling > upgrade-shepherd-services. I can confirm that 'switch-to-system-generation', the procedure that carries out 'guix system switch-generation', neither invokes 'upgrade-shepherd-services' nor runs that system's activation script. I'd be interested to hear from others who have worked on 'guix system' as to whether or not it would be a good idea to perform the effectful parts of a system activation for 'switch-generation'. I haven't yet pondered upon the implications. Regards, Jakob signature.asc Description: PGP signature
bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords
Ludovic Courtès writes: > "Jakob L. Kreuze" skribis: > >> Apologies, I should clarify -- the Guile for the S-Expression appears to be >> fine, but the Guile referenced in the shebang of the ungexp'd program-file >> does not reflect the system. > > Got it now. This is fixed by 2e8cabb8d630a8423e2e5a3bf150c1c0310b945d. > > Thanks! > > Ludo’. Just had the opportunity to test it out -- works great! Thanks, Ludo! Regards, Jakob signature.asc Description: PGP signature
bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords
Apologies, I should clarify -- the Guile for the S-Expression appears to be
fine, but the Guile referenced in the shebang of the ungexp'd program-file does
not reflect the system.
On July 26, 2019 11:37:20 AM EDT, "Jakob L. Kreuze"
wrote:
>Could you please try to reproduce using the example I provided? The
>derivation itself is handled appropriately, but its references are not.
>
>On July 26, 2019 11:28:11 AM EDT, "Ludovic Courtès"
>wrote:
>>zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:
>>
>>> Changing it to the following:
>>>
>>> #+BEGIN_SRC scheme
>>> (lower-gexp exp
>>> #:system "i686-linux"
>>> #:target "i686-unknown-linux-gnu"
>>> #:guile-for-build #f)
>>> #+END_SRC
>>>
>>> The Guile used is still a 64-bit LSB executable.
>>
>>I can’t reproduce it on current ‘master’:
>>
>>--8<---cut here---start->8---
>>scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3)
>>#:guile-for-build #f #:system "mips64el-linux")
>>$6 = #< sexp: (+ 2 3) inputs: () sources: () guile:
>>#< drv: #>/gnu/store/jsnihqsz6nxwv88pr41i2y3403f959cf-guile-2.2.4.drv =>
>>/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug
>>/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230>
>>sub-derivations: ("out")> load-path: () load-compiled-path: ()>
>>scheme@(guile-user)> (derivation-system (derivation-input-derivation
>>(lowered-gexp-guile $6)))
>>$7 = "mips64el-linux"
>>--8<---cut here---end--->8---
>>
>>Not even when cross-compiling (BTW, #:target probably doesn’t make
>>sense
>>above, since it’s cross-compiling from i686 to i686):
>>
>>--8<---cut here---start->8---
>>scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3)
>>#:guile-for-build #f #:system "mips64el-linux" #:target "i586-pc-gnu")
>>$8 = #< sexp: (+ 2 3) inputs: () sources: () guile:
>>#< drv: #>/gnu/store/jsnihqsz6nxwv88pr41i2y3403f959cf-guile-2.2.4.drv =>
>>/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug
>>/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230>
>>sub-derivations: ("out")> load-path: () load-compiled-path: ()>
>>scheme@(guile-user)> (derivation-system (derivation-input-derivation
>>(lowered-gexp-guile $8)))
>>$9 = "mips64el-linux"
>>--8<---cut here---end--->8---
>>
>>Am I missing something?
>>
>>Thanks,
>>Ludo’.
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords
Could you please try to reproduce using the example I provided? The derivation
itself is handled appropriately, but its references are not.
On July 26, 2019 11:28:11 AM EDT, "Ludovic Courtès" wrote:
>zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:
>
>> Changing it to the following:
>>
>> #+BEGIN_SRC scheme
>> (lower-gexp exp
>> #:system "i686-linux"
>> #:target "i686-unknown-linux-gnu"
>> #:guile-for-build #f)
>> #+END_SRC
>>
>> The Guile used is still a 64-bit LSB executable.
>
>I can’t reproduce it on current ‘master’:
>
>--8<---cut here---start->8---
>scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3)
>#:guile-for-build #f #:system "mips64el-linux")
>$6 = #< sexp: (+ 2 3) inputs: () sources: () guile:
>#< drv: #/gnu/store/jsnihqsz6nxwv88pr41i2y3403f959cf-guile-2.2.4.drv =>
>/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug
>/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230>
>sub-derivations: ("out")> load-path: () load-compiled-path: ()>
>scheme@(guile-user)> (derivation-system (derivation-input-derivation
>(lowered-gexp-guile $6)))
>$7 = "mips64el-linux"
>--8<---cut here---end--->8---
>
>Not even when cross-compiling (BTW, #:target probably doesn’t make
>sense
>above, since it’s cross-compiling from i686 to i686):
>
>--8<---cut here---start->8---
>scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3)
>#:guile-for-build #f #:system "mips64el-linux" #:target "i586-pc-gnu")
>$8 = #< sexp: (+ 2 3) inputs: () sources: () guile:
>#< drv: #/gnu/store/jsnihqsz6nxwv88pr41i2y3403f959cf-guile-2.2.4.drv =>
>/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug
>/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230>
>sub-derivations: ("out")> load-path: () load-compiled-path: ()>
>scheme@(guile-user)> (derivation-system (derivation-input-derivation
>(lowered-gexp-guile $8)))
>$9 = "mips64el-linux"
>--8<---cut here---end--->8---
>
>Am I missing something?
>
>Thanks,
>Ludo’.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords
Hi Ludo, Ludovic Courtès writes: > Note: #:target must be a “GNU triplet” like “arm-linux-gnueabihf”, not > a system type like “i686-linux”. Thanks, is 'nix-system->gnu-triplet' the suggested way of obtaining the triplet for a system? > That’s because the Guile used here comes from the #:guile-for-build > parameter. > > So the caller is responsible for doing the right thing here. In fact, > if you do: > > (lower-gexp exp #:system whatever #:guile-for-build #f) > > it will automatically take care of computing the right Guile for this > system. For consistency, I don’t think we should change the default, > though. > > WDYT? Changing it to the following: #+BEGIN_SRC scheme (lower-gexp exp #:system "i686-linux" #:target "i686-unknown-linux-gnu" #:guile-for-build #f) #+END_SRC The Guile used is still a 64-bit LSB executable. Similarly, the that's ungexp'd has a profile containing x86_64 executables. jakob@Epsilon ~ $ readlink /gnu/store/6z5hdxjr8db4qm4d578lly3l87mlgkpv-system/profile/bin/* | xargs file /gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin/[: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped /gnu/store/9y5cvqnincp2ax5kxyv43zr7gdd89vs2-man-db-2.8.5/bin/apropos: symbolic link to whatis /gnu/store/lm3i15cvw4ybsnf2lsam5nj76kqbjg2k-libtasn1-4.13/bin/asn1Coding: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped /gnu/store/lm3i15cvw4ybsnf2lsam5nj76kqbjg2k-libtasn1-4.13/bin/asn1Decoding: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped /gnu/store/lm3i15cvw4ybsnf2lsam5nj76kqbjg2k-libtasn1-4.13/bin/asn1Parser: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped ... Regards, Jakob
bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords
Hi, I believe there is an issue with 'lower-gexp'. Running the following snippet to lower a G-Expression for "i686-linux" yields output that references store paths built for x86_64. In this case, the Guile interpreter used is an x86_64 binary. #+BEGIN_SRC scheme (define (display-exp exp) (mlet* %store-monad ((lowered (lower-gexp exp #:system "i686-linux" #:target "i686-linux")) (to-build -> (cons (lowered-gexp-guile lowered) (lowered-gexp-inputs lowered))) (_ (built-derivations to-build))) (return (format #t "~a~%" (lowered-gexp-sexp lowered) (with-store store (run-with-store store (display-exp #~(primitive-load #$(switch-system-program %system) #+END_SRC jakob@Epsilon ~ $ guile ~/test.scm (primitive-load /gnu/store/v7v1b7375j9j82dvfycv56v36nv5jq3y-switch-to-system.scm) jakob@Epsilon ~ $ cat /gnu/store/v7v1b7375j9j82dvfycv56v36nv5jq3y-switch-to-system.scm #!/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile --no-auto-compile !# ... jakob@Epsilon ~ $ file /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped This doesn't seem to be an issue if '%current-system' is parameterized, as in the following. #+BEGIN_SRC scheme (parameterize ((%current-system "i686-linux")) (with-store store (run-with-store store (display-exp #~(primitive-load #$(switch-system-program %system)) #+END_SRC Regards, Jakob signature.asc Description: PGP signature
bug#36517: 'guix deploy' does not restart services
Heyo, Ludovic Courtès writes: > Oh, I see. To me that’s completely orthogonal to ‘guix deploy’ though, > in that ‘guix system reconfigure’ and ‘guix deploy’ should use the > same code for that. > > Thanks, > Ludo’. Yeah, I believe it would be safe to close this once the code for 'guix deploy' and 'guix system reconfigure' is unified. I opened this under the impression that the two would remain separate and individual changes would need to occur for both. Regards, Jakob signature.asc Description: PGP signature
bug#36517: 'guix deploy' does not restart services
Hi, Ludovic! Ludovic Courtès writes: > Hi, > > zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis: > >> This issue is described in more detail at [1]. Essentially, 'guix >> deploy' is will happily load and start new services, as well as unload >> obsolete services, but does nothing to restart valid services that are >> already running. > > That’s not a bug: ‘guix system reconfigure’ does not restart already > running services, simply because it cannot tell whether now is a good > time to restart them. It’s a decision that’s left to the system > administrator. > > However, note that ‘guix system reconfigure’ loads “replacements” for > each Shepherd service, such that next time you run ‘herd restart FOO’, > you spawn that new version of FOO. > > Does that make sense? Yes, that does make sense. I suppose the way I worded the initial report wasn't great; I opened this to track support for 'restart-strategy' as described in #33508 in 'guix deploy'. This takes care of the question of when a good time to restart the service would be. Regards, Jakob signature.asc Description: PGP signature
bug#36517: 'guix deploy' does not restart services
This issue is described in more detail at [1]. Essentially, 'guix deploy' is will happily load and start new services, as well as unload obsolete services, but does nothing to restart valid services that are already running. I can assign myself to this issue. Just filing for tracking purposes :] Regards, Jakob [1]: https://lists.gnu.org/archive/html/guix-patches/2019-06/msg00567.html signature.asc Description: PGP signature
bug#36364: Potential SSH session exhaustion
Hi, Ludovic Courtès writes: > Procedures like ‘send-files’ call ‘channel-get-exit-status’ and > ‘close-port’ on ports that represent SSH channels. > > AFAICS, ‘close-port’ triggers a call of ‘ptob_close’ in Guile-SSH, > which in turn calls ‘ssh_channel_close’. > > sshd_config(5) says: > >MaxSessions Specifies the maximum number of open shell, login or subsystem > (e.g. sftp) sessions permitted per network connection. Multiple sessions may > be > established by clients that support connection multiplexing. Setting > MaxSessions > to 1 will effectively disable session multiplexing, whereas setting it to 0 > will > prevent all shell, login and subsystem sessions while still permitting > forwarding. The default is 10. > > So you must be hitting this limit. Ah, thank you for the corrections :) > I see that ‘remote-eval’ does not close ‘remote’ though, so this > channel port remains open until it’s GC’d, which happens too late. > Could you try the attached patch? It allows me to do more than 10 > ‘remote-eval’ calls in a row. Wow, that was quick. The patch works like a charm, thanks! Regards, Jakob signature.asc Description: PGP signature
bug#36364: Potential SSH session exhaustion
Hello, Guix In developing a test suite for the internals of 'guix deploy', the virtual machine I spun up spat out an OpenSSH error that I've never encountered before. Jun 24 16:59:26 localhost sshd[235]: error: no more sessions This is, initially, quite curious. Creating the SSH session with #:log-verbosity set to 'protocol gives some insight. ;;; [2019/06/24 13:08:36.711847, 2] channel_open: Creating a channel 43 with 64000 window and 32768 max packet ;;; [2019/06/24 13:08:36.711959, 2] ssh_packet_global_request: Received SSH_MSG_GLOBAL_REQUEST packet ;;; [2019/06/24 13:08:36.711987, 2] ssh_packet_global_request: UNKNOWN SSH_MSG_GLOBAL_REQUEST hostkeys...@openssh.com 0 ;;; [2019/06/24 13:08:36.712010, 1] ssh_packet_process: Couldn't do anything with packet type 80 ;;; [2019/06/24 13:08:36.712197, 2] ssh_packet_channel_open_conf: Received a CHANNEL_OPEN_CONFIRMATION for channel 43:0 ;;; [2019/06/24 13:08:36.712219, 2] ssh_packet_channel_open_conf: Remote window : 0, maxpacket : 32768 ;;; [2019/06/24 13:08:36.712618, 2] channel_rcv_change_window: Adding 2097152 bytes to channel (43:0) (from 0 bytes) ;;; [2019/06/24 13:08:36.712651, 2] channel_request: Channel request exec success ... ;;; [2019/06/24 12:59:26.296022, 2] channel_open: Creating a channel 74 with 64000 window and 32768 max packet ;;; [2019/06/24 12:59:26.296262, 2] ssh_packet_channel_open_conf: Received a CHANNEL_OPEN_CONFIRMATION for channel 74:8 ;;; [2019/06/24 12:59:26.296308, 2] ssh_packet_channel_open_conf: Remote window : 0, maxpacket : 32768 ;;; [2019/06/24 12:59:26.296667, 2] channel_rcv_change_window: Adding 2097152 bytes to channel (74:8) (from 0 bytes) ;;; [2019/06/24 12:59:26.296721, 2] channel_request: Channel request exec success ;;; [2019/06/24 12:59:26.487339, 2] grow_window: growing window (channel 74:8) to 128 bytes ;;; [2019/06/24 12:59:26.489031, 2] channel_open: Creating a channel 75 with 64000 window and 32768 max packet ;;; [2019/06/24 12:59:26.489376, 2] ssh_packet_channel_open_conf: Received a CHANNEL_OPEN_CONFIRMATION for channel 75:8 ;;; [2019/06/24 12:59:26.489402, 2] ssh_packet_channel_open_conf: Remote window : 0, maxpacket : 32768 ;;; [2019/06/24 12:59:26.489858, 2] channel_rcv_change_window: Adding 2097152 bytes to channel (75:8) (from 0 bytes) ;;; [2019/06/24 12:59:26.489906, 2] channel_request: Channel request exec success ;;; [2019/06/24 12:59:26.542586, 2] grow_window: growing window (channel 75:8) to 128 bytes ;;; [2019/06/24 12:59:26.546104, 2] channel_open: Creating a channel 76 with 64000 window and 32768 max packet ;;; [2019/06/24 12:59:26.546407, 2] ssh_packet_channel_open_conf: Received a CHANNEL_OPEN_CONFIRMATION for channel 76:9 ;;; [2019/06/24 12:59:26.546438, 2] ssh_packet_channel_open_conf: Remote window : 0, maxpacket : 32768 ;;; [2019/06/24 12:59:26.546839, 2] channel_rcv_change_window: Adding 2097152 bytes to channel (76:9) (from 0 bytes) ;;; [2019/06/24 12:59:26.546865, 2] channel_request: Channel request exec success ;;; [2019/06/24 12:59:26.630055, 2] grow_window: growing window (channel 76:9) to 128 bytes ;;; [2019/06/24 12:59:27.272139, 2] channel_open: Creating a channel 77 with 64000 window and 32768 max packet ;;; [2019/06/24 12:59:27.272846, 1] ssh_packet_channel_open_fail: Channel opening failure: channel 77 error (2) open failed I will admit that my knowledge of the SSH protocol is limited, but the rising channel number gives me the impression that channels are going out of scope and aren't being cleaned up. For reference, this occurs when 'remote-eval' is invoked multiple times -- which, in turn, invokes 'send-files'. building path(s) `/gnu/store/3rfkwdbayg7m3wdrydmcljnfqhvrady5-remote-exp.scm' sending 1 store item (0 MiB) to 'localhost'... exporting path `/gnu/store/3rfkwdbayg7m3wdrydmcljnfqhvrady5-remote-exp.scm' building path(s) `/gnu/store/ib59b0pnypsw4vf59f2gwpwhn343xnzb-remote-exp.scm' sending 1 store item (0 MiB) to 'localhost'... exporting path `/gnu/store/ib59b0pnypsw4vf59f2gwpwhn343xnzb-remote-exp.scm' [this is where the "no more sessions" error occurs] Currently, my code performs all of these 'remote-eval' calls with the same session. I suppose it would be possible to create a new session for each call, but I feel I should raise this as it may cause issues down the line: do we need to do something about cleaning up SSH channels? If a reproducible example is necessary, you can look to the temporary 'tests/machine.scm' in 64ffe453b0c71f417927737fa808dffe858359cd on my personal branch.[1] Regards, Jakob [1]: https://git.sr.ht/~jakob/guix/ signature.asc Description: PGP signature
bug#35904: Rx 580 and Guix
The "[drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel modesetting." in your dmesg output comes from the 'nomodeset' parameter. If possible, I'd try setting up an SSH daemon, removing 'nomodeset' from your kernel command-line, and getting dmesg output remotely. (I assume you don't get any screen output without 'nomodeset'.) I had the same issue with my RX460. Modesetting (to my knowledge) isn't possible without the nonfree firmware, so I just gave in and created a package for the blobs. There _may_ be a way to use your card without the firmware, but if there is, I'm not aware of it. Sorry :< Jakob (Apologies if you're receiving this twice, Gnus quit out on me as I was sending this).
