Re: `guix pull` fails after fresh install
Please ignore my previous message in this thread, i sent the wrong version... Here's the right one: I was able to fix it! Yay Because this mailing list is a resource for people seeking help I'll hereby take the liberty to document how I tracked the issue down and fixed it. I added a new user to find out if the problem was reproducible and whether the system was to blame. This was luckily not the case. `guix pull` worked for the freshly added user 'test'. But I found the following differences: both /var/guix/profiles/per-user/user/current-guix and /home/user/.config/guix/current were real directories, whereas for the new 'test' user at the corresponding paths there were symlinks: the former pointing to current-guix-1-link in the same directory while the latter pointed to the former. Also, there is no file called `current-guix-0-link` in /var/guix/profiles/per-user/user/, but `current-guix` in the same directory points to that. I guessed this was most probably causing the issue. If I understand correctly guix stores two kinds of of symlinks in user-profiles (which live in /var/guix/profiles/per-user/): 1. current-guix-N-link: links to guix profiles (which contain guix and guix-daemon executables and info files), 2. guix-profile-N-link: links to package profile generations (which contain all installed programs including libraries, executables and documentation) and for each of those link-types one special link (current-guix and guix-profile) pointing to the currently active one of their kind. My guix-profile links seemed to be fine, but my suspicion grew that I'd have to replace the aforementioned directories with symlinks to the right places. Only problem: I did't know which is the "right" current-guix profile to link to. But since my installation is just some days old I figured there shouldn't be too much of a difference between the different guix versions on my machine and just linked to the one which /var/guix/profiles/per-user/test/current-guix-0-link pointed to. I tested with `guix pull` which worked just fine. Pleased with the outcome I happily `guix package upgrade`d my profile.
Re: `guix pull` fails after fresh install
I was able to fix it! Because this mailing list is a resource for people seeking help I'll feel free to describe how i tracked the issue down and fixed it. I added a new user (through a change in the system config and `guix system reconfigure) to figure out if the problem also exists for new users, and if not, what the differences to my profile were. and found the following differences:
Re: Librem Mini with pureboot/head don't boot GuixSD
Hello Roland, Em quinta-feira, 19 de agosto de 2021, às 11:57:45 -03, Roland Everaert escreveu: > I manage to successfuly copy the needed files to /boot using the `for > each` loop from ‘%copy-kernel-and-initrd’, Thank You. That’s great! > However, I need to resize (i.e. reduce) the root filesystem so /boot can > live in its own one. Currently, copying the kernel files too /boot is > useless, as HEAD will scan and sign all the files in /, anyway. > > Did you have any article discussing such process? > > I find plenty of articles about increasing the root partition, but, none > to reduce it. > > As the root partition cannot be unmounted online, I need to know if there > is a simple way to "switch to an offline mode of sort". For example, I > could map a minimal root FS in memory and chroot to it. An other > possibility is to copy a guix system to a USB drive and boot from it. > > The USB option seems the easiest, but the one with the RAMFS seems neat. > > What are the recommandations of the fine folks on this ML, for such > operation? I don’t have any resource about how to shrink a partition and its filesystem. I would boot into some distro’s live image and do it from there. Shrinking a partition is dangerous and error-prone because there are two steps: 1. Shrink the filesystem 2. Shrink the partition If you get the size calculation wrong in step 2 you’ll end up cutting off the end of your filesystem and thus corrupt it. So I believe the recommended practice is to always shrink the partition to be slightly bigger than the filesystem to make sure you don’t take that risk. You can then optionally grow back the filesystem to fill the slack space (filesystem resizing tools can automatically calculate the correct size to fill the partition). Since this is a risky operation, you have to make sure you have backups of everything. And since you need to do that, to be honest what I would *really* do is wipe everything out, repartition the disk to the new layout and then restore from backups... -- Thanks, Thiago
Re : Re: Librem Mini with pureboot/head don't boot GuixSD
Hello Thiago, I manage to successfuly copy the needed files to /boot using the `for each` loop from ‘%copy-kernel-and-initrd’, Thank You. However, I need to resize (i.e. reduce) the root filesystem so /boot can live in its own one. Currently, copying the kernel files too /boot is useless, as HEAD will scan and sign all the files in /, anyway. Did you have any article discussing such process? I find plenty of articles about increasing the root partition, but, none to reduce it. As the root partition cannot be unmounted online, I need to know if there is a simple way to "switch to an offline mode of sort". For example, I could map a minimal root FS in memory and chroot to it. An other possibility is to copy a guix system to a USB drive and boot from it. The USB option seems the easiest, but the one with the RAMFS seems neat. What are the recommandations of the fine folks on this ML, for such operation? Roland Everaert --- Use the F.O.S.S., Luke Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ Le samedi 14 août 2021 à 21:30, Thiago Jung Bauermann a écrit : > Hello, > > Em sábado, 14 de agosto de 2021, às 08:23:17 -03, Roland Everaert via > > escreveu: > > > The good news, I manage to boot the system. > > Nice! > > > I can apply your suggested workaround, but I will need some help to > > > > understand how to adapt /etc/config.scm to copy the kernel to /boot, if > > > > it is possible, from the configuration file. > > You could use ‘%copy-kernel-and-initrd’ from here as a basis: > > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/ > > berlin.scm#n97 > > If you change “/store” to “/boot” in the code perhaps it will work in your > > case. > > --- > > Thanks, > > Thiago
Re: guix pack and exposing ports
Thanks Edouard! So far I'm trying to follow the route where additional things are built on top of the existing image. Also managed to trim the image to a very bearable ~150Mb once I trimmed the manifest to bare necessities. ‐‐‐ Original Message ‐‐‐ On Thursday, August 19th, 2021 at 11:40 AM, Edouard Klein wrote: > Hi ! > > From what I know, with guix pack you can only have the dependencies in > > the docker image, but you won't have anything to start or manage your > > software automatically. You need to invoke the correct command (with > > docker run, I believe). > > What you can do is create an operating-system declaration and use the > > guix system docker-image subcommand. Note that this is way more > > involved, as you need to create a shepherd service for your software. > > I quickly ran into docker limitations following this route, but > > depending on what you want to do this may be the way to go. > > The alternative is to use the guix pack image as the base image in a > > standard dockerfile. > > As for the size of the image, see this thread > > https://lists.gnu.org/archive/html/help-guix/2021-07/msg00064.html > > Good luck > > Todor Kondić writes: > > > Hello, > > > > Please bear with me since I am not that very docker savvy. As far as I > > understand, normally, one can expose certain ports in a docker description > > file. But, how to do that when using `guix pack -f docker` command where > > the docker recipe is hidden from the user? > > > > Also, I note I'm getting ~10 GiG image for a flimsy program depending on R > > and shiny. Somehow that doesn't feel right. :)
