Well, meet us halfway there and maybe take a look at Calamares’ inability to format existing LVM’s? Gets your hopes up too! Letting us work with VG’s, set flags and mountpoints, then bam! Fail.
Afaik. Calamares’s documentation makes it clear it can’t create LVM’s, however manual partitioning should have no problem handling preexisting VG’s. Please correct me if I’m wrong.
Inside manual partition calamares offers to change and create LVM, but it is simple not working at all.
Precreated one will cause install to fail, playing with LVM inside calamares will cause calamares to crash.
We do not want to change the code of calamares itself, as it should be solved upstream.
It hopefully will be solved in a fututre release of calamares, but if there is much need for very custom installations, could have a look at architect, better use a CLI installer then failing and tinkering hours with a gui installer…
where you read this?
Documentation is poor phrasing, take a look here.
Should have been more specific: LVM on LUKS is not supported, or broken atm. More important is the fact it supports LVM’s, even within a LUKS container, but can’t install to them. Definitely a bug upstream, not EOS’ doing. 
Nor should you, your hands are already full (i.e. netinstaller).
Sorry for the interruptions.
I second this.
A swapfile is just more flexible and I haven’t had any issues even with hibernation on an encrypted system.
Could be easily scripted; see #22 … of this Howto
(Edit: @joekamprad)
Really excited and looking forward to this!
Didn’t think of hijacking Manjaro-Architect at a certain step; beautiful.
Maybe not that much work to fork for EOS as I initially thought.
And if one would use btrfs as filesystem there’s no more need for a separate /home, and no need for a 3rd partition for snapshots, which means you really only need 1 partition inside luks, which in consequence means you don’t need a logical volume either. A lot, lot simpler?
You may have a point there but I got burnt heavily in the early days of btrfs and experimenting with snapshots etc.
I know my way around LVM quite good and have never had a problem I couldn’t recover from, so personally I prefer and will stick to LVM for the foreseeable future.
Maybe just me getting old and unflexible; but “whatever works” and “never change a running system” are motto’s I try to live by.
The power of lazy compelled me. 
The only step M-A environment can’t replicate/replace is the EOS installation itself; everything else can be done live.
installation is mostly a package list and settings, settings for xfce are there on creating a new user (/etc/skel) on the EOS-ISO needs only to setup grub theme and lightdm settings with a script.
M-A is using scripts from Manjaro to install different Desktops vanilla or themed, this is the popint where it stuck, as they are not available.
We’d need M-A to fetch EOS’s XFCE iso profile, replace mirrors, rename dependencies with a “manjaro-” prefix to their (proper)Arch counterparts, and amend grub-install, hostname, grub.cfg, among other configuration files, to represent EOS.
Look at manjaro-chroot for instance, it’s an arch-chroot knockoff.
One of my main issues with Manjaro is exactly this unnecessary rebranding of pure arch stuff.
Manjaro-Architect itself was once a pure Arch installer. It would be awesome for the whole arch family if one could easily adapt it to install any arch based distro with it (=> new Architect installer).
Hopefully, Manjaro is finally giving back
Very nice what you’re doing here guys.
I like how community takes the lead here 
Do you think manjaro-architect evolved more than Architec/Pacbang installers?
I don’t know, now; I hope I can one day see Openbox as in Pacbang, hopefully !!!
I find it interesting,
maybe serve still …
Everything is going well with the tutorial. At some point M-A repopulates /etc/default/grub, duplicating some values. First I thought this’d dissuade people from pulling through, however if EOS /etc/default/grub is removed, M-A will add one in its place without duplicate values, but only once. Not sure which script carries it.
TL’DR Need more time, learning cool things by accident.
EDIT: Ah, figured it out! M-A will amend entries in /etc/default/grub only if three things are true:
/etc/default/grub exists.grub file exist.Executing “Install Bootloader” will fill in the blanks as many times, and for as long all three are true.
Really you want to go back to the clean code of the Architect arch installer not from the already duct tape M A installer that is a clone so your effort is just a clone of a poor clone. Then work on encpytion that is where -Carl and I left off,
You will get no help from Me we walked away from the project never to return. I should imagine all the code is still on git hub.
Don’t get me wrong Matei has done a good job but to many parts of manjaro are not Arch related by the time you rip out what you don’t need you are left with a vulnerable installer go back to the original work from their, I can tell you up-to 6 months ago the installer was working fine just a couple of package changes that says it all after being abandoned for 4 years.
My plan isn’t to rewrite the scripts, but to use Manjaro Architect “As-is”.
@Chrysostomus has built something great on top of the original project. Can not dismiss efforts, even in their absence.
Should the Endeavour OS team decide to fork M-A, they’d need to switch dependencies to Arch Linux counterparts, including mirrors. What easier way is there to prove its worthiness than by successfully spawning custom EOS installs, without Manjaros’s presence on disk.
I think you are really missing the whole point.
MA is a great installer for Manjaro I endorsed Chrysostomus when he asked me if i would be happy to allow the installer to be forked. But it like saying can Ford build a Cammaro no they can’t Mattie had to change many things to make the installer viable for Manjaro,
Apart from being loosely based on Arch Manjaro and Arch are chalk and cheese, Arch is simple by design, simple to maintain, Manjaro tries to be simple by complexity, Every thing is to not be anything like Arch apart from using the Arch name. I have not had a update fail in years with Arch, Manjaro breaks regularly, simplicity always wins over complexity every time.
That is why I believe using the MA installer is a bad move. Keep as close to Arch as humanly possible it would be better to consult Artoo at Artix to sort out Calarmas as he made the net installer usable and then dropped it.
We also made the pacbang offline installer Ant has been using it for his KDE and Deepin Arch Installs he told me he did just minimal changes it just works the simplest installer he has used, But does needs updating for encryption for lazy users.
I would also read this from this post, Manjaro discourages use off any of its tools I tried to do a review of Endeavour and got flamed by "hardcore users"
The same thing (somewhat) happened to me with the Manjaro community.
One day there was a creator of CondresOS on the forum. He (or she) introduced themselves, told of their project which was based on Manjaro. I replied back to them diplomatically and encouraged them to keep up the good work. Their main language was Italian and they were typing in English. Now sometimes when a person isn’t fluent in a second language points sometimes do not come across as they should. So I read between the lines, understood what they were saying, and had quite the pleasant chat with them.
Unfortunately, one of the founders of the Manjaro took offence to what the creator of CondresOS was trying to do, with his/her website, and proceeded to belittle the creator of CondresOS. That lead to a flame war from some of the community towards myself and the creator of CondresOS - of which I was quite shaken afterwards. Since then I have refused to use Manjaro or any distro that uses them as their base - because of that flame war.
The main point of that regretful interaction I had is this: Yeah the Internet world is full of flamers; and some thrive on flaming others - just because. But don’t let that deter you from wanting to find out more about Arch and writing about the experience. Your thoughts on reviewing Endeavour will absolutely help this distro grow. And I can honestly tell you: the flamers will be found out for who they are.
As my family says: Pick yourself up, dust yourself off, pick your chin up, and learn all the good things from the experience. And yes there is a lot of good to learn from any bad experience; all you have to do is find those good things!
Dan Ackles (midfingr) - R.I.P - was probably one of the biggest teachers i’ve found on youtube.
Thanks to him i made my own isos 3 years ago (Portergos), in a certain way EndeavourOS also depends in his legacy. The iso was built on my learnings after his videos of course, but i also believe @joekamprad also used his tutorials in first initial isos too.
Since he was the PacBang iso developer i always thought him and Carl Duff were the only responsible people for developing abif (he forked architect installer).
Saying this, it’s a pleasure to meet you @mandog. If you or the community decide to use abif from Pacbang or the offline installer from Portergos (i can upload a cleaner/latest version) i’d be very happy with this.
So there is no need argue about manjaro-installer, it’s up to you community to decide which path you want to choose.
OBS1: None of the developers have time to work in another installer (CLI), but i totally support that idea, since i prefer cli installer really and i understand that calamares has a big gap cosidering encrypted partitions/installs.
OBS2: This is my opinion, i’m not talking in the name of other developers.
Mid finger was a great inspiration to Linux but no my friend Carl was the Developer of pacbang it was inspired while he was involved with Manjaro I was the one that inspired him to build Manjaro bang then pacbang. He followed my own install I only have ever worked with Carl in the last 10 years.
I have nothing to do with any of it now but i would endorse the use of both installers as they both work