feat request: prompt user to continue on failure steps

[vanillaSprinkles]

for example; if grub fails on the grub-install step, the user should be able prompted to keep going with the install script - perhaps a warning stating that continuing after a failure can yield unexpected results (and as such should not be recommended) ; or a flag that can be added to enable prompt-to-continue-on-failure with an advanced-user-warning

after inspecting the new-install area after it failed here, i noticed the fstab was not setup, other users, ect.

[svartkanin]

What would be the point of continuing an installation that will most likely be broken and unusable? Can you think of an application that actually does that?

[vanillaSprinkles]

I would not consider "archlinux" an application; an actual application, on failure, has a cleanup and revert component to it; there is no reverting a formatted SSD.

In this case, the archinstaller is basically kickstarting the OS with a heap (system) of applications. grub is not a requirement of Archlinux, and as such, should not completely halt the setup. The same can be said with many of the other steps, take users-creation for example, if for some reason the 100000th user i add breaks the script (where others were successful), it should not halt the next step. Another example would be a package being installed, if it fails, do we consider the entire setup of the OS a failure - currently yes; but giving the user an advanced option to continue-on-failed-step (prompt or not) can be greatly beneficial.

adding a continue-on-error helps not only to triage the installer, but can enable further improvements; if only one piece of the puzzle fails to install, and 99.9999% of it still works; i still want to be able to work with the system at the stage of 99.9999%. vs fail at the 2nd step of the installation.

[svartkanin]

Applications quite often do not have a safe handling of unexpected failures. There's no way an application can anticipate any type of possible failures and just handle that in a safe way.

Archilinus may not be an application, but archinstall very much is and therefore is required to handle unexpected things. When running the installer, there are destructive and less things happening. Formatting a disk without breaking existing partitions is a rusky one. Installing a package like pipewire is probably less risky. Classifying what counts as rusky and essentially for the OS to even start may be determinable BUT how would a user know?

Any step that breaks during the installation can have side effects when continued. Let's take the example of creating a user, if that doesn't work then what would a command do that installs a service and wants to add the user to the allowed group (docker), then that command would fail as well.
We can't maintain a dependency graph of steps and based on XYZ decide. On top of that reporting issues will be substantially more difficult as mentioned side effects lead to misinterpretations of an actual problem which then makes debugging even harder.

It is understandable that bugs are frustrating and we do our best to fix them but I don't think having a broken installation after running archinstall is any better

[vanillaSprinkles]

I dont think it should be considered an application but rather a series of steps to install loads of apps; similar to an ansible task but much less robust (ie: the user cannot resume from partial installs or skip steps)

I dont think maintaining a dependency graph would be required here, nor part of the ask - thus the first req to enable an arg/flag to enable the prompt, and a warning; if the later steps have a particular error and crash resulting from the first error (like user failing to add for some reason), then the user can keep continuing; its giving the users more power over the situation.

A failed install of an OS is a failed install, a broken install with or without 1 missing piece is really up for the user to decide - a user has 2 steps forward here when a fail happens, format and try again and hope to achieve a perfect 100%, or manually intervene.. expanding on the 2nd is what would be enabled by allowing the rest continue on errors