all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tomas Cech <sleep_walker@suse.cz>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: none
Date: Fri, 05 Dec 2014 09:35:42 +0100	[thread overview]
Message-ID: <874mta7au9.wl%sleep_walker@suse.cz> (raw)
In-Reply-To: <87wq67qao8.fsf@gnu.org>

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

  reply	other threads:[~2014-12-05  8:35 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03 18:02 (unknown) Tomas Cech
2014-12-04 23:04 ` none Ludovic Courtès
2014-12-05  8:35   ` Tomas Cech [this message]
2014-12-06 14:06     ` none Ludovic Courtès
2015-03-10 11:59     ` bug#20071: none Tomáš Čech
2019-11-12 20:21       ` bug#20071: Bug Hunting: status? zimoun
2019-11-13 13:37         ` Ludovic Courtès
2019-11-13 15:31           ` zimoun
2019-11-20 17:36             ` zimoun
  -- strict thread matches above, loose matches on Subject: below --
2016-07-23  9:15 none David Craven
2016-07-21  1:39 (unknown) Unknown, Pjotr Prins
2016-07-21 12:51 ` none Ludovic Courtès
2016-07-22  0:41   ` none Pjotr Prins
2016-07-22  2:06     ` none Pjotr Prins
2016-07-22  3:25       ` none Jookia
2016-07-22  3:48       ` none Leo Famulari
2016-07-22  4:48       ` none Tobias Geerinckx-Rice
2016-07-22 11:07         ` none Pjotr Prins
2016-07-22 12:23           ` none Ricardo Wurmus
2016-07-22 12:50             ` none Jookia
2016-07-22 21:19               ` none Leo Famulari
2016-07-24  4:17                 ` none Jookia
2016-07-24  6:35                   ` none Leo Famulari
2016-07-24  7:47                     ` none Jookia
2016-07-24 16:52               ` none Christopher Allan Webber
2016-07-24 17:03                 ` none Andreas Enge
2016-07-22  8:15     ` none Roel Janssen
2016-07-22 14:07       ` none Leo Famulari
2016-07-22 14:15         ` none Vincent Legoll
2016-07-22 16:13       ` none Ludovic Courtès
2016-07-22 16:38         ` none myglc2
2016-07-23  7:03           ` none Tomáš Čech
2015-03-25 22:49 (unknown), Tomáš Čech
2015-03-26 21:22 ` none Ludovic Courtès
2015-03-26 21:52   ` none Tomáš Čech
2014-02-11 22:17 Gnunet-0.10.0 recipe Sree Harsha Totakura
2014-02-12 15:15 ` (unknown), Sree Harsha Totakura
2014-02-12 17:36   ` none Ludovic Courtès
2014-02-12 17:38     ` none Sree Harsha Totakura
2014-02-12 19:25     ` none Andreas Enge
2014-02-12 20:30       ` none Ludovic Courtès
2014-02-12 20:53         ` none Andreas Enge
2014-02-04 15:12 (unknown), John Darrington
2014-02-04 20:47 ` none Ludovic Courtès
2014-02-05 16:17   ` none Mark H Weaver
2014-02-05 17:38     ` none John Darrington
2014-02-05 18:35       ` none 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874mta7au9.wl%sleep_walker@suse.cz \
    --to=sleep_walker@suse.cz \
    --cc=guix-devel@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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.