Bootloader trouble during installation

[cinder88]

Hello again, all. I've been trying to install GuixSD for the first time with no 
success.
The installation process seems to go smoothly, but my machine can't detect the
installation. Since the installation isn't detected, I believe the problem is 
with the
bootloader.

For the bootloader, I am attempting to use legacy boot, not UEFI. I realize that
fdisk below identifies /dev/sda2 as an EFI system, but this seems to 
automatically
happen when I set boot to on in parted.

My hardware specs:

http://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad%20X270/ThinkPad_X270_Platform_Specifications.pdf

fdisk listing:

Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: EA4E014F-6603-41FE-8C81-703E4A54D45C

Device Start   End   Sectors  Size Type
/dev/sda1   2048  6143  40962M BIOS boot
/dev/sda2   6144268287262144  128M EFI System
/dev/sda3 268288  33822719  33554432   16G Linux swap
/dev/sda4   33822720 168040447 134217728   64G Linux root (x86-64)
/dev/sda5  168040448 234441614  66401167 31.7G Linux filesystem

parted listing:

Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End SizeFile system Name  Flags
 1  1049kB  3146kB  2097kB  grub  bios_grub
 2  3146kB  137MB   134MB   ext4boot  boot, esp
 3  137MB   17.3GB  17.2GB  linux-swap(v1)  swap
 4  17.3GB  86.0GB  68.7GB  ext4root
 5  86.0GB  120GB   34.0GB  ext4data

config.scm:

