(unknown)

(unknown)

[Tomas Cech]

Hello,

I'd like to share with you some experiences with using Guix.



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. But eventually I gave up
preparing it manually or automating it and I had rather put another
Grub in the same partition and set up chainloading.

I met then two problems:

1] if you set device to partition (and not to disk) in your grub-configuration like this:

 (bootloader (grub-configuration
               (device "/dev/sda4")))

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


2] current Grub version in Guix during boots generated this error:

error: symbol 'grub_term_highlight_color' not found

and started rescue shell.
It seems to be a bit mystic bug:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977

I used my Gentoo's version of Grub to fix it and then it worked.



I'm also interested in running chroot in Guix. This is something I
like about all Linux distribution I use - I can run Linux and at the
same time I prepare another Linux root filesystem for use. It seems
that chrooting into Guix may be tricky.

I prepared this script to be placed somewhere into Guix:

----------%<---------
#!/run/current-system/profile/bin/bash

export LIBRARY_PATH=LIBRARY_PATH=/root/.guix-profile/lib
export CPATH=/root/.guix-profile/include
export PATH=/run/setuid-programs:/run/current-system/profile/sbin:/root/.guix-profile/bin:/run/current-system/profile/bin
export INFOPATH=/root/.guix-profile/share/info:/run/current-system/profile/share/info

exec bash -i
----------%<--------

for i in dev proc sys; do mount -R /$i /guix_mountpoint/$i; done
chroot /guix_mountpoint/ /helper_script.sh

Ludovic said that `guix packages --search-paths' should generate similar path configuration so it may be the right way, but it didn't work for me.


And last thing I wanted to mention, you have kind community around Guix and Guile. It's really motivating!

Best regards,

Tomas Cech
Sleep_Walker

Re: none

[Ludovic Courtès]

Tomas Cech <sleep_walker@suse.cz> 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

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

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

> 2] current Grub version in Guix during boots generated this error:
>
> error: symbol 'grub_term_highlight_color' not found
>
> and started rescue shell.
> It seems to be a bit mystic bug:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977

Strange.  I haven’t experienced it.  Sounds like a .mod wasn’t found or
something like that?  That could be a bug related to separate /boot.

> I'm also interested in running chroot in Guix. This is something I
> like about all Linux distribution I use - I can run Linux and at the
> same time I prepare another Linux root filesystem for use. It seems
> that chrooting into Guix may be tricky.
>
> I prepared this script to be placed somewhere into Guix:
>
> ----------%<---------
> #!/run/current-system/profile/bin/bash
>
> export LIBRARY_PATH=LIBRARY_PATH=/root/.guix-profile/lib
> export CPATH=/root/.guix-profile/include
> export PATH=/run/setuid-programs:/run/current-system/profile/sbin:/root/.guix-profile/bin:/run/current-system/profile/bin
> export INFOPATH=/root/.guix-profile/share/info:/run/current-system/profile/share/info
>
> exec bash -i
> ----------%<--------
>
> for i in dev proc sys; do mount -R /$i /guix_mountpoint/$i; done
> chroot /guix_mountpoint/ /helper_script.sh

I suppose this works, right?

> Ludovic said that `guix packages --search-paths' should generate similar path configuration so it may be the right way, but it didn't work for me.

I realize ‘guix package --search-paths’ wouldn’t suffice here.  You may
want to source /etc/profile from within the chroot.

> And last thing I wanted to mention, you have kind community around Guix and Guile. It's really motivating!

Thanks for your feedback and for the kind words!

Ludo’.

Re: none

[Tomas Cech]

At Fri, 05 Dec 2014 00:04:23 +0100,
Ludovic Courtès wrote:
> 
> Tomas Cech <sleep_walker@suse.cz> 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 some more mails with help-grub ML It seems that Grub can do even better -
it can load core.img right from Guix's filesystem or just read new
configuration (multiboot, resp. config - both shown here
http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config
)... But these are just Grub chainloading Grub solutions...

