Cinnamon version fails to boot when selecting BTRFS during install.
Tested on several machines and also tested other Manjaro Cinnamon spins and same result. Installer is broken for BTRFS installations.
See screenshot. That is what you get when trying to boot after installation.
The error would seem not to have anything to do with BTRFS.
It seems more likely a broken file resulting from a bad write of the ISO to USB. This can happen easily; which is why I typically recommend using Ventoy, and booting directly from the ISO.
Nope. Tried full version, minimal version and the Spins by Kilz version.
Same effect on all. The installer is broken when selecting BTRFS.
Install fine as EXT4.
BTW, I use ventoy all the time.
It just makes sense. 
The error still doesn’t seem to indicate much apart from the broken file; so, it’s difficult to understand based on the error itself.
Have you tried another distribution (maybe XFCE) to see whether it is indeed limited to the Cinnamon distribution?
Manjaro Cinnamon is one of the community distributions; I don’t know who actually maintains it. I’m downloading it now to see if I can reproduce the issue in a VM.
Installing now - Manjaro Cinnamon 24.0.2-240627 - Latest ISO.
Aside:- It’s nice to see dark mode working in the Live installer.
Using the Erase Disk partitioning method; which presumedly was also used by the OP.
Confirming an error on first (and subsequent) boots…
error: start_image() returned 0x8000000000000001.
Failed to boot both default and fallback entries.
After a few seconds the Grub menu presents, but fails to continue automatic booting. Activating the first entry with a keypress fails, with the following error:
error: you need to load the kernel first.
Not the error the OP describes;
error: premature end of file /@/boot/amd-ucode.img.
but an issue nonetheless. 
Hopefully, a moderator @Aragorn can place this before the eyes of whosoever needs to be contacted (Manjaro Cinnamon).
Cheers.
There are currently two Cinnamon ISOs — note: they are not distributions, because it is all Manjaro — on offer…:
the common Cinnamon release currently maintained by @Yochanan — who is suffering from severe health issues at the moment, so cut him some slack — and…
a tentative release put together by @cscs.
However, @kwag also reports the same btrfs problem with the SbK spin, which uses the same calamares installer as all Manjaro editions. Therefore, switching to a different ISO is probably not going to make any difference, and I think I know where the problem lies. 
The thing is that the kernel images and initcpios are stored under /boot, and if /boot is on the root filesystem — as opposed to on a separate partition — then with the root filesystem being btrfs, naturally, the contents of /boot will be living on btrfs as well.
In and of itself, this is not a problem, but the regular grub does not support this, because grub — which needs to load the kernel image and initramfs (including the microcode file) into RAM — does not support sparse files, which are part and parcel of the copy-on-write principle of btrfs.
So, the solution would be to either…
disable copy-on-write on the initramfs and microcode files via chattr — see the man page; or…
use grub-btrfs instead of the regular grub; or…
use a separate partition formatted as ext4 for /boot — which is how I myself have done it here; or…
don’t use btrfs altogether.
Truth be told, most people here who use btrfs are not using it because of what it is and what it can do, but either because of the (partly false) sense of security they get from being able to roll back their system to an earlier snapshot — those are not actual backups, hence “partly false sense of security” — or simply because they think it’s better somehow — which it actually is — without understanding first thing about it, not dissimilar to how people always want the latest version of everything because “Oooh, shiny!”
Manjaro KDE works just fine. The problem is with the Cinnamon version.
Well, I don’t know much about using BTRFS, and while that would no doubt change if I actually had a need for it, some points are at least obvious (from this perspective) – for example I might; create a separate partition for /boot outside of the BTRFS container; possibly do the same with swap, unless it was to be encrypted; and use the manual partitioning method to design the layout exactly as I wanted – Even so, with comparatively little experience with BTRFS, my first resolve would be not to use it.
You might consider the points made by @Aragorn – in particular, don’t use BTRFS altogether – unless you are confident with the other points mentioned. Only you can know. 
I personally am using EXT4 as I have for many years, and haven’t found a need to change; though I have been procrastinating about using BTRFS in a VM for some time; and this would have otherwise been a good opportunity.
You’re kidding, right?
How about messing up some config files and then having to reinstall everything because of no rollbacks available?
How about BITROT (silent corruption) on EXT4, etc. which is non-existent on BTRFS?
What about full files checksumed on BTRFS, which function is non-existent on EXT4 FS?
Not to mention file system compression/dedup which is also non-existent on EXT4 (and family).
That is the truth to be told, and I have messed up sometimes because we are not perfect (dev here, BTW) and there’s nothing better than being saved after doing a # rm -rf /etc OR rm myfile. * and OUCH!!! (or some other stupid thing) and you know what happened!, and then you can simply reboot and rollback to the last snapshot. Just that easy!
It’s 2024. We need this features as default on every filesystem and every Linux distro.
Just like OpenSuse did, Garuda, Arcolinux (with a couple of lines), SpiralLinux, GeckoLinux and last but not least, FreedomBOX, also Debian based.
The benefits are just too many to ignore.
(BTW, the “rm -rf /etc” which leaves the system completely unuseable, is an actual test I did just to verify if indeed snapshots are reliable. And they are 
Swap can still be encrypted if it’s a dedicated swap partition — all you need to do is put it inside the LUKS container.
The tendency for people to want to use a swap file instead of a swap partition is an asinine habit from Microsoft Windows and Apple macOS.
A dedicated swap partition without a filesystem on it is always going to perform better than a swap file, because a swap file must be accessed through the filesystem layer of the kernel, and it has to be set up in a certain way — especially on btrfs, because you have to disable copy-on-write and compression — whereas with a swap partition — which is the way UNIX has always done it — the kernel can access the raw disk blocks directly.
Either way, most people here are using btrfs for the wrong reasons. Snapshot functionality is only one of the many benefits of btrfs — and it isn’t even unique to btrfs, because zfs and xfs also offer that functionality — and yet here at the forum, it’s pretty much the only reason why people use it.
I guess you’ve never heard of the word “backups” then?
Yes, those are good reasons for wanting btrfs, but I’m willing to bet that 99% of the people on this forum who use btrfs have never even thought about those things.
I can restore my /etc from my backups — and I’ve already had to do that once, after messing up the permissions because of a typo in a shell command.
btrfs snapshots are no substitute for backups on a separate storage medium. If your drive dies, then you lose your snapshots just the same.
“I guess you’ve never heard of the word “backups” then?”
A backup restore is a far cry from a rollback
" I can restore my /etc from my backups — and I’ve already had to do that once, after messing up the permissions because of a typo in a shell command.
btrfs snapshots are no substitute for backups on a separate storage medium. If your drive dies, then you lose your snapshots just the same."
100% correct! BUT, snapshot restores are atomic, while regular backups restore are SNAILtomic! lol
I agree;
if only from the inconvenience perspective of having both swapfile.sys and hiberfil.sys; and restore point data; stored on the system disk. I appreciate the reasons for the latter, but still much prefer to keep that separate, as my system drive on Windows is typically only 200G.
I place the Users directories on a separate partition, for much the same reasons that a separate /home is generally suggested in Linux.
That’s a misconception. rsync backups made by way of timeshift can be browsed — via a command-line shell or a file manager — just like any other directory on your system. As such, you can simply copy back individual directories and files while preserving the original permissions and ownership. For /etc, it takes only a few seconds.
Except that Windows doesn’t have an easy-to-modify file like /etc/fstab — the information is all stored in the Registry — and thus upon a fresh (re)installation of Windows, it won’t find your user directories anymore.
I know this from my two-year experience with NT 4.0, in which I had extensively hacked the Registry.
Not with a fresh install, no, at least, not without some effort. However, with an in-place upgrade there is never an issue; and that’s the method I would always use.
Latest incarnations of Windows 11 do make this more difficult; but not impossible; it is what it is (I don’t treat W11 as a serious concern).
W10 was released in… 2015, I think… after the additional 5 years of Beta (you know, post-release) I find it to be more than adequate for … Windows things … and surprisingly stable when compared to everything before it.
I do miss the comparative simplicity of NT4/2000; occasionally; but never for long.
Oh, I don’t miss it at all. I was only using it because I couldn’t get my hands on an affordable UNIX, and because all of my friends were using Windows 95/98. And luckily, I only had to tolerate it for two years, because then I discovered GNU/Linux, which was just what the doctor had ordered. 
It’s a known issue with Calmares 3.3. I switched it back to 3.2 earlier, but had forgotten to spin a new ISO.
Here’s a new one: manjaro-cinnamon-24.0.2-240710-linux69.iso (Yes, I know it should be 24.0.3).
EDIT: Now available on the official download page.
Sure! For small files like in /etc, it’s fast. However, no misconception that if you CRASH a big /usr like folder or if you also keep /home as a BTRFS snapshot, then get ready to wait a long time for your rsync restore. The simple test is this. How long does it take to do an initial EXT4 snapshot? a LOT! How long does it take the same on BTRFS? Zero! It’s an atomic operation.
A BIG Thank YOU! 
Installed and booted like a champ!
https://download.manjaro.org/cinnamon/24.0.2/manjaro-cinnamon-24.0.2-240710-linux69.iso
Thank you!
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.