Because the hooks can be tweaked to any user’s preference.
I wonder why you think there is a one-size-fits-all? I am beginning to think that you lesser about the packing than you pretend … please check before rambling on subjects you know little of.
Let me rephrase - Arch provides some sane defaults
And calamares rewrites the defaults from Arch with choices during installation
But I very much against modifying installations backwards - there is absolutely no reason to do that.
Worst case scenario - some one sees the pacnew and due ignorance implements the details and system breaks - who’s now to blame - I know who will get it …
And Manjaro Linux has backported the brackets patch
Because if a user request support and has never touched the file, you have to know what the defaults are to provide support. That is exactly why there are limited number of supported kernels, DEs and no aur support.
Let me paraphrase: there are no arch defaults on a manjaro installation. They come with a pacnew.
And yet that is exactly what happens now. A pacnew with the arch defaults comes from time to time and rewrites the calamares defaults if the user deals with the pacnew at all.
Generally, only someone that has never provided support to masses of customers can say that mixing different configurations among the userbase is not a support hell. That is exactly why your ISP is not giving access to your home router and controlling it remotely and updating it for everybody at the same time in the night.
Thanks for the heads-up. Those are the helpful nuggets of information I’m looking for. I wouldn’t have any idea to look out for this. I just checked and amd-ucode is installed.
I’ve decided to not add ‘amdgpu’ to MODULES for now though but try my luck with ‘kms’ in the hooks.
EDIT - 02/12/23
Forgot to ask about the plymouth hook. mkinitcpio (Arch Wiki) doesn’t specifically mention this one. It’s been added by Calamares when it detects that Plymouth is installed.
Almost none of the listed HOOKS variables listed in this discussion (except for the ‘calamares’ standard one) list ‘plymouth’. Is it a) not needed anymore, b) covered by another hook like ‘kms’ or c) deliberately removed by all the more experienced users because it’s considered a useless gimmick?
I have been following this with interest, I thought my config was in order, and it probably is.
I read the links provided and about the btrfs hook it is stated;
Sets the required modules to enable Btrfs for using multiple devices with Btrfs. You need to have btrfs-progs installed to use this. This hook is not required for using Btrfs on a single device where the filesystems hook suffices.
What do they mean by that?
I have multiple devices, my home is on a separate partition and not a subvolume.
I do NOT have this hook, and it works.
Do they mean if I were to have multiple btrfs installations or something?
Probably because what is said right next to what you quoted:
Runs btrfs device scan to assemble a multi-device Btrfs root file system when udev hook or systemd hook is not present.
There is also this:
mkinitcpio -H btrfs
==> Help for hook 'btrfs':
This hook provides support for multi-device btrfs volumes. This hook
is only needed for initramfs images which do not use udev.
==> This hook has runtime scripts:
-> pre-mount hook
I DO have multiple devices with btrfs.
I have NEVER scanned anything with btrfs device scan.
So question again:
Do they mean that the btrfs hook is needed if there are multiple btrfs installations? (multiple btrfs root systems)
Or do they mean if at least one btrfs system is CREATED using multiple devices?
Or WHEN is it ever needed?
Who said you should do it? Read the page, we are talking about hooks.
My guess multiple devices means multiple disks. Anyway, if you want to know what they mean you are welcome to go on irc.libera.chat:#archlinux and ask there.
This means that a btrfs volume consists of more than ONE device.
Device must be seen in context of command btrfs device
btrfs device --help
usage: btrfs device <command> [<args>]
btrfs device add [options] <device> [<device>...] <path>
Add one or more devices to a mounted filesystem.
btrfs device delete <device>|<devid> [<device>|<devid>...] <path>
btrfs device remove <device>|<devid> [<device>|<devid>...] <path>
Remove a device from a filesystem
btrfs device replace <command> [...]
Replace a device (alias of "btrfs replace")
btrfs device scan [-d|--all-devices] <device> [<device>...]
btrfs device scan -u|--forget [<device>...]
Scan or forget (unregister) devices of btrfs filesystems
btrfs device ready <device>
Check and wait until a group of devices of a filesystem is ready for mount
btrfs device stats [options] <path>|<device>
Show device IO error statistics
btrfs device usage [options] <path> [<path>..]
Show detailed information about internal allocations in devices.
manage and query devices in the filesystem
P.S.:
A device in linux is a thing under /dev but btrfs only uses partitions and disks from there.
Or multiple partitions, all combined into a single btrfs filesystem. It’s the same thing as what zfs calls “a pool”. You can combine multiple physicalbtrfs volumes into a single logical volume.
Ah, so a btrfs filesystem that SPANS over multiple devices is what they mean, ie If I f ex create a filesystem and add sda1 AND sdb1 to the same filesystem.
I got confused because my home was previously on a completely different device than the btrfs root, and it still worked.
I can also report that having /home on the same device but different partition also works without the btrfs hook.
Yeah, maybe it is enough to span over partitions, not devices for this to be needed. So if I change my statement above it would also include if I use sda1 AND sda2 into the same btrfs filesystem.