let user drop into REPL from installer

  • Done
  • quality assurance status badge
Details
3 participants
  • Liliana Marie Prikler
  • Mathieu Othacehe
  • raingloom
Owner
unassigned
Submitted by
raingloom
Severity
normal

Debbugs page

raingloom wrote 3 years ago
(name . Guix Bugs)(address . bug-guix@gnu.org)
20220419012310.214697b3@riseup.net
I tried installing Guix with the installer, mostly to give LUKS a try
in a low effort way, but also to hopefully find some bugs. I succeeded
in the latter so far. :)

I did a manual partitioning, with an encrypted BTRFS root and an ext4
/boot. The layout was left over from a previous failed encrypted
install with automatic partitioning.

Long story short I got an error related to mkfs.btrfs, this I think has
already been reported, but Mumi's search is not great so I haven't
verified that yet.

The important thing is that I'd like not to reboot or start the
installation from scratch. Scheme has call/cc and continuable
exceptions and whatever, so could we let users at least attempt to fix
these errors manually?

At the very least it would let them gather more info for debugging.
Liliana Marie Prikler wrote 3 years ago
1cddf614be92399d4806df5fa943efb727fee554.camel@gmail.com
Am Dienstag, dem 19.04.2022 um 01:23 +0200 schrieb raingloom:
Toggle quote (18 lines)
> I tried installing Guix with the installer, mostly to give LUKS a try
> in a low effort way, but also to hopefully find some bugs. I
> succeeded in the latter so far. :)
>
> I did a manual partitioning, with an encrypted BTRFS root and an ext4
> /boot. The layout was left over from a previous failed encrypted
> install with automatic partitioning.
>
> Long story short I got an error related to mkfs.btrfs, this I think
> has already been reported, but Mumi's search is not great so I
> haven't verified that yet.
>
> The important thing is that I'd like not to reboot or start the
> installation from scratch. Scheme has call/cc and continuable
> exceptions and whatever, so could we let users at least attempt to
> fix these errors manually?
>
> At the very least it would let them gather more info for debugging.
As far as I'm aware you still have four open terminals after things go
wrong in the graphical installer. I'm not sure how much of the
automatic process actually mirrors the manual – we could aim for 100%
surely – but let's say you encounter an issue during mkfs as above,
then it'd be nice if Guix could just catch that error, check where we
are according to the manual, print out the backtrace and a nice message
"You can attempt to fix this by switching to manual installation and
continuing from SECTION/SUBSECTION." Perhaps add a "fix manually"
button that switches to VT3, as well as your typical "Redo
installation".

Cheers
Mathieu Othacehe wrote 2 years ago
Re: bug#55011: let user drop into REPL from installer
(name . raingloom)(address . raingloom@riseup.net)(address . 55011-done@debbugs.gnu.org)
87edu8thez.fsf@gnu.org
Hello,

Toggle quote (4 lines)
> Long story short I got an error related to mkfs.btrfs, this I think has
> already been reported, but Mumi's search is not great so I haven't
> verified that yet.

Installer now reports failing partitioning commands and offers to re-run
them or keep things going. This should cover your request.

Closing,

Mathieu
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 55011@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 55011
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help