From Guix perspective I don't think it is possible to do it
automatically. I think you can consider installation of Grub to
partiotion as something just for advanced users. With that in mind I
believe guix should refuse (with some warning) installing grub that
way. Advanced users can use `--no-grub' option which will prevent guix
from fail and do manually anything they desire. And in the
documentation I'd give some short notice about that with link to Grub
manual. IMHO information that "only ZFS and BtrFS can embed core.img
into boot sector" belongs there.

> > 2] current Grub version in Guix during boots generated this error:
> >
> > error: symbol 'grub_term_highlight_color' not found
> >
> > and started rescue shell.
> > It seems to be a bit mystic bug:
> > https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977
> 
> Strange.  I haven’t experienced it.  Sounds like a .mod wasn’t found or
> something like that?  That could be a bug related to separate /boot.

Yes, sounds like something like that. Important for me is that the
same command with same configuration worked when I used version from
Gentoo so I don't think it's bug elsewhere but in Grub version.


> > I'm also interested in running chroot in Guix. This is something I
> > like about all Linux distribution I use - I can run Linux and at the
> > same time I prepare another Linux root filesystem for use. It seems
> > that chrooting into Guix may be tricky.
> >
> > I prepared this script to be placed somewhere into Guix:
> >
> > ----------%<---------
> > #!/run/current-system/profile/bin/bash
> >
> > export LIBRARY_PATH=LIBRARY_PATH=/root/.guix-profile/lib
> > export CPATH=/root/.guix-profile/include
> > export PATH=/run/setuid-programs:/run/current-system/profile/sbin:/root/.guix-profile/bin:/run/current-system/profile/bin
> > export INFOPATH=/root/.guix-profile/share/info:/run/current-system/profile/share/info
> >
> > exec bash -i
> > ----------%<--------
> >
> > for i in dev proc sys; do mount -R /$i /guix_mountpoint/$i; done
> > chroot /guix_mountpoint/ /helper_script.sh
> 
> I suppose this works, right?

Yes :)

> 
> > Ludovic said that `guix packages --search-paths' should generate similar path configuration so it may be the right way, but it didn't work for me.
> 
> I realize ‘guix package --search-paths’ wouldn’t suffice here.  You may
> want to source /etc/profile from within the chroot.

OK, I'll play with this to improve it.


S_W

Re: none

[Ludovic Courtès]

Tomas Cech <sleep_walker@suse.cz> skribis:

> At Fri, 05 Dec 2014 00:04:23 +0100,

[...]

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

Another option for you would be to add a ‘menu-entry’ to the
‘grub-configuration’ form that would boot the other distro.

  (grub-configuration
    (device ...)
    (menu-entries
      (list (menu-entry
              (label "Good ol' distro")
              (linux "/path/to/kernel”)
              (linux-arguments '("whatever"))
              (initrd "/path/to/initrd")))))

> After some more mails with help-grub ML It seems that Grub can do even better -
> it can load core.img right from Guix's filesystem or just read new
> configuration (multiboot, resp. config - both shown here
> http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config
> )... But these are just Grub chainloading Grub solutions...
>
> From Guix perspective I don't think it is possible to do it
> automatically. I think you can consider installation of Grub to
> partiotion as something just for advanced users. With that in mind I
> believe guix should refuse (with some warning) installing grub that
> way. Advanced users can use `--no-grub' option which will prevent guix
> from fail and do manually anything they desire. And in the
> documentation I'd give some short notice about that with link to Grub
> manual. IMHO information that "only ZFS and BtrFS can embed core.img
> into boot sector" belongs there.

OK, thanks for the info.  I’m tempted to think the GRUB manual should be
the primary source for this sort of things.

Thanks,
Ludo’.

bug#20071: none

[Tomáš Čech]

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


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 <sleep_walker@suse.cz> 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.

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

bug#20071: Bug Hunting: status?

[zimoun]

Dear,

This bug is pending since more than 4 years. Does it still apply?
If yes, any progress to report?
If no, does it make sense to close it?

Thanks in advance.

All the bets,
simon

bug#20071: Bug Hunting: status?

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> This bug is pending since more than 4 years. Does it still apply?

The wishlist item at <https://issues.guix.gnu.org/issue/20071> is about
adding a “force” flag for the GRUB configuration.

Do you still think that would make sense, Tomáš?

Thanks,
Ludo’.

PS: zimoun, could you include the bug title and/or URL in the reminders
    you send, to make it easier to see what this is about?  (Besides,
    thanks a lot for doing bug triage!)

bug#20071: Bug Hunting: status?

[zimoun]

On Wed, 13 Nov 2019 at 14:37, Ludovic Courtès <ludo@gnu.org> wrote:

> Do you still think that would make sense, Tomáš?

The email address used by Tomáš returned  "address not found". And
yesterday I asked to Sleep_Walker on IRC (assuming same nick = same
person :-)) what is the new address to report.



> PS: zimoun, could you include the bug title and/or URL in the reminders

My bad! :-)
Because I am doing directly from Emacs, the bug number appeared to me
enough to reach it easily (via `debbugs-gnu-bugs').
Next round, I will write clearer Subject than "Bug Hunting: status?"
;-) and provide URL to ease the triage.


Thank you.
simon

bug#20071: Bug Hunting: status?

[zimoun]

Dear,

On Wed, 13 Nov 2019 at 16:31, zimoun <zimon.toutoune@gmail.com> wrote:
>
> On Wed, 13 Nov 2019 at 14:37, Ludovic Courtès <ludo@gnu.org> wrote:
>
> > Do you still think that would make sense, Tomáš?
>
> The email address used by Tomáš returned  "address not found". And
> yesterday I asked to Sleep_Walker on IRC (assuming same nick = same
> person :-)) what is the new address to report.
>

If this wishlist bug still makes senses, please re-open it.


Thank you.