(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules admin)
(operating-system
  (host-name "alpha")
  (timezone "US/Eastern")
  (locale "en_US.utf8")
  (bootloader (grub-configuration (device "/dev/sda")))
  (file-systems (append
 (list (file-system
   (device "my-root")
   (title 'label)
   (mount-point "/")
   (type "ext4")))
(list (file-system
   (device "my-boot")
   (title 'label)
   (mount-point "/boot")
   (type "ext4")))
  %base-file-systems))
  (users (cons (user-account
(name "cinder")
(comment "primary user")
(group "users")
(supplementary-groups '("wheel"
"audio" "video"))
(home-directory "/home/alice"))
   %base-user-accounts))
  (packages (cons tcpdump %base-packages))
  (services (cons* (dhcp-client-service)
   (service openssh-service-type
(openssh-configuration
  (port-number )))
   %base-services)))

the automatically generated grub.conf:

# This file was generated from your GuixSD configuration.  Any changes
# will be lost upon reconfiguration.

function setup_gfxterm {
  # Leave 'gfxmode' to 'auto'.
  insmod video_bochs
  insmod video_cirrus
  insmod gfxterm

  if [ "${grub_platform}" == efi ]; then
# This is for (U)EFI systems (these modules are unavailable in the
# non-EFI GRUB.)  If we don't load them, GRUB boots in "blind mode",
# which isn't convenient.
insmod efi_gop
insmod efi_uga
  else
# These are specific to non-EFI Intel machines.
insmod vbe
insmod vga
  fi
}

# Set 'root' to the partition that contains /gnu/store.
search --label --set my-root

if loadfont 
/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/share/grub/unicode.pf2; 
then
  setup_gfxterm
fi

terminal_output gfxterm


insmod png
if background_image /gnu/store/z22x0dqcysrfx1zzyqyxgqlgl6pwi3m3-grub-image.png; 
then
  set color_normal=light-gray/black
  set color_highlight=yellow/black
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi

set default=0
set timeout=5
menuentry "GNU with Linux-Libre 4.11 (beta)" {
  search --label --set my-root
  linux /gnu/store/fqc2kg4lq1lz1ymk41080jzb5q90icg0-linux-libre-4.11/bzImage 
--root=my-root --system=/gnu/store/cp014zrg3ajwbfwsp1mp8pwbyiipgk2d-system 
--load=/gnu/store/cp014zrg3ajwbfwsp1mp8pwbyiipgk2d-system/boot
  initrd /gnu/store/0m59xnbipjnxhch9m99hvfqf7b0nfy0r-raw-initrd/initrd
}

As you can see, I am trying to put /boot on a separate partition. I tried 
having /boot
on the same partition as /, but it didn't seem to make a difference.

Thank you for any and all help,

-Andrew

Re: Bootloader trouble during installation

[Adam Van Ymeren]

cinde...@hushmail.com writes:

> Hello again, all. I've been trying to install GuixSD for the first time with 
> no success.
> The installation process seems to go smoothly, but my machine can't detect the
> installation. Since the installation isn't detected, I believe the problem is 
> with the
> bootloader.
>
> For the bootloader, I am attempting to use legacy boot, not UEFI. I realize 
> that
> fdisk below identifies /dev/sda2 as an EFI system, but this seems to 
> automatically
> happen when I set boot to on in parted.

> fdisk listing:

> Disklabel type: gpt

If you're not using UEFI boot, try using a regular DOS/MBR partition scheme
rather than GPT.  Not all BIOS's will support GPT in legacy mode.

In fdisk I believe the command is "o" to initialize a blank DOS
partition.

Re: Bootloader trouble during installation

[Chris Marusich]

cinde...@hushmail.com writes:

> Hello again, all. I've been trying to install GuixSD for the first time with 
> no success.

Sorry to hear that!  Hopefully we can help get it fixed.

> The installation process seems to go smoothly, but my machine can't
> detect the installation. Since the installation isn't detected, I
> believe the problem is with the bootloader.

How far along does the bootstrap process get?  Are you receiving an
error message at some point?  If you can provide some more details about
the problem, maybe it will point us towards the right solution.

> For the bootloader, I am attempting to use legacy boot, not UEFI. I
>realize that
> fdisk below identifies /dev/sda2 as an EFI system, but this seems to 
> automatically
> happen when I set boot to on in parted.

The reason that happens is because 'boot' is an alias for 'esp' in the
case of GPT (see: info '(parted) set').  I'm not sure if it's correct to
enable this flag on /dev/sda2, though.  In Guix's system installation
tests, which also use GPT, we enable the 'boot' flag on the bios_grub
partition, which is /dev/sda1 in your case.  Maybe you can try enabling
the 'boot' flag on /dev/sda1 instead?

>   (file-systems (append
>  (list (file-system
>(device "my-root")
>(title 'label)
>(mount-point "/")
>(type "ext4")))
>   (list (file-system
>  (device "my-boot")
>  (title 'label)
>  (mount-point "/boot")
>  (type "ext4")))
>   %base-file-systems))

It might not be related to the issue at hand, but you might want to
double check that the labels of your file systems actually matches
labels you've specified here.  There are many ways to view file system
labels; one convenient way is to run 'blkid' (which is in the util-linux
package).

> Thank you for any and all help,

Happy to assist!

-- 
Chris


signature.asc
Description: PGP signature

Re: 01/02: gnu: blast+: Update to 2.6.0.

[Ludovic Courtès]

Hi Ben,

donttrust...@gmail.com (Ben Woodcroft) skribis:

> commit 18dea67dc3a42d782b34b551304748346f173184
> Author: Ben Woodcroft 
> Date:   Mon Jul 3 23:00:14 2017 +1000
>
> gnu: blast+: Update to 2.6.0.
> 
> * gnu/packages/bioinformatics.scm (blast+): Update to 2.6.0.
> [origin]: Remove bundled pcre.
> [arguments]: Replace paths in run_with_lock.c.  Configure with pcre.
> [inputs]: Add pcre, perl, python.

[...]

> +  (patches (search-patches "blast+-fix-makefile.patch"))

You forgot this patch in the commit.  Could you please commit it?

We may have to revert it because it’s currently blocking evaluations on
hydra.gnu.org: .

TIA!

Ludo’.

Re: A question about 'guix build -f'

[Alex Kost]

Feng Shu (2017-07-06 06:21 +0800) wrote:

> I want to build emacs-exwm-x in my guix-git repo with the following command:
>
>guix build emacs-exwm-x -f /home/feng/project/guix/gnu/packages/emacs.scm
>
> But it seem to do nothing, any suggestion?

As it is mentioned in the manual, when you use "guix build -f", the file
*must* evaluates to the package definition, i.e. it would work if the
last expression in "gnu/packages/emacs.scm" returned a package.  But the
last expression is ‘(define-public ...)’ which doesn't return a package
definition.

> by the way, pre-inst-env is not suit my need, I just want to hack a
> small package -> rebase it to latest git commit -> test build and
> install -> format patch
>
> The problem is that, when I git pull to get latest git commit, test
> build and install need download and build many many package, this is
> veeery sloow. so I need a way I can code in guix git repo
> and use system guix to test build and install.

Well, if you don't want to pull the latest commit, use whatever commit
you want, modify the package and use "pre-inst-env".  I don't really
understand what is the problem.

Actually, if you really want to use "-f" option, just put ‘emacs-exwm-x’
symbol to the end of that file.  But this is not the "right way" :-)

-- 
Alex

Re: Bootloader trouble during installation

[Danny Milosavljevic]

Hi Andrew,

there should be a BIOS setup option that indicates whether the BIOS is supposed 
to use EFI (I think you can also set up boot cryptographic keys in there 
somewhere, so around there).

According to 
http://pcsupport.lenovo.com/at/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x270/downloads/ds120442
 it has UEFI.

How did you boot previously?

> For the bootloader, I am attempting to use legacy boot, not UEFI. I realize 
> that
> fdisk below identifies /dev/sda2 as an EFI system, but 

>this seems to automatically happen when I set boot to on in parted.

Really?  Didn't happen to me - but I have Libreboot so no idea what it does for 
UEFI.

UEFI is kinda annoying to use and disable.  But if it doesn't boot anyway, try 
setting the grub package to grub-efi in the config (and then invoke "guix 
system reconfigure config.scm") to make it use UEFI.  Can't hurt...

Otherwise I think you have to manually disable UEFI in the BIOS setup or 
something...

But I only used UEFI once on another person's laptop (customer...), so I don't 
know much about it.  I added Ludo, who more recently used UEFI, to Cc  :)

> Device Start   End   Sectors  Size Type
> /dev/sda1   2048  6143  40962M BIOS boot


> /dev/sda2   6144268287262144  128M EFI System

This should be a FAT partition.  If you want you can mount it and check it 
out...

If there are ".EFI" files there, it's UEFI.

> Number  Start   End SizeFile system Name  Flags
>  1  1049kB  3146kB  2097kB  grub  bios_grub
>  2  3146kB  137MB   134MB   ext4boot  boot, esp

Yeah, "esp" for EFI system partition.

>   (bootloader (grub-configuration (device "/dev/sda")))

Try (bootloader (grub-configuration (grub grub-efi) (device "/dev/sda"))) if 
you want...

Re: Binding generator, for Guile, to C libraries

[Danny Milosavljevic]

Hi Ludo,

On Wed, 05 Jul 2017 23:53:36 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Danny Milosavljevic  skribis:
> 
> > Okay, I've cleaned up what I have and put it on github, under:
> >
> > https://github.com/daym/guile-gcc-unit
> >
> > What this does is it allows you to read gcc output files which specify all 
> > the prototypes - in our case in order to extract the prototypes and 
> > generate Guile bindings (of parted, or whatever).
> >
> > The next steps:
> > - Provide the actual binding generator (I started a version of it - I'll 
> > commit a cleaned-up version in a few days I guess).

> > - Get it to work with non-toy examples (see file "tests/huge/input" for the 
> > parted non-toy example - the goal is to read this file, find all the record 
> > decls and all the function decls in it

This part is working now, also for parted.

> and generate the Guile pendants of them).  If you happen to know LALR parsing 
> theory, I have a question :)
> > - Find out whether that can be integrated as a Guile "language".  Just 
> > being able to do something like ',load "foo.h"' and have it register all 
> > the functions from it would be way cool.  On the other hand, on non-Guix 
> > systems the header files aren't usually installed when the library is 
> > installed.  So maybe an offline version would be good as well.  
> 
> Matt Wette, the author of nyacc, was apparently in the process of
> writing a similar tool using nyacc’s C99 parser.  Might be worth looking
> at.

Nice!  I've actually thought about using nyacc and mes for that - but since we 
use gcc to compile everything, we can also use gcc to find out what it compiled 
- it's more probable that that actually matches up.  What I like is that gcc 
actually dumps the declarations even when you *don't* call the function.  So 
you can actually create a mostly-empty source file with #include in it and gcc 
will give you everything that is in scope.

But it's definitely worth taking a look at Matt Wette's actual Guile dynamic-* 
generator, maybe that can be shared between the projects.

> Besides and FWIW, I’m skeptical of binding generators.  Things like
> SWIG, for instance, generate interfaces that are often not quite what
> you’d like, so you end up writing a layer on top of the generated glue
> anyway, not to mention annotation in headers. 

Yeah, probably the bindings will suck a bit.  But one can always write a 
wrapper and not export all the original functions from there.  Rust for example 
has a "...-sys" convention where the package "foo-sys" contains the 
easily-generated bindings and the package "foo" contains the actually simple 
high-level bindings.

What I don't want is to manually maintain all the bindings.  It's a computer, 
it should automate it :P

Writing "override" declarations (or maybe even just literally overwriting the 
definition in Scheme) once every few months I'm fine with.  Adapting the 
bindings every time upstream adds a function?  No.

If I plan to use something like the "...-sys" convention in Guile, can I 
somehow re-export all the same names as the "-sys" package did, in a non-sys 
package?

For example:

(define-module (foo-sys)
  #:export (a b c))

...
--
(define-module (foo)
  #:re-export (same-names-as-in foo-sys, but use newer versions from below if 
applicable))

(define (b ...)
  fix it up)
-
Hmm, I guess I can use (include-from-path "foo-sys") in the second module 
before I overwrite anything.

> (Bindings generated from
> high-level descriptions like GIR and XCB are a different story; those
> seem to work quite well.)

Yeah, I like glib's approach with the def files which specify also the object 
lifetimes etc.

Re: 01/02: gnu: blast+: Update to 2.6.0.

[Ben Woodcroft]

Hi Ludo,


On 07/07/17 02:54, Ludovic Courtès wrote:

Hi Ben,

donttrust...@gmail.com (Ben Woodcroft) skribis:


commit 18dea67dc3a42d782b34b551304748346f173184
Author: Ben Woodcroft 
Date:   Mon Jul 3 23:00:14 2017 +1000

 gnu: blast+: Update to 2.6.0.
 
 * gnu/packages/bioinformatics.scm (blast+): Update to 2.6.0.

 [origin]: Remove bundled pcre.
 [arguments]: Replace paths in run_with_lock.c.  Configure with pcre.
 [inputs]: Add pcre, perl, python.

[...]


+  (patches (search-patches "blast+-fix-makefile.patch"))

You forgot this patch in the commit.  Could you please commit it?

We may have to revert it because it’s currently blocking evaluations on
hydra.gnu.org: .
Gah, apologies. I will fix this in ~12 hours time. Anyone should feel 
free to revert it in the meantime as I am unable to until then.

ben

Re: 01/02: gnu: blast+: Update to 2.6.0.

[Leo Famulari]

On Fri, Jul 07, 2017 at 09:33:26AM +1000, Ben Woodcroft wrote:
> Hi Ludo,
> 
> 
> On 07/07/17 02:54, Ludovic Courtès wrote:
> > Hi Ben,
> > 
> > donttrust...@gmail.com (Ben Woodcroft) skribis:
> > 
> > > commit 18dea67dc3a42d782b34b551304748346f173184
> > > Author: Ben Woodcroft 
> > > Date:   Mon Jul 3 23:00:14 2017 +1000
> > > 
> > >  gnu: blast+: Update to 2.6.0.
> > >  * gnu/packages/bioinformatics.scm (blast+): Update to 2.6.0.
> > >  [origin]: Remove bundled pcre.
> > >  [arguments]: Replace paths in run_with_lock.c.  Configure with pcre.
> > >  [inputs]: Add pcre, perl, python.
> > [...]
> > 
> > > +  (patches (search-patches "blast+-fix-makefile.patch"))
> > You forgot this patch in the commit.  Could you please commit it?
> > 
> > We may have to revert it because it’s currently blocking evaluations on
> > hydra.gnu.org: .
> Gah, apologies. I will fix this in ~12 hours time. Anyone should feel free
> to revert it in the meantime as I am unable to until then.
> ben

I reverted it in the meantime.


signature.asc
Description: PGP signature

Re: stability of master - just QA and hydra is not enough

[myglc2]

On 07/01/2017 at 14:01 Leo Famulari writes:

> On Sat, Jul 01, 2017 at 05:36:04PM +, ng0 wrote:
[...]
>> 0: What is it these days? Is hydra now just a in-retirement frontend
>> for cuirass or how does bayfront work these days? I understand cuirass,
>> not hydra.
>
> ... Bayfront is still not fully operational, so hydra.gnu.org is still
> serving as the front-end of the build farm. We are still relying on the
> Hydra software. That is, the situation is basically the same as before.
> Adding build machines will not help very much until the front-end
> hardware gets faster.

This leaves me wondering ...

Is the hydra/front-end hardware going to be upgraded?

Is bayfront/cuirass intended to replace hydra?

The bayfront hardware described here ...

https://www.gnu.org/software/guix/news/growing-our-build-farm.html

... seems weak to me. Is there a plan to scale it up and make it redundant?

A reliable, resourced, managed, "nightly Guix build" should pay big
dividends for the project. But, from reading the lists, I get the
impression that such a thing does not exist. Is that correct?

Do we know what would be needed to achieve a complete nightly build?

TIA - George

Re:Re: A question about 'guix build -f'

[tumashu]

> I don't really understand what is the problem.


The problem is:  who will deal with the conflict when merge the patch?

If  patch-sender,   patch-sender must "git pull" before format-patch.  this 
make patch can am the master
without deal with conflict, but when "git pull", ./pre script can work as same 
as before git pull ?

If patch-amer.  patch-sender seem to no problem :-)

