Skip to main content ↑ ↓
Topic: GUI installer (Calamres): rEFInd (Read 2135 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: GUI installer (Calamres): rEFInd

Reply #15 –
What a tiresome thread. How hard is to replace grub with whatever after installation anyway?

Re: GUI installer (Calamres): rEFInd

Reply #16 –
rEFind doesn't work on computers with BIOS boot only, and if you have a mix of older and newer computers it can be easier to run them all as BIOS boot so you can swap HDD's over in case of hw failure etc. Also grub does support zfs and you can use it, just not all features YET but it quite likely will in future, you could just as easily ask for improved zfs support in grub. And while you are talking about zfs then why not ask for that to be finished, from what I read it lacks many things itself like proper fsck and recovery abilities.  ;D

Re: GUI installer (Calamres): rEFInd

Reply #17 –
The more I read threads like this, the more I think maybe the Arch way to install a system is the best. Make your decision, RTFM, then just do it.

Re: GUI installer (Calamres): rEFInd

Reply #18 –
Apologies if this is SBO and you already know, perhaps for grub being slow, check /etc/default/grub GRUB_TIMEOUT=4, this is usually the default value but can be set to '0' as for me the grub part of boot is negligible in time, I personally put 1 there so I see the menu briefly as a reminder when to press the key if needed. And possibly grub deliberately avoids supporting the full zfs feature set to AVOID bloat?

Re: GUI installer (Calamres): rEFInd

Reply #19 –
@#######
1. OpenZFS is 10 years old, enough time to modify Grub?
2. If you ask just for ZFS, just get back one (unusable) Arch-linux-link
3. 4k-disks are also 10 years old, also not yet implemented well https://forum.artixlinux.org/index.php/topic,3214
4. Always get I links, but nobody read my links with the proof of not working apps.
5. Is UEFI 10 years old or older?

Why have I apps (partition and formatting tools) on my PC that don't understand 4k?
Who know about 4k, the kernel only?
Grub, rEFInd, ZBM, no one is complete, why?
Can you replace one of them without be a coder?
Does someone ask the users to detect how many BIOS are still in use?
Does Grub start OS because detecting initrams on PARTUUID, /dev/disk/by/id/ or just (hd0,1)?
Can we really take a disk from UEFI machine and start in BIOS-machine?

Put I a question and get only links, some are good some else not, who post the links also don't read the same.
Proof I that something is incomprehensible or wrong or is not working and document it with links, this will be ignored.
If nothing else help, make the question ridiculous like in 'Django Unchained': "What nonsense! Just white cake!?"

Again, Artix-grub is the best grub I ever had (if you don't touch anything).
The Installer take also Fritz-Box_"Host-name-of-machine", that's great.
The graphic is great and many other things too
but...
Bootloader and disk handling you/we have inherited, are the most important things in an OS, are not OK and must be improved.

We are (at least) 10 years late with 4k-disks, file systems (ZFS) and proper bootloader.

Nobody can tell me or anybody else that e.g. 'ext4' is an up-to-date FS if after setting disk to 4k I have to use the following command to ensure ext4 recognize 4k properly...
Code: [Select]
mkfs.ext4 -F -b 4096 -F /dev/nvme0n1p2
if I have to set two times the switch/option "-F" (that mean "Force", see mkfs.ext4 man-page), that means... ext4 could understand 4k but must not, ext4 listen 4k from kernel-module (or somewhere else and maybe) but don't know itself until you "force" it twice while formatting.

So, this specific ext4 "small problem" could be resolved with an e.g. "ext5" that cover this topic, and why we not yet have an ext5? Cause of 10 years old ZFS and thus ext5 not needed?

The same thing is the bootloader topic, the bootloader should understand ZFS (as well maybe also btrfs, xfs etc.) and snapshots-boot without any hick-hack (additional ext2 boot-partition, missing of FS-feature, special update-scripts that suddenly disappear).

- For using Grub with ZFS is also needed to insert zfs-efi-drivers (see here), in rEFInd for Artix in Omniverse repo (thousand thanks to Artist) are the drivers already implemented (see here) or see in artix-refind-package in a.m. repo, to be tested.
- Grub (apparently) need a special ext2/boot-partition for zfs, this cannot be removed after installation and hence replace Grub with refind is not possible at all or not "just white cake". On top of this, Grub not support all ZFS feature, boot snapshots (if alt all possible) only for coders.

The name of the cockroach (grub, refind, zbm (zfs-boot-menu), syslinux, etc.) is for me (and hope for everyone else here) not of interest, the features or solution is/are of course very important and those all are missing, even after 10 years.

So, we can wait for Windows 12, True OS (with debian/devuan on zfs) or any other linux-distro or OS appears and people forget that, ones, also Artix existed or... you/we make Artix looking in the future with perfect disk-handling, bootloader, future oriented file-system and so on.

You make the decision, it's up to you, you can make survey/poll, improve packages...

Re: GUI installer (Calamres): rEFInd

Reply #20 –
I personally use refind over grub, as I find it easier to use for EFI, my opinion. Also use it with ZFS as well. Generally no need to edit a config unless you need a set of options and/or for some reason it doesn't see the kernel that should be detected. Same time, if you need more advance control over the system, it is best to just use base iso, and I find that true no matter the distro used, though I prefer control as well.

Re: GUI installer (Calamres): rEFInd

Reply #21 –
Support is improving, see the grub commit history searching for zfs:
https://git.savannah.gnu.org/cgit/grub.git/log/?qt=grep&q=zfs
The grub zfs code is about 6000 lines of C, so not huge. You could learn C and study this to see if you can help out! But that would probably take a couple of years to get anywhere, right? Don't think just because you aren't a coder now you couldn't be, it only takes 3 years to get a university degree. So that's why this doesn't happen instantly, because that's what someone somewhere has to do to accomplish this.
I use btrfs, not so long ago support for that was quite sketchy, sometimes simple tools to search for files or see file size didn't work or even caused kernel hangs, I think I remember reporting a couple of bugs which were fixed, so even without doing anything hard I could make some slight contribution to the development just by patiently gathering the required info and logs so the fault could be identified and reproduced, and presenting it to the relevant maintainers who could resolve things, which they did actually.
And there's usually no probs swapping drives about, the fallback initramfs has all the modules in it, like the live iso's work in most machines.
 

Re: GUI installer (Calamres): rEFInd

Reply #22 –
Update:

From FreeBSD forum I learned:
  • OpenZFS (which is as well in Linux as in BSD) is not (yet) able to encrypt the whole disk, at least not in FreeBSD. The full disk encryption in BSD is done with Geli.
  • ZFS and (in case wished) encryption not span over all partitions-boundaries but only on zroot
  • The swap-partition exist in FreeBSD only as 'freebsd-swap' if no ZFS is selected.
  • If ZFS is selected, a 'zvol' inside 'zroot' named  "swap" is created and configured. This mean the swap-volume is under zroot-volume = a subvolume of 'zroot'.
  • BSD boot-code is inside the first 1024 (1MiB) of disk
    Code: [Select]
    gpart add -a 4k -s 800K -t efi ada0
     # prior to FreeBSD 12.x
     gpart bootcode -p /boot/boot1.efifat -i 1 ada0
     # for FreeBSD 12.x and up, create a FAT32 partition
     newfs_msdos -F 32 -c 1 /dev/ada0p1
     mount -t msdosfs -o longnames /dev/ada0p1 /mnt
     mkdir -p /mnt/EFI/BOOT
     cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
  • BSD have a special 'freebsd-zfs' partition. The correspondent part on Linux is not known, not by myself.
    Code: [Select]
    gpart add -a 1m -t freebsd-zfs -l disk0 ada0

Apparently OpenZFS don't work in Ubuntu 21.10, to be checked if in OS using Calamares it works.

I will check again the ubiquity script of 20.04 with the intention to find additional useful details for us.