GNU bug report logs - #20024
grub store is not copied to target system

Previous Next

Full log

View this message in rfc822 format

From: Tomáš Čech <sleep_walker <at> suse.cz>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 20024 <at> debbugs.gnu.org
Subject: bug#20024: grub store is not copied to target system
Date: Mon, 9 Mar 2015 21:04:21 +0100

[Message part 1 (text/plain, inline)]

On Mon, Mar 09, 2015 at 06:00:24PM +0100, Ludovic Courtès wrote:
>Tomas Cech <sleep_walker <at> 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

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.