Guix infrastructure

[Leo Famulari]

On Thu, Jul 06, 2017 at 08:09:17PM -0400, myglc2 wrote:
> On 07/01/2017 at 14:01 Leo Famulari writes:
> > ... Bayfront is still not fully operational, so hydra.gnu.org is still
> > serving as the front-end of the build farm. We are still relying on the
> > Hydra software. That is, the situation is basically the same as before.
> > Adding build machines will not help very much until the front-end
> > hardware gets faster.
> 
> This leaves me wondering ...
> 
> Is the hydra/front-end hardware going to be upgraded?

Yes...

> Is bayfront/cuirass intended to replace hydra?

... and yes.

> The bayfront hardware described here ...
> 
> https://www.gnu.org/software/guix/news/growing-our-build-farm.html
> 
> ... seems weak to me. Is there a plan to scale it up and make it redundant?

It will be a lot more powerful than the current Hydra system. As for
specific plans, I'll let those administering the system chime in.

> A reliable, resourced, managed, "nightly Guix build" should pay big
> dividends for the project. But, from reading the lists, I get the
> impression that such a thing does not exist. Is that correct?

Currently, we tend to build all the packages as often as we can with our
resources, which is less than once a day.

> Do we know what would be needed to achieve a complete nightly build?

It depends on what you mean by "complete".

