H2T (Host-to-target) installs and prevent host pollution

[h8d13]

This is a follow up to my last PR#3928 and original ISSUE#3599

What we achieve with such a patch:

• Prevent polluting the host by having a hacky running_from_host definition
  • Skip set_kb_layout (will be set on target only) via installer.set_keyboard_language() and set_vconsole()
• This is added to main __init__.py to print: EXAMPLE:

Fetching Arch Linux package database...
Checking version...
Running from host (H2T Mode)...

Or Running from ISO (Live Mode)

And will be present in logs to have a trace too (useful if outdated system deps or straight up missing deps).

End result: Makes it so that if you are installing say from a US layout computer and target uses a different layout (ex: laptop), we do not modify the host system and can be built-upon for other host-checks if needed (say for example: extra deps checks or other host isolation related needs).

• Readme clarification Host to target installs without an ISO!
• Pyright type annotations fixes (was giving me errors but can revert it if needed)

[svartkanin]

I understand the intention of the PR but I'm not a big fan of deviating behavior depending on where archinstall is run as it will make things more complex.

Having said that I do agree that modifying the host system is not a good idea and I hope to find an alternative option that behaves the same as well, from a quick look:

• localectl seems good for the console as permanent changes are short lived there anyways
• setxkbmap only seems to work on X11 sessions

So I guess the options would be

1. Don't modify anything anywhere and the user has to set it up manually outside of archinstall
2. Find a solution that sets it temporary but that requires host inspection and different tools for different systems
3. Accept the different behavior BUT display the current keyboard layout in all inputs so there less confusion

@Torxed any thoughts?

[h8d13]

Thanks for the feedback @svartkanin

It might seem a bit too hacky but makes sense with how it works (usually from live medium but why not from an existing install).

We just need to be able to differentiate maybe you have a better solution or better spot for it (I thought early is better) and make it abstract bool so that it can be re-used.

It doesn't really affect much of the rest is more just of guardrails for H2T. The key here: is just the return early here and makes a lot of sense. And still sets for target !

(Please feel free to modify the rest!) ,because again it would just make it so that we do not touch the host's settings, if in live-install scenario vs being on an live-medium (where we don't care).

If anything I don't think it adds much complexity but clearly states what archinstall should behave like in different scenarios. I've had run manually countless times before I found this hack and I think is one of the cooler parts of archinstall is not needing an ISO at all and being able to use your current install to create others :D

About your other solutions I don't think it addresses the root cause: Unless we use loadkeys which is only for the current session/tty. But again still wouldn't make sense in ISO vs on running system

[svartkanin]

So the assumption after this will be

• If on ISO a user has probably not setup the desired keymap yet and archinstall will do it automatically for them whenever a new layout is choosen
• If on host, a user will use their preferred keymap already and most likely the target will have the same (in which case there's no need to set it)

To avoid confusion I'd still like to have the current keymap displayed in any input (can be done in a future PR as I have some major migration to textual upcoming)

[h8d13]

• If on host, a user will use their preferred keymap already and most likely the target will have the same (in which case there's no need to set it)

This is where the issue is, if on host and select a keymap (different from host) I've polluted my host but only wanted this in target (and assumptions that they are the same is just wrong).

I've had this many times installing for laptops (forced into a different keymap) from my main setup (us).

I think the loadkeys (set in session only) + running from host def seems like a good solution (see comment on code, could be re-used for other things).

Again thanks for follow up ! And hopefully this makes more sense now. Sorry if I was unclear, it's a weird case I get a lot with French/Belgian layouts.

[svartkanin]

I think the loadkeys (set in session only) + running from host def seems like a good solution (see comment on code, could be re-used for other things).

I'm not too keen on using a tool that is not supported on Wayland as most system will be on Wayland by now. So this will add another layer of behaviour that needs to be understand as just looking at the code path is not enough.

If you can change the info to debug I think the PR is fine