On Mon, Mar 09, 2015 at 06:00:24PM +0100, Ludovic Courtès wrote:
Tomas Cech <sleep_wal...@suse.cz> skribis:I'm afraid that I don't understand the relation between `guix system init' and `guix system reconfigure' you insist on. My understanding was, that `guix system init' will create new system in subdirectory as it is described in manual (6.1.4 Proceeding with the Installation).‘guix system init’ initializes a GuixSD root file system. It is typically used from the USB installation image. Conversely, ‘guix system reconfigure’ is used to reconfigure an already installed GuixSD system, with the untold assumption that the root partition remains the same (which is reasonable, IMO.)
Thank you for your verification. It means I understand it correctly. I reread whole bug again and I couldn't find the reason you even consider me using `guix system reconfigure'. My assumption is that you didn't expect me to have Guix on my Gentoo. Guix is (as you have to know the best) non-intrusive for OS so I have standard Gentoo installation and Guix built from GIT and installed to system. Binaries are in /gnu/store so it is not colliding with the rest of my system. I'll keep that in mind to mention it better in future bugs. Sorry for confusion. TL;DR I run `guix system init' from Gentoo to separate partition to _init_ root filesystem and after reboot to boot into GuixSD.
Seriously, I don’t think we’d want it to automagically migrate the store.How does it differ from building new VM image?‘init’ is similar to building a new VM image; ‘reconfigure’ is not. Specifically, ‘reconfigure’ changes things to have immediate effect, such as switching /run/current-system/ to the new (reconfigured) system. Eventually it will also offer to restart dmd services whose definition have changed.
I hope it is now obvious that I didn't `reconfigure', but `init'.
Maybe it could check whether the root partition in the OS declaration is the same as the one that holds the current store, but I’m not sure if that can be done reliably. Thoughts?Again, I'm afraid we misunderstood each other. One thing is that you can expose it to configuration and let user configure it correctly. I was already thinking that I'm wasting disk space with two copies of /gnu/store on my computer (on Gentoo and on GuixSD).Oh, I see. So you had installed Guix atop Gentoo, and from there you wanted to install GuixSD while (1) keeping Gentoo, and (2) not rebuilding a new store, right?
Yes.
The solution to is to run, from your Gentoo system:
# guix system init config.scm /
The “/” here means that you keep the same root file system, and thus the
same store.
If you want to still be able to boot into Gentoo, you need to specify
GRUB menu entries in config.scm, like
(define gentoo-entry
(menu-entry
(label "Gentoo")
(linux "/whatever/bzImage")
(linux-arguments '("answer=42"))
(initrd "/something/initrd.gz")))
(operating-system
;; ...
(bootloader (grub-configuration
(device "/dev/sda")
(menu-entries (list gentoo-entry)))))
I'm aware of this feature, I'm preparing bug report for that :)
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.
Does that better answer your questions?
Yes and no. I really appreciate your patience here but we diverged from original reported issue. Let me the whole bug rephrase into single simple question: Shouldn't `grub' be in `%base-packages'? Thanks and best regards, S_W
pgp_BccXGMVVW.pgp
Description: PGP signature
