I am wondering if there might be a way to install a system directly from the ISO without the need for booting to a live environment and using an installer, graphical or text/cli based.
I am thinking of the possibility of “unpacking” the image into a subvolume on a BFRTS partition and make it bootable somehow (how?) or just boot up the kernel image directly from a Grub command line?
Does this make any sense or could it be feasible?
(I have not used btrfs specifically.)
Arch is installed via a live ISO. But you could do the same via an existing Arch/Endeavour install I suppose. You need this package called arch-install-scripts. Should probably be doable with btrfs too.
I’m not aware if unpacking a tarball is possible with Arch, but Gentoo does exactly this for the initial bootstrap.
Edit:
Live ISO is a fully functional environment so extracting it in a partition could work in theory. Never tried this though.
I actually tried this twice last evening. It all went fine. Mounting the root subvolume, chrooting into it and installing the system.
My idea was to run os-prober from the “ordinary” installation in order for it to discover the root subvolume and add it to Grub boot menu. However, the system was unbootable.
Suspicious of the boot mode, the second time I tried, I verified the boot mode:
ls /sys/firmware/efi/efivars
and the output implied that it was not in UEFI mode. Maybe the reason for the boot failure from an UEFI grub?
This is actually what triggered me wanting to try this.
Let me spin up some virtual machines…
Even I would do the same.
Edit: Be patient though. My network isn’t fast, so downloading packages take a bit of time.
I was inspired by some recent posts on the forum about converting the root of a system from EXT4 to BTRFS. In some thread @dalto mentioned that he usually does this for those which doesn’t have an installer supporting BTRFS.
Therefor the idea of using only the ISO:s of such distros and directly extract it to a subvolume on a BTRFS partition and hopefully be able to make it bootable.
No problem! I appreciate so much that you are taking interest in this and are willing to try it out. Thank you!
Btrfs is a thing I’m not much knowledgeable about. I’m doing my install on the good old ext4. Will that make a difference?
Edit: Missed the “not” 
I don’t think it should in practice apart from the difference in specifying where to find the kernel image:
menuentry ‘Arch Linux’ --class arch --class gnu-linux --class gnu --class os $menuentry_id_option ‘gnulinux-simple-4e33451a-4483-4d0a-9fee-c48e63991416’ {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 4e33451a-4483-4d0a-9fee-c48e63991416
echo ‘Loading Linux linux-zen …’
linux /@/boot/vmlinuz-linux-zen root=UUID=4e33451a-4483-4d0a-9fee-c48e63991416 rw rootflags=subvol=@ lsm=lockdown,yama,apparmor,bpf loglevel=3 nowatchdog
echo ‘Loading initial ramdisk …’
initrd /@/boot/intel-ucode.img /@/boot/initramfs-linux-zen.img
}
So I installed Arch the Arch way via an Endeavour VM. It boots perfectly fine. Os prober worked.
Next step is to actually try extracting the ISO. On to it…
Wow, that sounds great!
Is your EnOS’ VM MBR/legacy?
Perhaps I am wrong, but when I tried last evening, I got the idea that the chroot-environment was as if though you have booted up the iso in Legacy mode. Hope my wording is adequate and not confusing. Therefore I couldn’t boot up the newly installed system from the UEFI Grub of the original system.
I even created a custom.cfg for it with the exact path to the initramfs and kernel image of the new system but no joy.
Since
ls /sys/firmware/efi/efivars
failed, maybe installing efivar would have helped?
Yes. ext4 on msdos layout.
IIRC, chroot comes from the Unix days. It simply changes the root to a different path. You could make a directory structure following the FHS at any folder, and then “chroot” into it. arch-chroot is a wrapper around the chroot command. It automatically opens the shell on the chroot directory. If using basic chroot then after the mount point, you also need to specify the shell location.
It shouldn’t have to do anything with EFI or legacy.
I didn’t need to mess with grub or kernel image.
Possibly EFI systems need more mind power 
Edit : Yes chroot is from Unix era. Its listed under “containers” so you can guess the purpose. 
Edit 2 : You might not need an FHS directory structure. As long as the shell can be started, I suppose chroot would work. Probably need a person more experienced to throw some light 
I guess that explains it.
Is this why you get /bin/bash not found sometimes? I get stuck at point 
If not more mind power, another treatment surely 
And thanks for the link! I’ll have look at it!
This is a bit above my paygrade, but I guess a little struggle will pay off!
Thanks @flyingcakes for your time and effort! I am really excited to see if this can be worked out. Specially for those distros with non supporting BTRFS installers, installing from the ISO directly might be a nice workaround.
Assuming you have the partition mounted, this is command for chroot 
chroot /path/to/new/root /path/to/shell
/path/to/shell is relative to the new root.
So for my Arch install I’ll do this
su
mount /dev/sdb1 /mnt
chroot /mnt /bin/bash
Surely gonna help you 
Great! Thanks!
I can see some cakes coming flying my way! I better put the kettle on!
I need to get to do some things offline! Thanks so far and see you later!
It depends on the ISO. Some ISO’s have fully featured live systems, some have systems packed into compressed containers, some have have compressed disk images others create a minimal chroot and then install all the packages.
Just realize that if the ISO in question is capable of being unpacked like that, there are still things that will be needed to turn it into a working system. At the very least, you will need to:
/etc/fstab/etc/machine-idDepending on how you unpack it what is on the ISO there may also be cleanup that is required such as removing things that only made sense on the ISO.
I might be able to provide some alternative approaches if you explain why you want to do this. Without understanding the end goal it is bit tricky.
Get the drinks ready! 
About 3 hours later, I’ve done it 
Could have been done much quicker, but I didn’t know the steps. Hit and Trial is slow process.
I’ll brief out the steps I followed to install the Endeavour OS Live environment without booting it. I think you know Arch installation steps, because this is not a detailed guide.
/mnt.sudo mount -o loop,ro -t iso9660 filename.iso test_folder
arch/x86_64 folder. Copy the file airootfs.sfs to a location where you have write permission (like your home directory). cd into whichever folder you copied this file. Run this command:sudo unsquashfs -f -d /mnt airootfs.sfs
This will copy the live environment into the partition.
5. Use arch-chroot
arch-chroot /mnt
In case of non arch distros, you’ll need to mount locations first.
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
WARNING : I’m not 100% sure if you need to pass different flags to mount. This worked for me, so I am mentioning. I was in VM so I did not risk messing my system, but if you do this on bare metal, then be careful. Consult someone more knowledgeable than me.
Now you can chroot
chroot /mnt /bash/bin
Further on, you just need to change the live system to something that you would actually install. In this case, I had EndeavourOS ISO, so things I mentioned are related to this distro only.
Remove stuff I don’t want. Because live ISO may have extra stuff. In my case, I did not need nvidia packages. So run pacman -Rns ...
Run systemd-firstboot. See below links for more info
https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html
https://wiki.archlinux.org/title/Systemd-firstboot
Set stuff like hostname (/etc/hostname), hosts file (/etc/hosts), locale file, time/timezone, keyboard layout and fstab. Also add users and configure sudo if needed.
Edit /etc/mkinitcpio.conf. Scroll down to the HOOKS option which has many parameters given. Change the line to this
HOOKS="base udev autodetect modconf block keyboard keymap filesystems fsck"
Of course feel free to add or remove modules if you know what you are doing.
This step is VERY important. mkinitcpio is arch specific tool. When installing different distro, you may have to deal with a different tool. So check with the distro devs or forum.
Specifically speaking, this step is important because with the default configs, your initramfs is set to look for a device with a certain label. (when you create live USB, it gets a label, which is used to identify and boot later on). So having this on your normal system makes it unbootable. Removing the extra live iso related modules from mkinitcpio and populating it with stuff thats there on a normal system will fix it. (you’ll have to rebuild initramfs; thats done in next step)
mknitcpio -p linux
Finally install grub (or whichever boot loader you want)
Enjoy!
I’m past the dinner time. Good night 
I probably made some errors in typing this, I’m sleepy. So if you’ve got questions, I’ll come back tomorrow. 
installing without an installer … is basically the archway to “install” a system 
EOS-ISO itself using an systemimage to run livesession, and do offline installs…
So you could simply create a systemimage and unpack it to another device … like drive cloning would work…
Thank you so much @flyingcakes !
That was a heaven of a post/cake coming flying at me. I didn’t expect to be met with the whole solution when I logged in. Great job, sir!
To be honest, I need to read all this stuff and perhaps some more to digest this whole thing. Hopefully during the weekend I will find some time to do so. I guess the best course of action for now is to try things in VMs.
It’s now way past midnight around your longitude, so happy sleeping!
And thanks again!
Thanks @joekamprad for your reply!
True. Not adequate wording for what I wanted to ask, namely
or the kind of environment you boot into with Arch, non-graphical or what is it called. At any rate you would need to burn it to a flashdrive an boot it up.
I’ll need to reply back to @dalto a bit later on. I just made the OP hastily without going into any details about what I want to achieve. Hopefully it will become more clear.
Grateful as always for your great explanations, thank you @dalto!
I’ll post back a bit later on detailing what I had/have in mind and what I want to accomplish.
So long!
Now that I think I have guess of what you may be trying to do, I can share how I get a Linux install into a subvolume.
I install into a VM and then btrfs-send the subvolume to the host. This has the advantage of still leveraging the power of the installer and ensuring everything gets set and cleaned-up properly. It also allows me to do some configuration in the VM before shipping it to the host.