bug#20024: grub store is not copied to target system
Tomáš Čech skribis: > TL;DR > I run `guix system init' from Gentoo to separate partition to > _init_ root filesystem and after reboot to boot into GuixSD. OK, that’s not what I had understood, so thanks for bearing with me! ;-) >>But! Beware that GuixSD wants to own /etc. So in practice, when you >>boot GuixSD, it may override most of the files in there with its own (it >>might also bork of some of its assumptions do not hold, like if Gentoo >>left files in /etc that it doesn’t expect to see.) So the next time you >>boot into Gentoo, Gentoo will basically be somewhat broken. >> >>IOW, using ‘guix system init’ on the current root should be thought of >>as a one-way transition. It’s not documented because it’s brittle and >>it’s most likely not what you want. > > Yes, that would be way to hell. So the better solution can be putting > /gnu on separate partition and share it among the systems like you can > do for /home, /boot etc. Possibly, yes. > Let me the whole bug rephrase into single simple question: > > Shouldn't `grub' be in `%base-packages'? It could be there; OTOH, we don’t want to encourage users to bypass ‘reconfigure’. WDYT? Is it really the only thing you were asking for? If yes, I think we could have been more efficient in our communication. :-) I just realized that I misread “grub store is not copied” in the title as “/gnu/store is not copied.” Sorry for the confusion. Ludo’.
bug#20024: grub store is not copied to target system
On Tue, Mar 10, 2015 at 08:58:07AM +0100, Ludovic Courtès wrote: Tomáš Čech skribis: TL;DR I run `guix system init' from Gentoo to separate partition to _init_ root filesystem and after reboot to boot into GuixSD. OK, that’s not what I had understood, so thanks for bearing with me! ;-) But! Beware that GuixSD wants to own /etc. So in practice, when you boot GuixSD, it may override most of the files in there with its own (it might also bork of some of its assumptions do not hold, like if Gentoo left files in /etc that it doesn’t expect to see.) So the next time you boot into Gentoo, Gentoo will basically be somewhat broken. IOW, using ‘guix system init’ on the current root should be thought of as a one-way transition. It’s not documented because it’s brittle and it’s most likely not what you want. Yes, that would be way to hell. So the better solution can be putting /gnu on separate partition and share it among the systems like you can do for /home, /boot etc. Possibly, yes. Let me the whole bug rephrase into single simple question: Shouldn't `grub' be in `%base-packages'? It could be there; OTOH, we don’t want to encourage users to bypass ‘reconfigure’. WDYT? Aha! Now it makes sense! Yes, you're right, but there is also chance that after initialization of GuixSD and reboot you will have no way back to original distribution. I understand that that is probably just corner case and typical Guix user (yay! :) would just reboot to the image he used for installation... After my installation I got into state where Guix couldn't access network so `guix system reconfigure' was not possible and my graphic card needs some special care during boot to make KMS work (which I was hardly googling on tablet to fix it). We could just add note in documentation that one can add grub as system package as safety belt and remove it when confirmed it works. OTOH this may encourage users to bypass reconfigure even more. Is it really the only thing you were asking for? If yes, I think we could have been more efficient in our communication. :-) I'm afraid that yes. I wasn't able to say it in this simple way before as I didn't know the reason. And yes, I'll do my best to explain it better next time. I just realized that I misread “grub store is not copied” in the title as “/gnu/store is not copied.” Sorry for the confusion. I'm glad we finally made it clear :) Best regards, S_W pgpajHLSi9za_.pgp Description: PGP signature
bug#19015: Fixed
Fixed in commit 2cb4ca6 by remove asla-lib from inputs. SDL_mixer do a testing for libmikmod using libmikmod-config. libmikmod-config.in has: --libs) echo -L@libdir@ -lmikmod @LIBRARY_LIB@ When built with alsa driver support, @LIBRARY_LIB@ become "-lm -lasound", require alsa-lib presented to get the test success. But in fact the use of libmikmod library don't depends on the drivers (alsa), and the libmikmod.pc file doesn't have them in Libs (and Libs.private). So I think it's a bug where @LIBRARY_LIB@ contains '-lasound'. Instead of dropping @LIBRARY_LIB@ from libmikmod-config.in, I notice that the only user of libmikmod is sdl-mixer, which use it's own audio output drivers. So I'm temped to remove alsa-lib from libmikmod (the libx11 is unused IIRC).
bug#20024: grub store is not copied to target system
Tomáš Čech skribis: > On Tue, Mar 10, 2015 at 08:58:07AM +0100, Ludovic Courtès wrote: >>Tomáš Čech skribis: [...] >>> Shouldn't `grub' be in `%base-packages'? >> >>It could be there; OTOH, we don’t want to encourage users to bypass >>‘reconfigure’. WDYT? > > Aha! Now it makes sense! > > Yes, you're right, but there is also chance that after initialization of > GuixSD and reboot you will have no way back to original distribution. As I wrote before, once you’ve booted into GuixSD, chances are that the original distro on that partition is in a bad state because GuixSD has fiddle with /etc and other global directories. > After my installation I got into state where Guix couldn't access network so > `guix system reconfigure' was not possible and my graphic card needs some > special care during boot to make KMS work (which I was hardly googling on > tablet to fix it). Could you explain the KMS issue in a separate thread? > We could just add note in documentation that one can add grub as system > package as safety belt and remove it when confirmed it works. OTOH this may > encourage users to bypass reconfigure even more. It’s enough to modify grub.cfg. GRUB itself is not needed. But anyway, the take-home message is that if you run ‘guix system init’ on your current root, then you can assume the former distro to no longer be bootable. Thanks, Ludo’.
bug#20024: grub store is not copied to target system
On Tue, Mar 10, 2015 at 11:54:53AM +0100, Ludovic Courtès wrote: Tomáš Čech skribis: On Tue, Mar 10, 2015 at 08:58:07AM +0100, Ludovic Courtès wrote: Tomáš Čech skribis: [...] Shouldn't `grub' be in `%base-packages'? It could be there; OTOH, we don’t want to encourage users to bypass ‘reconfigure’. WDYT? Aha! Now it makes sense! Yes, you're right, but there is also chance that after initialization of GuixSD and reboot you will have no way back to original distribution. As I wrote before, once you’ve booted into GuixSD, chances are that the original distro on that partition is in a bad state because GuixSD has fiddle with /etc and other global directories. Irrelevant. As I wrote before - I have two separate partitions with root filesystem. Problem is that when `guix system init' takes care of grub configuration. After my installation I got into state where Guix couldn't access network so `guix system reconfigure' was not possible and my graphic card needs some special care during boot to make KMS work (which I was hardly googling on tablet to fix it). Could you explain the KMS issue in a separate thread? Irrelevant. It is not related to Guix and it may be even fixed already in vanilla. We could just add note in documentation that one can add grub as system package as safety belt and remove it when confirmed it works. OTOH this may encourage users to bypass reconfigure even more. It’s enough to modify grub.cfg. GRUB itself is not needed. But anyway, the take-home message is that if you run ‘guix system init’ on your current root, then you can assume the former distro to no longer be bootable. No, I'm initializing GuixSD root filesystem, not the Gentoo one. Lets just stop to avoid further confusion. I take it that my usecase is corner case and I should add grub as system package by myself. My goal was to consider providing grub and you have your reasons. And it looks like I have too weird setup - separate /boot, LVM, bootloader chainloading. I have found my way to workaround it. Please close the bug. pgpkGYJo3xnDa.pgp Description: PGP signature
bug#20025: user in ratpoison doesn't have access to guix by default
On Sun, Mar 08, 2015 at 11:09:13PM +0100, Ludovic Courtès wrote:
tc...@suse.cz skribis:
After booting into Guix I used slim to login into Ratpoison and I run
there terminal emulator. `guix' wasn't available in current PATH
settings so user couldn't maintain his profile.
I believe that /run/current-system/profile/bin/ should be added to PATH.
AFAICS it is.
Could it be that the account’s .bash_profile fails to source
/etc/profile, or something like that (info "(bash) Bash Startup Files")?
See /etc/skel/.bash{rc,_profile} as examples.
As my config file changed, I'm no longer able to reproduce it. If there is
such bug, it will reappear in future.
Please close the bug.
pgpuKOOenKANL.pgp
Description: PGP signature
bug#20071: none
On Fri, Dec 05, 2014 at 09:35:42AM +0100, Tomas Cech wrote: At Fri, 05 Dec 2014 00:04:23 +0100, Ludovic Courtès wrote: Tomas Cech skribis: > I tried to install Guix as alternative OS to my Gentoo and openSUSE > installations to give a try. I tried unsupported scenario - > installation on LVM volume and separate /boot partition until I was > told it is unsupported. Separate boot wasn't hard as I had to just > copy generated files so they are loaded. OK, but there’s still an open bug on that topic. :-) http://bugs.gnu.org/19220 Good, I'll give a try again. > 1] if you set device to partition (and not to disk) in your grub-configuration like this: > > (bootloader (grub-configuration >(device "/dev/sda4"))) Why would you want to use a partition and not a disk? I didn’t know this was even possible. Because this way I can separate Grub managed by Guix and Grub from my Gentoo. As I'm playing with that on my notebook I need for work, this way can reduce risks. I'm not sure how Guix installer can manipulate with grub.cfg and I'd like to always have some working system... > `guix system init' will fail on grub installation. By default Grub > tries to fit in the beginning of partition and fails if it can't fit > in. I asked about this behaviour on Grub mailing list and it seems > that there are two options: > > a] add `--force' to command line and use block list for keeping information about position of Grub's core.img > b] use filesystem which allows embedding - BtrFS or ZFS > > I verified both options (a] and then b] with BtrFS) and it no longer fails. > > But, > ad a] - I don't feel safe passing `--force' to grub-install every > time. So if installation fails on this point and you'd like to use > your FS anyway, you can pass `--no-grub' to `guix system init' and > then rung grub-install manually. > > ad b] - I don't feel safe using still experimental BtrFS. OK. I think the conclusion for Guix is to leave the defaults unchanged. Perhaps we could add a ‘force?’ field to the ‘grub-configuration’ data type to allow those who know what they doing to get the effect of ‘--force’. WDYT? After giving some more thoughts and after more experience with the process I do agree that exposing `--force' parameter into grub-configuration is good idea. I'm filing bug for that. pgpC3l4OROYuc.pgp Description: PGP signature
bug#20024: grub store is not copied to target system
Tomáš Čech skribis: > I take it that my usecase is corner case and I should add grub as system > package by myself. My goal was to consider providing grub and you have your > reasons. And it looks like I have too weird setup - separate /boot, LVM, > bootloader chainloading. I have found my way to workaround it. Hmm OK. GuixSD doesn’t support LVM though (although that would be nice!), so I guess there’s another part of the story that I’m not aware of. > Please close the bug. Done. Apologies if that discussion frustrated you, I tried hard to understand and address the issue. Thanks, Ludo’.
bug#20025: user in ratpoison doesn't have access to guix by default
Tomáš Čech skribis:
> On Sun, Mar 08, 2015 at 11:09:13PM +0100, Ludovic Courtès wrote:
>>tc...@suse.cz skribis:
>>
>>> After booting into Guix I used slim to login into Ratpoison and I run
>>> there terminal emulator. `guix' wasn't available in current PATH
>>> settings so user couldn't maintain his profile.
>>>
>>> I believe that /run/current-system/profile/bin/ should be added to PATH.
>>
>>AFAICS it is.
>>
>>Could it be that the account’s .bash_profile fails to source
>>/etc/profile, or something like that (info "(bash) Bash Startup Files")?
>>See /etc/skel/.bash{rc,_profile} as examples.
>
> As my config file changed, I'm no longer able to reproduce it. If there is
> such bug, it will reappear in future.
>
> Please close the bug.
Thanks.
Ludo'.
bug#20037: 'guix system reconfigure' without 'gnu/system/linux.go' fails with duplicates login pam-service
宋文武 skribis: > I can reproduce the issue Tomáš Čech (Sleep_Walker) reported at IRC, > but only when reconfigure under 'pre-inst-env' and without > 'gnu/system/linux.go': Thanks a lot for finding it out, it’s an interesting bug! The problem was that ‘pam-service->directory’ would get a different list of objects depending on whether (gnu packages linux) is evaluated or running from bytecode: when evaluated, the list would contain duplicate services, leading to the build error you reported, but when running from bytecode, the list is deduplicated. This is because (gnu system) would call ‘delete-duplicates’ on the list of PAM services, thereby using ‘equal?’ to compare them. But since include gexps, which include closures, ‘equal?’ could return #t when running the compiled code (because in effect the gexps in ‘unix-pam-service’ would not lead to the allocation of fresh closures at each call, so the gexps would be ‘eq?’), whereas with the evaluated code, it would systematically return #f (we get fresh closures at each ‘unix-pam-service’ call.) Commit 118 fixes that. Thanks to both of you! Ludo’.
