From: "Tomáš Čech" <sleep_walker@suse.cz>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 20024@debbugs.gnu.org
Subject: bug#20024: grub store is not copied to target system
Date: Mon, 9 Mar 2015 21:04:21 +0100 [thread overview]
Message-ID: <20150309200421.GA1222@venom> (raw)
In-Reply-To: <877fuqkswn.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 4389 bytes --]
On Mon, Mar 09, 2015 at 06:00:24PM +0100, Ludovic Courtès wrote:
>Tomas Cech <sleep_walker@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
[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2015-03-09 20:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 0:01 bug#20024: grub store is not copied to target system tcech
2015-03-08 21:49 ` Ludovic Courtès
2015-03-08 21:57 ` Tomáš Čech
2015-03-09 8:05 ` Ludovic Courtès
2015-03-09 10:34 ` Tomas Cech
2015-03-09 17:00 ` Ludovic Courtès
2015-03-09 20:04 ` Tomáš Čech [this message]
2015-03-10 7:58 ` Ludovic Courtès
2015-03-10 8:41 ` Tomáš Čech
2015-03-10 10:54 ` Ludovic Courtès
2015-03-10 11:50 ` Tomáš Čech
2015-03-10 12:36 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150309200421.GA1222@venom \
--to=sleep_walker@suse.cz \
--cc=20024@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).