Re: Review of installation manual draft

[Petter]

Hi Ludo,

Thanks for looking at it.

On 2016-02-10 22:16, address@hidden wrote:
> Hi Petter,
>
> Thanks a lot for the additions to the manual!
>
> There was a lot more than I expected.  ;-)  For now, I’ve focused on 
> the
> improvements to the “System Installation” section, leading to commit
> dedb8d5.
>
> It turned out to be more work than I expected because I had to find out
> what the differences were (some paragraphs had been moved to a single
> line, which made it hard to spot the differences), and then ended up
> doing a few things differently to preserve consistency.
>
> In the future, it would be awesome if you could send more focused
> patches and make sure the diffs don’t show unrelated “noise.”

I'm sorry that it caused you extra work! For the record, this wasn't 
intended as a patch. We'd been working on this for a little while and 
wanted to get some feedback on particuarly the general direction before 
going any further. With a patch proposal i would have been more careful 
with noise etc.. This was really just a quick translation into guix.texi 
as requested. Maybe it would have been better if you had reviewed the 
link initially provided instead, as this was clearly not a patch.

> Petter <address@hidden> skribis:
>
> > +Open the file in one of the editors. We'll now walk you through the 
> > updates you need to make in the operating-system declaration in turn 
> > from top to bottom.
> > +
> > address@hidden @asis
> > address@hidden @samp{host-name}
> > +Will be the name for this system. It'll be used for identifying this 
> > system on the network and should be unique amongst the computers in 
> > your LAN(s). You may also see it in shell prompts. Use ASCII letters 
> > and digits only unless you know what you're doing.
> > +
> > address@hidden @samp{timezone}
> > +This value must match a supported timezone exactly. To find the value 
> > you need here you can run the command
> > address@hidden
> > +tzselect
> > address@hidden example
> > +and answer its questions. When it asks "Is the above information OK?" 
> > answer "1" (Yes). The value in the last line of output is the value to 
> > use in your configuration.
> > +To get a shell prompt for running commands you can change virtual 
> > console (Ctrl-Alt-F#), or close the editor.
> > +
> > address@hidden @samp{locale}
> > +This value must match a supported locale exactly. To get a list of 
> > supported locales and their typing run the command
> > address@hidden
> > +ls /run/current-system/locale/@var{X.Y}
> > address@hidden @samp{example}
> > +where X.Y is the libc version (just press TAB at this level). Find 
> > the locale you want in the listed output and take note of exactly how 
> > it is typed (trailing / is not included in the name).
> > +To get a shell prompt for running commands you can change virtual 
> > console (Ctrl-Alt-F#), or close the editor.
> > +
> > address@hidden @samp{bootloader}
> > +Update the @samp{device} argument according to the comment in the 
> > example configuration. Typical value is @var{/dev/sda}, note there's 
> > no trailing digit. This will instruct the installation to install GRUB 
> > to the MBR of your disk. This is fine even if you're going to use the 
> > boot loader in your boot firmware, it will just be unused in this 
> > case.
> > address@hidden table
>
> I did not include this as is because I think most of it is redundant
> with (or should be covered by) the “operating-system Reference” 
> section.

Ok. Well, this started as a standalone guide for libreboot.org. And the 
general idea was to guide the user through the entire installation 
process. Also there have been a few issues with locale on IRC, like 
specifying a locale that's not supported.

> I have not yet integrated the bits about setting up an encrypted root
> etc. because I first want the bits below to be fixed in the code.
>
> > address@hidden Booting a fully encrypted system
> > +
> > address@hidden chapter is only for systems with encrypted boot.}
> > +
> > +To be able to boot with encrypted boot you need a system with GRUB 
> > flashed into the boot firmware, like with Coreboot/Libreboot.
>
> It’s not clear to me how much of it is specific to Coreboot/Libreboot.
> It seems like it could equally well work when GRUB is spawned by a
> random proprietary BIOS no?

Yes, these are GRUB specific instructions, not Coreboot/Libreboot. These 
projects are used as examples.

This should be good for any system that can start GRUB without /boot 
access. I have only tried on Libreboot, which load the crypto modules 
automatically. Other systems may not do this and these modules would 
need to be loaded manually in this case. That's the only thing i can 
think of that could be different.

> > address@hidden @asis
> > address@hidden Manual steps to boot your fully encrypted system
> > +Press @kbd{c} in GRUB to enter command mode.
>
> Seems to me that GuixSD should automatically DTRT when installing on an
> encrypted root file system.  See <http://bugs.gnu.org/21843>.
>
> > +menuentry "GuixSD (current)" @{
> > +  cryptomount @var{grub-partition}
> > +  set root=(crypto0)
> > +  set guix_system=/var/guix/profiles/system
> > +  linux  address@hidden@}/kernel/bzImage 
> > address@hidden address@hidden@} 
> > address@hidden@}/boot
> > +  initrd address@hidden@}/initrd
> > address@hidden
>
> I think this sort of answers the above bug report, no?

I don't think so. The bug report looks to be concerned with the 
installation routine. The draft is here concerned with booting.

When i installed, and when i reconfigure, I also get the error:
    Path '/mnt/boot/grub' is not readable by GRUB on boot.
    Installation is impossible. Aborting.

But it hasn't been a problem for me. The (/mnt)?/boot/grub.cfg file has 
luckily been generated when this happens. What fails is the installation 
of GRUB. I don't know why it failed in this case, in my case it's 
because i've specified /dev/sda1, which is my encrypted root partition. 
(I do this because i don't want GuixSD to install GRUB.) However, 
specifying a disk and not a partition, like /dev/sda, i'd expect it to 
install without problems. If this fails maybe the master boot record 
(MBR) is the problem? From the bug report it doesn't look like a reboot 
was attempted. Maybe the system was indeed fine and it's just the 
message that's a bit dramatic?

If you have encrypted /boot you'd most likely want to use GRUB provided 
by your boot firmware anyway, so you can update the GRUB configuration.

We discussed this in #guix and agreed that better than providing a note 
to ignore this message is that the installation routine is made aware 
there are systems where this is ok. I'm not sure if this thread made it 
out of #guix though.

> Thanks a lot for your feedback on this!
>
> Ludo’.

I'm sorry again this took you more time than what was intended.

Petter