Re: Testing the installer
Hi Gábor, Gábor Boskovits skribis: > This is a bit off topic, but I am about to create an automatic > installer, that is > a candidate for a new backend. It currently works by providing a configuration > record, and then executes a few things from the installer. > > (It does a lookup for a candidate installation target disk, autopartitions it, > then injects the bootloader and file-system fields into an operating-system > template, and finally does a system installation.) > > I will have a look at the new protocol soon, to see if this project > can benefit from that. Yes, there may be things to share here. Alternately, the automated installer could directly poke at the installer’s APIs instead of being an external program. Something to discuss at the Guix Days! :-) Ludo’.
Re: Testing the installer
Hello, Bengt Richter ezt írta (időpont: 2020. jan. 24., P, 0:08): > > Hello Gábor, > > On +2020-01-23 12:21:27 +0100, Gábor Boskovits wrote: > [...] > > > This is a bit off topic, but I am about to create an automatic > > installer, that is > > a candidate for a new backend. It currently works by providing a > > configuration > > record, and then executes a few things from the installer. > > > > (It does a lookup for a candidate installation target disk, autopartitions > > it, > > then injects the bootloader and file-system fields into an operating-system > > template, and finally does a system installation.) > > > > Will your installer be able to create /boot and / images that will > work with Coreboot/SeaBios/grub legacy-only (not UEFI) bootable systems > (like PureOS)? It is based on the current installation image, and it accepts a Guix System configuration template, so it works on systems that Guix System can currently operate on. Right now the bootloader configuration is limited to that what the autopartitoning in the installer does for the option 'All in one partiton', which means that UEFI or legacy is autodetected, and installed accordingly. Does that answer you question? > > IOW, what kind of BIOS systems is it dependent on? > > > I will have a look at the new protocol soon, to see if this project > > can benefit from that. > [...] > > > > > Best regards, > > g_bor > > -- > > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21 > > > > -- > Regards, > Bengt Richter Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: Testing the installer
Hello Gábor, On +2020-01-23 12:21:27 +0100, Gábor Boskovits wrote: [...] > This is a bit off topic, but I am about to create an automatic > installer, that is > a candidate for a new backend. It currently works by providing a configuration > record, and then executes a few things from the installer. > > (It does a lookup for a candidate installation target disk, autopartitions it, > then injects the bootloader and file-system fields into an operating-system > template, and finally does a system installation.) > Will your installer be able to create /boot and / images that will work with Coreboot/SeaBios/grub legacy-only (not UEFI) bootable systems (like PureOS)? IOW, what kind of BIOS systems is it dependent on? > I will have a look at the new protocol soon, to see if this project > can benefit from that. [...] > > Best regards, > g_bor > -- > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21 > -- Regards, Bengt Richter
Re: Testing the installer
Hi! Mathieu Othacehe skribis: >> I’ve pushed ‘wip-installer-test’, which implements said protocol. See >> screenshot below! :-) > > Woow, that's impressive :) Glad you like it. :-) > I just gave you access to Guile-newt repository so that you can > integrate your changes. I will create a new release once its done. Thanks, will do! > In the future, I would have liked to keep open the possibility of having > one installer with multiple graphical backends (newt, gtk, cli). That > would mean that we would need to factorize the protocol part in the > backend agnostic part of the installer. > > Anyway, for now it would be completely over-engineered, as we don't know > yet if a new backend will come one day. Yeah, I think that can come later. > Please let me know if you want help on some point but, I think that I'll > try to tackle the "installer cannot restart issue". It’d be great if you could address that issue! For my part, I’ll try to get with at least one test to make sure the approach is viable. Then I’ll need help to write new tests and to improve things here and there. Also, for 1.0, we had also messed up with things like MATE. I’d like us to have system tests for the desktops we propose: GNOME, MATE, etc. That would mean at least ensuring that a config like that of ‘desktop.tmpl’ allows us to log in via GDM, and then to start a terminal in the desktop (I suppose we could do that using the keyboard, with ‘marionette-type’ etc. NixOS tests are a good source of inspiration: https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/gnome3.nix Help welcome! Ludo’.
Re: Testing the installer
Hello Mathieu, Mathieu Othacehe ezt írta (időpont: 2020. jan. 23., Cs, 10:42): > > > Hey! > > > I’ve pushed ‘wip-installer-test’, which implements said protocol. See > > screenshot below! :-) > > Woow, that's impressive :) > > I just gave you access to Guile-newt repository so that you can > integrate your changes. I will create a new release once its done. > > In the future, I would have liked to keep open the possibility of having > one installer with multiple graphical backends (newt, gtk, cli). That > would mean that we would need to factorize the protocol part in the > backend agnostic part of the installer. > > Anyway, for now it would be completely over-engineered, as we don't know > yet if a new backend will come one day. This is a bit off topic, but I am about to create an automatic installer, that is a candidate for a new backend. It currently works by providing a configuration record, and then executes a few things from the installer. (It does a lookup for a candidate installation target disk, autopartitions it, then injects the bootloader and file-system fields into an operating-system template, and finally does a system installation.) I will have a look at the new protocol soon, to see if this project can benefit from that. > > Please let me know if you want help on some point but, I think that I'll > try to tackle the "installer cannot restart issue". > > Thanks, > > Mathieu > Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: Testing the installer
Hey! > I’ve pushed ‘wip-installer-test’, which implements said protocol. See > screenshot below! :-) Woow, that's impressive :) I just gave you access to Guile-newt repository so that you can integrate your changes. I will create a new release once its done. In the future, I would have liked to keep open the possibility of having one installer with multiple graphical backends (newt, gtk, cli). That would mean that we would need to factorize the protocol part in the backend agnostic part of the installer. Anyway, for now it would be completely over-engineered, as we don't know yet if a new backend will come one day. Please let me know if you want help on some point but, I think that I'll try to tackle the "installer cannot restart issue". Thanks, Mathieu
Re: Testing the installer
Hello! Mathieu Othacehe skribis: > That sounds like a nice idea! I guess we can discuss it more deeply > during Guix Days, but here are a few thoughts: > > * Testing from a VM won't cover HW issues with undetected wifi networks > and kmscon rendering issues, but could cover most partitioning issues. Yeah, but for that we need manual testing, there’s no other option. > * This kind of client/server protocol would make even easier to > switch to a gtk graphical installer. Well, if we replace the explicit Newt calls with a higher-level interface, yes. Besides, the protocol may prove useful for accessibility because it provides semantics. > * Before the next release, it would be nice to fix the "installer always > fail when restarted" issue than has been bitten lots of people. Yes! I’ve pushed ‘wip-installer-test’, which implements said protocol. See screenshot below! :-) What’s left to do now is to write an actual test that uses it. Speaking of which, does anyone know if there’s a way to share a Unix-domain socket between a QEMU guest and its host? (Over 9p?) Thanks, Ludo’.
Re: Testing the installer
On Sun, 12 Jan 2020 18:34:54 -0500 sirgazil wrote > On Sun, 12 Jan 2020 17:13:54 -0500 Ludovic Courtès > wrote > > Hello Guix! > > > > One of the lessons from the 1.0.0 screw-up was that we should test the > > graphical installer itself: > > And, if possible, not test only using virtual machines, but real ones, > because I remember my installation in a virtual machine went smoothly, but > installing in my real machine was rough (network devices not detected, > installer generated config.scm with truncated UUID, unknown error when > trying to restart installation). > By the way, in my old notes about my installation of the Guix System 1.0.0, I have something about a problem related to the order in which the installer checks for network availability. My computer had another OS installed at that time. If I recall correctly, I started the Guix System installation process, told the installer to use the whole disk for installation, and only after formatting the disk, the installer told me there was a connection problem, and I couldn't install the system. So I couldn't boot to the old OS at that point. Fortunately, people on #guix helped me solve the network problem (related to bug) and I could install the Guix System. So, if this is still the case, I think the installer should check for network connection before attempting to do any destructive operation. --- https://sirgazil.bitbucket.io/
Re: Testing the installer
On 12.01.20 23:13, Ludovic Courtès wrote: Hello Guix! One of the lessons from the 1.0.0 screw-up was that we should test the graphical installer itself: https://guix.gnu.org/blog/2019/gnu-guix-1.0.1-released/ I think we should try to do that before the next release; not doing it means testing by hand, which also takes a lot of time. I did a quick test by hand and opened a bug: https://issues.guix.gnu.org/issue/39199
Re: Testing the installer
Hello Ludo, That sounds like a nice idea! I guess we can discuss it more deeply during Guix Days, but here are a few thoughts: * Testing from a VM won't cover HW issues with undetected wifi networks and kmscon rendering issues, but could cover most partitioning issues. * This kind of client/server protocol would make even easier to switch to a gtk graphical installer. * Before the next release, it would be nice to fix the "installer always fail when restarted" issue than has been bitten lots of people. Thanks, Mathieu Ludovic Courtès writes: > Hello Guix! > > One of the lessons from the 1.0.0 screw-up was that we should test the > graphical installer itself: > > https://guix.gnu.org/blog/2019/gnu-guix-1.0.1-released/ > > I think we should try to do that before the next release; not doing it > means testing by hand, which also takes a lot of time. > > One idea that I had was that we could change the installer so that it > listens for connections on some pre-defined Unix-domain socket. When it > gets a connection, it would perform a dialog with its client: sent it a > summary of the current form, wait for its choice, and so on. The forms > would thus be unavailable from the keyboard: essentially ‘run-form’ > calls would be replaced by ‘draw-form’ calls in that mode. > > Our test infrastructure would thus connect (from a marionette) to the > installer and participate in that dialog. It could even take a QEMU > screenshot at each step. > > How does that sound? Am I overlooking things? > > I guess the difficulty will be to represent questions and answers. > > Ludo’.
Re: Testing the installer
On Sun, 12 Jan 2020 17:13:54 -0500 Ludovic Courtès wrote > Hello Guix! > > One of the lessons from the 1.0.0 screw-up was that we should test the > graphical installer itself: And, if possible, not test only using virtual machines, but real ones, because I remember my installation in a virtual machine went smoothly, but installing in my real machine was rough (network devices not detected, installer generated config.scm with truncated UUID, unknown error when trying to restart installation).
Re: Testing the installer
Hi swedebugia, > I see two branches with wip-installer. > > What is the difference between those? Wip-installer2 having a newer master > merged in? The “wip-installer2” is newer and has seen more work than the original “wip-installer”, which has been abandoned. If you want to work on it I recommend looking at “wip-installer2”. > I would like to try installing via the installer to test it. Is it working? I don’t know. From what I remember it still had some rather rough edges and was less guided than you would expect from other installers. > Can the installer handle dual-boot detection/setup yet? I don’t think so. -- Ricardo
