Carl Duff and Mandog's Architect Approach, a Possibility?

General system EndeavourOS installation
1

Manjaro’s very own one-man army @Chrysostomus forked Carl Duff’s and @Mandog’s Architect, creating “manjaro-architect”.

Originally, it only installed Arch. Now (don’t quote me on this) it can install both, at least it should be able to. M-A is a “TUI Netinstaller”, as in, online-only installer.

Have read this distribution lacks an online installer (for now), perhaps an EOS-Architect delivery method could take its place until then?

Just a thought. :exploding_head:

4 Likes
2

We’re still hard at work to realise the netinstaller with Calamares and the progres and potential seems very exciting and promising.
At this point in development it’s better for us to focus on one installer, the advantage of Calamares for us is that we can offer the offline installer and the online installer unifide in one, so the user can choose for either one in the install process.

6 Likes
3

Calamares is a great installer, born out the projects of netrunner-rolling & manjaro with kaos. becomming these days the installer that adopting a pretty range of distro’s from Debian based to arch is very great. sure Architect installer is comming because , manjaro disposed there cli installer. And community infact took the architect installer to have that option again. But to have both in one, is better , also in maintainance and feedback. Mayby somedistro can 30 iso’s out each month but thats more in quantity, good to aim at quality, having one iso is good ^^ :slight_smile:

5 Likes
4

Ah! Both the granularity of a netinstaller for powerusers, and reliability of a friendly offline installer interface. Very exciting news indeed! :partying_face:

Sounds very ambitious, is git the best way to track progress?

1 Like
5

The netinstaller isn’t going to be for powerusers only, it’s going to be a friendly and easy way to install the desktop of your choice.

6

Risky assumption, my mistake. Pictured an architect-like installer experience and got carried away.

Here’s an issue that could affect EOS installer(s): FDE implementation runs the risk of crowding LUKS key store.

Seeing as boot/ encryption is an option, it’s likely already an issue waiting to ruin somebody’s day.

Here’s how/why:

EOS encryption solution (partition selection stage) incorporates boot/ by default. That’s great (for me at least). manjaro-architect has an “encrypted boot” option, which establishes an indistinguishable FDE environment. That is to say, both EOS and Manjaro ocupy two LUKS keyslots:

  • key-slot 0 User-generated passphrase.
  • key-slot 1 Randomly-generated keyfile (embedded in initramfs)

So far we’re good! Unbeknownst to us however, our imaginary guinea-pig " Jane Doe", is dealt tremendous misfortune. Now she has to restore/reinstall the bootloader! In Manjaro, doing so yields duplicate entries, here’s an example:

  • key-slot 0 User-generated passphrase.
  • key-slot 1 Randomly-generated keyfile (embeded in initramfs)
  • key-slot 2 User-generated passphrase (Entered in key-slot 0)
  • key-slot 3 Another randomly-generated keyfile.

We want to avoid this in EOS, whilst leaving the door open for friendly bootloader recovery.

Here’s what I recommended over at Manjaro Forum back when:

  1. Check for LUKS
  2. If yes, search for encrypted boot presence.
  3. Prompt for existing passphrase.
    • Match passphrase with corresponding, randomly generated key (encrypted boot) to avoid --test-passphrase false negatives.
  4. Correct? Reinstall bootloader only.
    • Incorrect? “No key available with this passphrase” > proceed? y/n.
  5. “n” = Insert new key or key pair (encrypted boot)? y/n
    • “n” = Reinstall bootloader only.

Implementing something like this (in theory) wouldn’t work in a “userfriendly” netinstaller hybrid (too many variables?). It’s something to keep in mind though, so that when an EOS user needs to repair their bootloader, everything goes well.