I doubt we can find armhf hardware that could build all the packages
daily. That platform doesn't get very powerful in general and, in my
experience, the machines that do exist can't handle sustained high
loads, nor do they have fast network and I/O interfaces.

It is possible for x86_64, i686, and eventually for aarch64. Maybe we
will be able to cross-build from aarch64 to arhmf; I'm not sure. Efraim?

Ricardo has been working on getting some new x86_64 / i686 builders
online:

https://gnunet.org/bot/log/guix/2017-06-30#T1433202


signature.asc
Description: PGP signature

Re: Graphical Installer - Call for Testing.

[Chris Marusich]

Hi Danny,

Wow!  I just looked, and I see that a lot of changes have been made
since January.  Is the wip-installer-2 branch the one I should test with
now?  What's the difference between the wip-installer and
wip-installer-2 branches?  What steps should I take to create a disk
image with the installer (or is a testable image available already)?

I will see if I can test it again in the next couple of weeks.

Danny Milosavljevic  writes:

>> * I think you made the first letter of some commands bold (like the "C"
>>   in "Continue"), but I didn't notice it until I tried the installation
>>   on a machine with a different monitor.  More contrast, or an
>>   underlined character, might help call that out more.
>
> Yeah, the HIG standard is underline.  Does underline work in curses on the 
> Linux console?  Apparently it's always auto-mapped to color.

