Re: none

[Tomas Cech <sleep_walker@suse.cz>]

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