Yes
I know, thatâs why itâs better to call these installers snapshots, milestones.
Just call them ISOs.
Or we could just call them ISO images? Itâs what they are, right?
Oops. You beat me to it.
I think that ISOs should not be numbered, but we can distinguish them by name. Cassini brought quite a lot of new things, so I think it can be safely called a milestone.
With the change to dracut as the default initramfs generator, EndeavourOS ceases to be as close to Arch as it used to be. Dracut may be a useful tool compared to mkinitcpio. However, until Arch makes dracut its default initramfs generator, the move away from mkinitcpio represents a shift in thinking at EndeavourOS.
Nothing prevents you from using dracut on Arch. Itâs in the Arch repos.
When installing Arch the Arch way, you can simply install dracut instead of mkinitcpio.
The Arch wiki page is pretty good in that regard:
https://wiki.archlinux.org/title/Dracut
So no, I wouldnât say this makes any departure from Arch.
Besides itâs being used on Fedora and most likely some others ⌠I know little about it but Iâve been running it for a while on KDE and so far no issue. Still using grub.
From the page you linked:
" Arch uses mkinitcpio by default."
This is like saying well itâs not really arch then? Itâs no different than using systemd over grub. Doesnât mean itâs not Linux.
It is just that what is explicitly stated is:
Initramfs
Creating a new initramfs is usually not required, because mkinitcpio was run on installation of the kernel package with pacstrap.
For LVM, system encryption or RAID, modify mkinitcpio.conf(5) and recreate the initramfs image:
Seemingly, when installing the kernel, mkinitcpio is chosen by default.
However as mentiond above, nothing prevents the users to switch to dracut. Or perhaps explicitly install it while âpacstrappingâ? In both cases, a pre-knowlege of the existent of the alternative is necessary at the outset.
What is this pacstrapping?
You should probably look up the pacstrap
command.
So?
The archiso tool is used to build Arch ISOs and is used by EndeavourOS and practically all others producing Arch-based systems. The archiso tool specifies mkinitcpio as the tool used to build the initramfs. Until Arch developers change the specified initramfs generator in archiso, mkinitcpio will remain the default choice.
The Arch installation wiki gives the example of running mkinitcpio -P to produce the initramfs. Actually, it states that mkinitcpio is run automatically (since that is the package installed by a default package list when building the iso) when the kernel is installed by pacstrap.
Since the initramfs is a crucial component used to boot the system, how it is generated can be viewed as a critical decision. Arch, so far, chooses the mkinitcpio tool by default. Until Arch changes to dracut as its default choice, mkinitcpio is part of what comprises an Arch system. Arch-based systems are free to choose whatever they wish. I guess my issue is with people re-defining Arch to include systems that swap critical components and still maintain something is âjust Arch with different branding.â
I donât have any issue. I donât want to get into this debate. What i care about is that it works. Thatâs all I care about. Otherwise I wonât use it.
But if you consider it from a practical standpoint, the amount of work required to convert between dracut and mkinitcpio is quite trivial. It took me less than three minutes to make the switch from mkinitcpio to dracut.
I guess the point here is that shipping dracut by default wouldnât be considered that big of a deviation from vanilla arch, at least from a practical standpoint. Not when one can remove dracut and switch back to mkinitcpio in under two minutes.
Given that both are in the Arch repos, they are both Arch.
This is a very valid point. From the userâs vantage point, how the initramfs is generated makes little difference. âVanilla Archâ is a loaded term though!