bug#20024: grub store is not copied to target system

bug#20024: grub store is not copied to target system

[tcech]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

With guix at revision df81e046c57e5f767738113e4e7a28b212c03d63 I tried
to deploy Guix to another partition.

Result system installed Grub into partition but did not copied it's
store to /gnu/store/ on target partition.

As a result, no graphics was working (font loading depends on the
store) and no grub reinstallation was possible.


Configuration used:

(use-modules (gnu)
	     (gnu packages bash)
    	     (gnu packages emacs)
    	     (gnu packages enlightenment)
    	     (gnu packages grub)
     	     (gnu packages linux)
	     (gnu packages mc)
       	     (gnu packages wicd)
       	     (gnu packages xorg)
	     (gnu packages dwm)
	     (gnu services ssh)
	     (gnu services dbus)
     	     (gnu services networking)
	     (gnu services xorg))

(operating-system
 (host-name "venom")
 (timezone "Europe/Prague")
 (locale "cs_CZ.utf8")
 (bootloader (grub-configuration
	      (device "/dev/sda")))
 (file-systems (append (list (file-system
			      (device "/dev/sda4") ; or partition label
			      (mount-point "/")
			      (type "ext4"))
;			     (file-system
;			      (device "/dev/venom/home")
;			      (mount-point "/home")
;			      (type "ext4"))
			     )
		     %base-file-systems))
; (swap-devices '("/dev/sda2"))
 (users (list (user-account
	       (name "tcech")
	       (uid 1000) (group "users")
	       (comment "Tomas Cech")
	       (home-directory "/home/tcech"))))
 (packages (append
	    (list emacs lvm2 mc bash xterm slock dwm terminology iw wicd)
	    %base-packages))
 (services (append (list (lsh-service #:port-number 2222 #:root-login? #t)
			 (slim-service)
			 (wicd-service)
			 (dbus-service '()))
		   %base-services))
 (kernel linux-libre)
 )


[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

bug#20024: grub store is not copied to target system

[Ludovic Courtès]

tcech@suse.cz skribis:

> With guix at revision df81e046c57e5f767738113e4e7a28b212c03d63 I tried
> to deploy Guix to another partition.

Do you mean that you wanted to use a different root partition than the
one that was being used?

> Result system installed Grub into partition but did not copied it's
> store to /gnu/store/ on target partition.

Indeed, ‘guix system reconfigure’ assumes that the root partition
remains the same and does not try to copy the store.

Thanks,
Ludo’.

bug#20024: grub store is not copied to target system

[Tomáš Čech]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Sun, Mar 08, 2015 at 10:49:37PM +0100, Ludovic Courtès wrote:
>tcech@suse.cz skribis:
>
>> With guix at revision df81e046c57e5f767738113e4e7a28b212c03d63 I tried
>> to deploy Guix to another partition.
>
>Do you mean that you wanted to use a different root partition than the
>one that was being used?

Yes. I am running from my Gentoo `guix system init -c 3 /guix' where /guix is
different partition planned to be booted as root filesystem for GuixSD.

>> Result system installed Grub into partition but did not copied it's
>> store to /gnu/store/ on target partition.
>
>Indeed, ‘guix system reconfigure’ assumes that the root partition
>remains the same and does not try to copy the store.

I'm runnning `guix system init' though.

S_W

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

bug#20024: grub store is not copied to target system

[Ludovic Courtès]

Tomáš Čech <sleep_walker@suse.cz> skribis:

> On Sun, Mar 08, 2015 at 10:49:37PM +0100, Ludovic Courtès wrote:
>>tcech@suse.cz skribis:
>>
>>> With guix at revision df81e046c57e5f767738113e4e7a28b212c03d63 I tried
>>> to deploy Guix to another partition.
>>
>>Do you mean that you wanted to use a different root partition than the
>>one that was being used?
>
> Yes. I am running from my Gentoo `guix system init -c 3 /guix' where /guix is
> different partition planned to be booted as root filesystem for GuixSD.

OK.

>>> Result system installed Grub into partition but did not copied it's
>>> store to /gnu/store/ on target partition.
>>
>>Indeed, ‘guix system reconfigure’ assumes that the root partition
>>remains the same and does not try to copy the store.
>
> I'm runnning `guix system init' though.

Yeah your expectations for ‘guix system reconfigure’ were too high I
guess.  ;-)

Seriously, I don’t think we’d want it to automagically migrate the
store.

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?

Thanks,
Ludo’.

bug#20024: grub store is not copied to target system

[Tomas Cech]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

On Mon, Mar 09, 2015 at 09:05:37AM +0100, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@suse.cz> skribis:
>
>> On Sun, Mar 08, 2015 at 10:49:37PM +0100, Ludovic Courtès wrote:
>>>tcech@suse.cz skribis:
>>>
>>>> With guix at revision df81e046c57e5f767738113e4e7a28b212c03d63 I tried
>>>> to deploy Guix to another partition.
>>>
>>>Do you mean that you wanted to use a different root partition than the
>>>one that was being used?
>>
>> Yes. I am running from my Gentoo `guix system init -c 3 /guix' where /guix is
>> different partition planned to be booted as root filesystem for GuixSD.
>
>OK.
>
>>>> Result system installed Grub into partition but did not copied it's
>>>> store to /gnu/store/ on target partition.
>>>
>>>Indeed, ‘guix system reconfigure’ assumes that the root partition
>>>remains the same and does not try to copy the store.
>>
>> I'm runnning `guix system init' though.
>
>Yeah your expectations for ‘guix system reconfigure’ were too high I
>guess.  ;-)

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).

>Seriously, I don’t think we’d want it to automagically migrate the
>store.

How does it differ from building new VM image?

>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).

I may sound like Cpt. Obvious here, but you can also be sure that store is
elsewhere if you need to create /gnu/store directory...

And also note that it worked for me for every package but grub. My opinion is
that grub binaries are not part of %base-packages or similar package set and
noone noticed until now because grub was installed from different
distribution.

I hope I made it a bit more clear now.

Best regards and thanks,

S_W

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

bug#20024: grub store is not copied to target system

[Ludovic Courtès]

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.)

>>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.

>>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?

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)))))

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.

Does that better answer your questions?

Thanks,
Ludo’.

bug#20024: grub store is not copied to target system

[Tomáš Čech]

[-- 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 --]

bug#20024: grub store is not copied to target system

[Ludovic Courtès]

Tomáš Čech <sleep_walker@suse.cz> 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

[Tomáš Čech]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

On Tue, Mar 10, 2015 at 08:58:07AM +0100, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@suse.cz> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

bug#20024: grub store is not copied to target system

[Ludovic Courtès]

Tomáš Čech <sleep_walker@suse.cz> skribis:

> On Tue, Mar 10, 2015 at 08:58:07AM +0100, Ludovic Courtès wrote:
>>Tomáš Čech <sleep_walker@suse.cz> 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

[Tomáš Čech]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

On Tue, Mar 10, 2015 at 11:54:53AM +0100, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@suse.cz> skribis:
>
>> On Tue, Mar 10, 2015 at 08:58:07AM +0100, Ludovic Courtès wrote:
>>>Tomáš Čech <sleep_walker@suse.cz> 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

bug#20024: grub store is not copied to target system

[Ludovic Courtès]

Tomáš Čech <sleep_walker@suse.cz> 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’.