[arch-general] dracut roll-out plan?
Archdevs,
I see dracut is creeping into the system. Which I see as fine, SuSE has used dracut for a couple of years and it has proven to be quite robust. But I do have a question on roll-out and what will be required on the user's part. I have begun seeing, e.g.:
New optional dependencies for brltty dracut: for dracut based initramfs support
I currently have 3 Arch servers, with one remote administered, so if this will require some type of manual on-site intervention, it would be good to know before hand.
On 1/23/21 5:58 PM, David C. Rankin via arch-general wrote:
Archdevs,
I see dracut is creeping into the system. Which I see as fine, SuSE has used dracut for a couple of years and it has proven to be quite robust. But I do have a question on roll-out and what will be required on the user's part. I have begun seeing, e.g.:
New optional dependencies for brltty dracut: for dracut based initramfs support
I currently have 3 Arch servers, with one remote administered, so if this will require some type of manual on-site intervention, it would be good to know before hand.
There is no plan. Dracut is an optional alternative, because Arch is all about choice. People who like dracut are welcome to use it.
The optional dependency is referring to the fact that brltty provides upstream files for /usr/lib/dracut/modules.d and therefore dracut optionally depends on brltty in order for dracut to have brltty support.
I don't understand why the optional dependency was added to brltty instead of dracut, though.
dracut doesn't enhance brltty. brltty enhances dracut.
You could try reaching out to the brltty maintainer directly and asking for insight, I guess.
On 23/01/21, Eli Schwartz via arch-general wrote:
There is no plan. Dracut is an optional alternative, because Arch is all about choice. People who like dracut are welcome to use it.
According to Wiki you can test it and switch to it if you think it's working - then remove mkinitcpio. So if one want to make sure dracut is working how does {s}he test it?
You cannot compare the initfsram files created as dracut contains the microcode image also.
Furthermore neither the wiki [1] not the man page [2] is a mention on the HOOKS [3] that mkinitcpio uses. Is there something similar for dracut or it's not required For example: will it automatically execute `btrfs device scan` as the `btrfs` HOOK would do in mkinitcpio?
[1]: https://wiki.archlinux.org/index.php/Dracut [2]: https://man.archlinux.org/man/dracut.conf.5 [3]: https://wiki.archlinux.org/index.php/mkinitcpio#HOOKS
On 1/24/21 9:20 AM, Leonidas Spyropoulos via arch-general wrote:
On 23/01/21, Eli Schwartz via arch-general wrote:
There is no plan. Dracut is an optional alternative, because Arch is all about choice. People who like dracut are welcome to use it.
According to Wiki you can test it and switch to it if you think it's working - then remove mkinitcpio. So if one want to make sure dracut is working how does {s}he test it?
I presume by trying to boot using it.
You cannot compare the initfsram files created as dracut contains the microcode image also.
Furthermore neither the wiki [1] not the man page [2] is a mention on the HOOKS [3] that mkinitcpio uses. Is there something similar for dracut or it's not required For example: will it automatically execute `btrfs device scan` as the `btrfs` HOOK would do in mkinitcpio?
I dunno, try it and see? Though my understanding is, dracut is less configurable and far more automatic probe-y. Chances are if it detects a btrfs filesystem of any sort, it will assume you need to probe for multi-device btrfs volumes at boot, and do so without asking or being configured.
On 1/24/21 9:51 AM, Eli Schwartz via arch-general wrote:
I dunno, try it and see? Though my understanding is, dracut is less configurable and far more automatic probe-y. Chances are if it detects a btrfs filesystem of any sort, it will assume you need to probe for multi-device btrfs volumes at boot, and do so without asking or being configured.
As an FYI i've been using dracut for just over a year now (when Giancarlo brought it up on mailing list) and it works flawlessly for me.
I don't use btrfs so cannot comment. As Eli said it is quite 'automatic'. However, for my systems with md raid - i found I needed to add one option - the options I use are:
--zstd --early-microcode --mdadmconf
Gene
On 1/24/21 10:15 AM, Genes Lists via arch-general wrote:
'automatic'. However, for my systems with md raid - i found I needed to add one option - the options I use are:
--zstd --early-microcode --mdadmconf
Forgot to mention that best I can tell neither early-microcode nor mdadmconf are needed as they default to 'yes'. And things may have changed over the year+ or my setup may be an issue, but at the time I set this up, I needed mdadmconf. May or may not still be needed.
Am 24.01.21 um 15:51 schrieb Eli Schwartz via arch-general:
Furthermore neither the wiki [1] not the man page [2] is a mention on the HOOKS [3] that mkinitcpio uses. Is there something similar for dracut or it's not required For example: will it automatically execute `btrfs device scan` as the `btrfs` HOOK would do in mkinitcpio?
I dunno, try it and see? Though my understanding is, dracut is less configurable and far more automatic probe-y. Chances are if it detects a btrfs filesystem of any sort, it will assume you need to probe for multi-device btrfs volumes at boot, and do so without asking or being configured.
I have never used dracut, but it has modules similar to mkinitcpio hooks. I guess the modules contain more automagic so you don't have to manually enable/disable them. If you want, you can limit the modules to include, though. If functionality is missing you will need to write a dracut module instead of a mkinitcpio hook.
https://man.archlinux.org/man/extra/dracut/dracut.conf.5.en
-- Andy
Just out of curiosity: Is remote unlocking of an encrypted (dm-crypt) disk via ssh possible out of the box with dracut? At the moment I use tinyssh with the mkinitcpio-netconf / mkinitcpio-tinyssh packages, as explained in https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Remote_unlocking_(...)
but didn't find something similar in the wiki.
Mathias
Am 24.01.21 um 16:42 schrieb ProgAndy via arch-general:
Am 24.01.21 um 15:51 schrieb Eli Schwartz via arch-general:
Furthermore neither the wiki [1] not the man page [2] is a mention on the HOOKS [3] that mkinitcpio uses. Is there something similar for dracut or it's not required For example: will it automatically execute `btrfs device scan` as the `btrfs` HOOK would do in mkinitcpio?
I dunno, try it and see? Though my understanding is, dracut is less configurable and far more automatic probe-y. Chances are if it detects a btrfs filesystem of any sort, it will assume you need to probe for multi-device btrfs volumes at boot, and do so without asking or being configured.
I have never used dracut, but it has modules similar to mkinitcpio hooks. I guess the modules contain more automagic so you don't have to manually enable/disable them. If you want, you can limit the modules to include, though. If functionality is missing you will need to write a dracut module instead of a mkinitcpio hook.
https://man.archlinux.org/man/extra/dracut/dracut.conf.5.en
-- Andy
Em janeiro 24, 2021 13:25 Mathias Anselmann via arch-general escreveu:
Just out of curiosity: Is remote unlocking of an encrypted (dm-crypt) disk via ssh possible out of the box with dracut? At the moment I use tinyssh with the mkinitcpio-netconf / mkinitcpio-tinyssh packages, as explained in https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Remote_unlocking_(...)
but didn't find something similar in the wiki.
Last time I've checked, dracut had something similar for it, but only using dropbear, not tinyssh. Dracut has way superior networking capabilities than mkinitcpio has, it supports a lot of stuff.
However, a quick google search yield [0].
However, a quick google search yield [0].
Nice! It's even in the AUR! I guess when I have some spare time I will give it a try! Thanks for this hint, I didn't know about it.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 24 January 2021 г., 17:20, Leonidas Spyropoulos via arch-general arch-general@lists.archlinux.org wrote:
According to Wiki you can test it and switch to it if you think it's working - then remove mkinitcpio. So if one want to make sure dracut is working how does {s}he test it?
I have switched to dracut more than a year ago (approximately when announcement was made in mailing list) and I can tell that dracut works fine. I consider dracut modules are somewhat more flexible than mkinitcpio, every specific configutation which I did in mkinitcpio was doable with dracut. If someone asks my opinion, I would recommend dracut.
Furthermore neither the wiki [1] not the man page [2] is a mention on the HOOKS [3] that mkinitcpio uses. Is there something similar for dracut or it's not required For example: will it automatically execute `btrfs device scan` as the `btrfs` HOOK would do in mkinitcpio?
Btrfs is supported in dracut (I use simple layout, not RAID), no specific configuration is needed.
On 26/01/21, Maksim Fomin via arch-general wrote:
I have switched to dracut more than a year ago (approximately when announcement was made in mailing list) and I can tell that dracut works fine. I consider dracut modules are somewhat more flexible than mkinitcpio, every specific configutation which I did in mkinitcpio was doable with dracut. If someone asks my opinion, I would recommend dracut.
After looking up the original anouncement in mailing list and wiki / this thread I setup dracut in parallel with mkinitcpio (for now) generating images with '-dracut' suffix though a pacman hook. It seems to be working ok with minimal configuration as others suggested.
Anyone found a way to re-generate the images using dracut for all installed kernels, similar to
mkinitcpio -P
I assume no since the mkinitcpio is getting this information from presets located in /etc/mkinitcpio.d but maybe something automagically discovered since dracut is all about discovery.
On Wed, Jan 27, 2021 at 12:55:01PM +0000, Leonidas Spyropoulos via arch-general wrote:
On 26/01/21, Maksim Fomin via arch-general wrote:
Anyone found a way to re-generate the images using dracut for all installed kernels, similar to
mkinitcpio -P
Take a look at [1].
[1]https://aur.archlinux.org/packages/rebuild-initramfs-dracut/
mlm
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, January 27, 2021 12:55 PM, Leonidas Spyropoulos via arch-general arch-general@lists.archlinux.org wrote:
Anyone found a way to re-generate the images using dracut for all installed kernels, similar to
mkinitcpio -P
I assume no since the mkinitcpio is getting this information from presets located in /etc/mkinitcpio.d but maybe something automagically discovered since dracut is all about discovery.
I use custom pacman hook which generates initramfs (calls dracut) for each kernel found in /usr/lib/modules.
Em janeiro 23, 2021 19:58 David C. Rankin via arch-general escreveu:
Archdevs,
I see dracut is creeping into the system. Which I see as fine, SuSE has used dracut for a couple of years and it has proven to be quite robust. But I do have a question on roll-out and what will be required on the user's part. I have begun seeing, e.g.:
Dracut is not "creeping" into anything. At the time mkinitcpio replacement was considered, mkinitcpio didn't had a maintainer anymore and I've packaged it and brought it up on the mail list so people would use it.
However, I have been maintaining mkinitcpio for the past couple of years. For now, mkinitcpio will probably remain the default, and dracut is an option. I have yet need to find it a decent support for the hooks to install the kernel as well as time to mimic mkinitcpio's profile functionality with dracut. This is one of the reasons I didn't include any hooks with it yet.
New optional dependencies for brltty dracut: for dracut based initramfs support
I think this dependency is wrong, should probably be the other way around.
I currently have 3 Arch servers, with one remote administered, so if this will require some type of manual on-site intervention, it would be good to know before hand.
We try to have a news item for any manual intervention needed, so you don't need to worry.
Regards, Giancarlo Razzolini
25.01.2021 5:44, Giancarlo Razzolini via arch-general writes:
New optional dependencies for brltty
dracut: for dracut based initramfs support
I think this dependency is wrong, should probably be the other way around.
hello. since I provided this patches to dvzrv, I'm sorry. your version really looks better. unfortunately I haven't tested brltty with Dracut yet. so I don't know if this will actually work.
Regards, Giancarlo Razzolini
I see dracut is creeping into the system. Which I see as fine, SuSE has used dracut for a couple of years and it has proven to be quite robust. But I do have a question on roll-out and what will be required on the user's part. I have begun seeing, e.g.:
At first I thought that dracut, being common to Suse and Fedora, would be nice to use in Arch too, so that there's more standardisation between distros. Alas, after using it for a while, dracut seems like the worse project than mkinitcpio. Both are heavily based on bash, but dracut is a huge single script and hard to follow. dracut also had obvious errors (for which I've sent a PR) that really cooled me off the idea to replace mkinitcpio with it.
I'd hope that mkinitcpio stays the supported initramfs system in Arch in the near future. Are there any pressing issues in mkinitcpio currently?
Em janeiro 25, 2021 8:34 Damjan Georgievski via arch-general escreveu:
I see dracut is creeping into the system. Which I see as fine, SuSE has used dracut for a couple of years and it has proven to be quite robust. But I do have a question on roll-out and what will be required on the user's part. I have begun seeing, e.g.:
At first I thought that dracut, being common to Suse and Fedora, would be nice to use in Arch too, so that there's more standardisation between distros. Alas, after using it for a while, dracut seems like the worse project than mkinitcpio. Both are heavily based on bash, but dracut is a huge single script and hard to follow. dracut also had obvious errors (for which I've sent a PR) that really cooled me off the idea to replace mkinitcpio with it.
dracut is huge because it supports way more stuff than mkinitcpio does. I have been using it on a few of my machines for a long time now, without issues. I use mkinitcpio on my main machine.
I'd hope that mkinitcpio stays the supported initramfs system in Arch in the near future. Are there any pressing issues in mkinitcpio currently?
I don't see things changing any time soon.
Regards, Giancarlo Razzolini
participants (11)
-
Alexander Epaneshnikov
-
Damjan Georgievski
-
David C. Rankin
-
Eli Schwartz
-
Genes Lists
-
Giancarlo Razzolini
-
Leonidas Spyropoulos
-
Maksim Fomin
-
Mathias Anselmann
-
Merell L. Matlock, Jr.
-
ProgAndy