I don't know.

>> * Partition the disks: when launching cfdisk, consider explaining that
>>   we're going to launch cfdisk to do the actual partitioning, and the
>>   user needs to quit cfdisk to come back and continue the installation.
>
> I'm writing guile-parted bindings now :)

Cool!

>> * The generated operating system configuration should use file system
>>   UUID or label, if possible, rather than device path.
>
> I didn't get that far yet.  Is that still the case?

I don't know.  When I test it again, I'll check.

>> * Choose mount point: since you can also set the label here, maybe
>>   change the title of the section to "Choose file system and mount
>>   point" or something?
>
> In the long run, I think this all should be "disk setup" and encompass 
> partitioning, lvm, encryption, file system creation and mount point setup.

I think it would be fantastic to accomplish all of the following:

* It's easy to configure the disks for the common use cases.

* It's possible to customize the configuration for any use case.

* The installer doesn't overwhelm people with knowledge that they might
  not (yet!) possess, but it invites them to take control and to learn.

I think each of those bullet points is in the spirit of Guix.

>> * The installer takes a "window within a window" approach for
>>   installation phases.  This conflicts with the "replace the whole
>>   window" behavior that occurs when running cfdisk.  
>
> Writing the parted bindings... :)

Excellent!

>>   I think that using a "replace the whole window" approach for the
>>   whole installer would help unify the overall look and feel.  So,
>>   instead of creating a window within the installer window for the
>>   "Partition the disks" phase, just replace the entire window with
>>   the relevant interface for the sub-menu.
>
> I actually like the window-within-window approach, especially since it
> can show some kind of path or status of where the user is nicely.  I
> wonder whether the nesting works for more than two levels, though.

