I have just been through an attempted hard install of Artix/OpenRC.
It is a live system with the Calamares installer.
I used the ‘Custom partitioning’ option and defined a root partition and an EFI partition.
When I hit ‘Install’ it went ahead and copied all the files to the root partition, then it said ‘Installing Bootloader’
I did not want that. I wanted to multiboot it from grub on another disk controlled by MX.
Well, cant stop it now, so I let it finish, then rebooted into MX, did update-grub, it found the new install ( called it Arch ??), but it would not boot the new install…message about the root filesystem UUID did not exist ???
I mucked around for ages with the grub menu editor … nothing works… it cant find the root filesystem.
In desperation I decided to write grub again to the EFI partition on the disk containing the Artix install… I did that from MX… BAD MOVE… now I cant boot any distro on any disk… not even a grub menu just grub recovery>
Next day I got out the SuperGrub2 CD, and used it to boot into MX, reinstalled grub on the MX disk, did update-grub, rebooted, and I have my grub menu back , and everything boots… except the new Artix.
So I erased Artix , redid the install, only this time killed it when it said
‘Installing Bootloader’. I got all the root filesystem, /etc/fstab isOK, and there is no grub.cfg file. It should boot, but it doesnt. It is a complete failure.
So 2 questions
how to stop Calamares from installing a bootloader… killing it on the fly is a bit awkward.
has anyone tried an Artix install recently… it simply does not work for me?
OK, that may get me a login.
Then I have to work out what to do?
Do you know where the EFI partition is mounted in Arch?
I mounted it to /boot/efi… maybe that is wrong? It is in /etc/fstab… I could easily change it without having to reinstall.
Thanks Joel,
It does help. It seems, that Artix is different from Arch in this respect.
Arch requires the EFI partition mounted on /boot or /efi, because the systemd.boot service requires those mounts.
Artix does not have those restrictions, because it does not use systemd, so you can mount the ESP partition anywhere , so it makes sense to stick with the Debian convention and mount it to /boot/efi
So it looks like that is not my problem, but I will test it tomorrow.
Mounting the ESP partition to /boot seems crazy to me… it mixes the initrd and vmlinuz files with the grub files all on a fat32 partition which would need to be much bigger than the usual 512Mb. Also mounting to a mount point that already contains files will hide the original files… so you would not see or be able to access the linux image files?
That is what I did in Calamares, so I guess that is not my problem
Just for interest… I found a Linux system where everything was installed inside the fat32 ESP partition. It was Clonezilla. Apparently it uses syslinux instead of grub to boot, and syslinux requires it that way.
I would almost bet that Artix Linux is just like the Gentoo I installed on a gpt disc with legacy boot. mount point for boot is “/boot” but grub would not install, until I added the “4mb bios_grub” partition.
That is huge… I normally have 1Mb
but
I am using uefi boot, so it should not need a bios-grub partition.?
It is not asking for one in the installer?
I will test that out .
@nevj Have you tried EndeavourOS? I am using it right now and it is an Arch based distro and it uses Calamares. You can try it without killing it at ‘installing bootloader’ and see what happens. As I have read, it faces no problem on multibooting. If you wish to do so, we will have a definite expert opinion which will help us all.
I did the experiment, but first … that disk previously had Antix installed, and it booted with no problem… so I decided to wipe Artix and reinstall Antix… now Antix does not boot either… same message
Error: no such device: 6865... ( the UUID number)
Error: disk 'hd3,gpt5' not found
Error: you need to load the kernel first
So now it looks like some sort of disk problem, maybe the way I partitioned it?
So I followed your advice
Here is the disk as setup, it has a gpt partiton table
so there is now a 4Mb bios-grub partition, and a bit of space at the top.
I rebooted Antix and same error message.
Maybe there is a problem because the Antixroot partition is after that very long data partition called Common? I did not have Common before when Antix booted on that disk.
Any suggestions welcome… it is not an Artix issue, it is not due to where I mount the ESP partiton, and because I know Antix formerly worked it is not an OS issue… it must be a partitioning issue… and/or… that disk is on a Marvel SATA interface. My other disks are on a motherboard SATA interface. I could try moving the sata cable… but it worked previously???
I have not tried it. That can wait. It is not an OS problem, I think.
Yes that is the problem.
The solution was to move the 2Tb data partition to the very end of the disk, then move the linux root partition up to the top of the unused space.
I moved the 2Tb partition by backing it up, deleting it, making a new partition at the disk end, and copying the backup back onto it. … that changed its UUID, so I had several /etc/fstab files to edit… all my distros mount that common data area.
Now, I can boot Antix… I did not even have to reinstall it… and I expect if I install Artix it will boot too.
So why the problem.? Grub cant count its way past a 2Tb partition to find a root partition that is beyond it. It may be that it gets integer overflow counting cylinders or something like that.?
Its time grub caught up with GPT disks.
I found this
" r many old BIOSes (in legacy or UEFI mode) are known to not be able to access disks beyond 2TB.
That’s because an LBA (or a sector / block number) would exceed 2^32.
In many cases the block number just wraps around and the firmware reads some wrong data. "
Maybe it is a BIOS issue rather than a grub issue?
I am sure it is!!!
“No-one can tell me how to stop the stupid installer from writing grub to the ESP”.
Has to be a way to opt-out of Calamares and do a command line install!!!
For UEFI it is not a matter of installing a bootloader but setting the EFI partition, if you don’t set it, you will get a warning that no bootloader will be installed and your new install might not boot, but it will not fail the install.
Not sure if that is enough of a feature of not installing a bootloader, or that it needs to be documented more.
The issue says it was fixed- in April 2022, but if you are not seeing an option to skip bootloader- it might be relevant. Seems exactly what you are dealing with.
I had better have a closer look at the partition step screen… it may be there.
That discussion reads to me like the user understands the problem better than the responder.
In general, Calamares is quite pleasant to use, and it tells me what partitions it will write to before I press the final button. It needs to also tell me what it is going to do with the bootloader.
I think I like the Refracta installer (Devuan) better.
Installing is really a very simple business. All it does is set a few config settings, then copy the whole system to a partition(s).
Sorry, I’ve not used installers for a while except for vms (Debian mostly) and when installing a VM I just let it do it’s job because it only has that partition to mess.