That would work, too.  As long as the choice is consistent, it'll be a
better user interface.

>> * Choose mount point: clarify what the actions Check, Write, and
>>   re(Create) mean.  I wasn't sure until I tried them all!
>
> I think that's cfdisk ?  Or where?

It's been a few months, but I don't think that was in the cfdisk menu.
Maybe that section of the installer has been changed since I last tested
it.  I think it was in a section called "choose mount point".

I'm happy to see that this branch has remained active!  I'm sure having
a graphical installer will encourage more people to try GuixSD.

-- 
Chris


signature.asc
Description: PGP signature

Re: Graphical Installer - Call for Testing.

[Danny Milosavljevic]

Hi,

On Thu, 06 Jul 2017 21:48:47 -0700
Chris Marusich  wrote:

> Is the wip-installer-2 branch the one I should test with now?

Yes, if you want :)

>  What's the difference between the wip-installer and
> wip-installer-2 branches?

I didn't want to fuck up the wip-installer branch so I created a new one 
starting from master, merged all the wip-installer commits into wip-installer-2 
as far as possible (took a lot of manual conflict resolution) and edited the 
branch until the installer worked again.  Then I added some new stuff.

>  What steps should I take to create a disk
> image with the installer (or is a testable image available already)?

Good question.  I'm not sure.

John adapted the gnu/system/install.scm - installation-os to add an invocation 
of the graphical installer.

Hydra does (system-disk-image installation-os
  #:disk-image-size
  (* 1024 MiB).

Try doing the same in the Guile interpreter, like so:

guile -L .
,use (gnu system vm)
,use (gnu system install)
(system-disk-image installation-os #:disk-image-size (* 1024 MiB)

But I think that's a monadic value and one would still call run-with-store with 
some store and the result?