Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em agosto 22, 2019 17:15 Damjan Georgievski via arch-general escreveu: Just in case, I'll mention kernel-install [1] once again, it's a nice central hub where initramfs creators, bootloaders (and optionally signing of uefi images) can hook into, and then any kernel install can call all the users hooks with a single command. [1] https://www.freedesktop.org/software/systemd/man/kernel-install.html I've searched the thread and didn't find a previous mention from you about kernel-install. It seems interesting, I'll take a look at it. Regards, Giancarlo Razzolini pgpKIS9BsxgQH.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 8/22/19 3:36 PM, Giancarlo Razzolini via arch-general wrote: > Em agosto 22, 2019 16:29 Damjan Georgievski via arch-general escreveu: ... > > On the other hand, I have been using dracut for months now without any > issues. > > Regards, > Giancarlo Razzolini I too have been using it for months by packaging hooks to use dracut instead of mkinitrd with my custom kernel builds. The only issue I had early on was with raid, as explained in my post of june 15th - the solution was to ensure that the initrd is built with --mdadmconf. Since then it's been rock solid on several computers includng 2 running raid 6. Anyway - works like a champ.Thanks for taking this on Giancarlo.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On Thu, 22 Aug 2019 at 21:36, Giancarlo Razzolini wrote: > Em agosto 22, 2019 16:29 Damjan Georgievski via arch-general escreveu: > > Are there any news/updates on this front? > > > > I have dracut installed in one test VM, but I have to run it manually > after > > each kernel update. The wiki page [1] is still empty, so > > how do I configure proper hooks to build the initramfs (and possibly also > > disable the mkinitcpio ones)? > > > > Yes. I have been working on pacman hooks for this. There are a few things > I need > to iron out before releasing it though. There's a need to change all > kernels as > well, because the hooks are deployed with them currently, this has to > change. > Just in case, I'll mention kernel-install [1] once again, it's a nice central hub where initramfs creators, bootloaders (and optionally signing of uefi images) can hook into, and then any kernel install can call all the users hooks with a single command. [1] https://www.freedesktop.org/software/systemd/man/kernel-install.html -- damjan
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
I have been looking into dracut for some time now, I copied some stuff from > them on a few of my own > scripts and they also have an actual test suite, that we currently can't > use on Arch, but I plan to > change that. > > Are there any news/updates on this front? I have dracut installed in one test VM, but I have to run it manually after each kernel update. The wiki page [1] is still empty, so how do I configure proper hooks to build the initramfs (and possibly also disable the mkinitcpio ones)? [1] https://wiki.archlinux.org/index.php/Dracut -- damjan
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 6/15/19 5:12 PM, Genes Lists via arch-general wrote: ... > > I need to do more work ... perhaps test with the --madadmconf flag when > building the initrd is next step. > I confirm that building the initrd with --mdadmconf fixes the problem assembling the raid disks using dracut - this happens fine now. In my case the /etc/mdadm.conf has RRAY /dev/md0 metadata=1.2 name=xxx ... where xxx is the hostname which is also in the RAID superblock. I would therefore recommend that the pacman hook file which is used to build the initrd use the --mdadmconf option. I will note that the file is not included even with -H or --include /etc/mdadm.conf. best gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
I now understand why this works with mkinitrd - it's because this approach does not assemble the array until -after- the pivot root - and the hostname is now the real hostname and this matches what's in the raid superblock. dracut attempts to assemble the array(s) before - in this case the hostname is the fake hostname. In neither case is /etc/mdadm.conf included - tho nkinitrd approach its not needed. I need to do more work ... perhaps test with the --madadmconf flag when building the initrd is next step. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 2019-06-11 18:02, Damjan Georgievski via arch-general wrote: > Is there any support for post hooks in Dracut? > > ie. I want to sign the uefi image with sbsign, after it's built with > `dracut --uefi …` > That would be cool, but dracut doesn't have this capability built in, see the last few lines of /usr/bin/dracut (https://github.com/dracutdevs/dracut/blob/8365177644bee107dcb66a71c8a7509900c9ece4/dracut.sh#L1938-L1982) Might be worth submitting an upstream feature or pull request? signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
> > I have been looking into dracut for some time now, I copied some stuff > from them on a few of my own > scripts and they also have an actual test suite, that we currently can't > use on Arch, but I plan to > change that. > Is there any support for post hooks in Dracut? ie. I want to sign the uefi image with sbsign, after it's built with `dracut --uefi …` -- damjan
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
> Giancarlo Razzolini Found this (very) old thread [1] - and tried the suggesion - removed name= from mdadm.conf, rebuilt the initrd and rebooted but had same problem. Booted from mkinitrd and still works. May be i need to learn more about raid Will need to get back to this. [1] https://ubuntuforums.org/showthread.php?t=1764861
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em junho 4, 2019 18:08 Genes Lists via arch-general escreveu: On 6/4/19 4:53 PM, Genes Lists via arch-general wrote: Forgot to post the boot the boot log which shows the problem occurs after switching the pivot root: ... saplinux kernel: md/raid:md127: raid level 6 active with 6 out of 6 devices, algorithm 2 saplinux kernel: md127: detected capacity change from 0 to 12001828929536 saplinux systemd[1]: Started dracut initqueue hook. ... saplinux systemd[1]: Switching root. ... kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: data=ordered systemd[1]: dev-md0.device: Job dev-md0.device/start timed out. systemd[1]: Timed out waiting for device /dev/md0. systemd[1]: Dependency failed for File System Check on /dev/md0. systemd[1]: Dependency failed for /mnt/md0. systemd[1]: Dependency failed for /srv/nfs4/install. systemd[1]: Dependency failed for Local File Systems. systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'. systemd[1]: local-fs.target: Triggering OnFailure= dependencies. ... Please, report all issues on bugs.archlinux.org with as much information as possible. As far as I know dracut supports raid. Perhaps this might even be an upstream issue. Regards, Giancarlo Razzolini pgpvdLYHgrEG2.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
> Speculation - this may be related to the kernel config which has CONFIG_DEFAULT_HOSTNAME="archlinux" for arch kernels and i use a different name (saplinux) In either case, in the boot logs the hostame shown before the pivot root is that default as compiled into thekernel - but after the switch root the actual hostname for the server is used. Since raid uses the real hostname (cat /proc/mdstat for example shows the real hostname on the raid server) - that since the hostnames doesn't match. Before the switchroot the raid is assembled but at md127 instead of md0 - after the pivot root all hell breaks loose as there is no md0 only md127. Clearly dracut must be used for raid - so whats the right way to do this? thanks.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 6/4/19 4:53 PM, Genes Lists via arch-general wrote: Forgot to post the boot the boot log which shows the problem occurs after switching the pivot root: ... saplinux kernel: md/raid:md127: raid level 6 active with 6 out of 6 devices, algorithm 2 saplinux kernel: md127: detected capacity change from 0 to 12001828929536 saplinux systemd[1]: Started dracut initqueue hook. ... saplinux systemd[1]: Switching root. ... kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: data=ordered systemd[1]: dev-md0.device: Job dev-md0.device/start timed out. systemd[1]: Timed out waiting for device /dev/md0. systemd[1]: Dependency failed for File System Check on /dev/md0. systemd[1]: Dependency failed for /mnt/md0. systemd[1]: Dependency failed for /srv/nfs4/install. systemd[1]: Dependency failed for Local File Systems. systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'. systemd[1]: local-fs.target: Triggering OnFailure= dependencies. ...
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 6/4/19 12:07 PM, Genes Lists via arch-general wrote: > FYI - I have switched my custom kernel builds to use dracut by default Ug take it back - i have one problem - a big problem. On a computer using md RAID-6 the raid disks are not assembled at boot - and the boot fails. Works fine switching back to mkinitcpio. Is there anything special we need to do with dracut to make md raid work at boot? The raid array is for data only not root which is a separate disk. dracut docs suggest nothing is needed to assemble raid arrays at boot. Perhaps this is incorrect? Thanks.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
FYI - I have switched my custom kernel builds to use dracut by default now - tested on 8 machines with no issues. Very supportive of switching to dracut. thank you. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 29, 2019 18:49 Michael Lojkovic via arch-general escreveu: Should this work with a minimal initramfs, without udev? I don't know how to transfer the mkinitcpio config to dracut to test this properly. It would help if you upload your current config/preset somewhere. I'm not sure anything works properly without udev these days, except for very simple setups. Also, if you're talking about non x86_64 platforms, the dracut Arch package is compiled just for that platform. For others, I guess this question would be better asked upstream. Regards, Giancarlo Razzolini pgpOSHYuU5YLN.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Should this work with a minimal initramfs, without udev? I don't know how to transfer the mkinitcpio config to dracut to test this properly.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/27/19 2:07 PM, Genes Lists via arch-general wrote: Likely the same issue https://lkml.org/lkml/2019/5/28/812 Thanks, gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/27/19 2:07 PM, Genes Lists via arch-general wrote: > Hi > > I've come across a possible issue which related to usb keyboard/mouse > device. > > Quick follow up. I have this issue on 2 machines I've tested. (i) vendor_id : GenuineIntel cpu family : 6 model : 78 model name : Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz stepping: 3 (ii) vendor_id : GenuineIntel cpu family : 6 model : 158 model name : Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz stepping: 9 gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/27/19 6:10 AM, Joerg Schilling wrote: > Eli Schwartz via arch-general wrote: > >> I think Chet Ramey did a pretty good explanation in the linked mailing >> list about why this is a fundamental misunderstanding of what "POSIX" >> means, but just to be extra sure... you are aware that POSIX defines >> `command ^` as the only true, correct POSIX way to suppress shell >> extensions and functions and ensure lookup as a true utility (and "^" is > > This is not true: > > "command" prevents to use functions, but it does not prevent to use shell > extensions that are built in commands. Pretty sure that's exactly what I said, but whatever. (`cd` is a "utility" even though it's a bit unique in that it's literally impossible to implement as an external binary, that's about as definite as it's likely to get.) Anyway if any shell implemented the "^" program as an in-process shell builtin command, I can only assume that for such a standardized thing as it would have to be, it would presume to be compatible with Neven Sajko's `exec(3)`'able version and life will be great (and also POSIX-compatible). -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Hi I've come across a possible issue which related to usb keyboard/mouse device. I notice that booting using dracut initramfs with kernel 5.2-rc2 that as soon as it boots it shows on the console: stopping job udev Kernel Device Manager with red spinner. This times out and boot continues fine - once the system has booted I check the boot log and included interesting part of logs below. Keyboard and mouse are both working and the relevant hid modules are loaded fine - and xinput shows all looking normal. Interesingly, using mkinitcpio initrd with same 5.2 kernel- the system comes up with no keyboard or mouse (it uses logitech wireless kbd/mouse). The hid_logitech modules seem not to have been loaded at all. So something in the newer kernel is leading to this issue but dracut manages to pull through anyway while mkinitcpio does not. Obviously anyone experiencing this might be quite taken aback. Also, everythign works fine with 5.1.5 kernel with both dracut and mkinitcpio. the hid modules are all fine for that test case. udev is a bit of a mystery to me - but thought I'd best mention the problem. gene --- boot journal with 5.2 with dracut saplinux systemd[1]: systemd-udev-trigger.service: Succeeded. saplinux systemd[1]: Stopped udev Coldplug all Devices. saplinux systemd[1]: dracut-pre-trigger.service: Succeeded. saplinux systemd[1]: Stopped dracut pre-trigger hook. saplinux systemd[1]: Stopping udev Kernel Device Manager... ... saplinux systemd-udevd[386]: Giving up waiting for workers to finish. saplinux systemd-udevd[386]: Event loop failed: Connection timed out saplinux systemd[1]: systemd-udevd.service: Main process exited, code=exited, status=1/F> saplinux systemd[1]: systemd-udevd.service: Killing process 459 (systemd-udevd) with sig> saplinux systemd[1]: systemd-udevd.service: Killing process 480 (systemd-udevd) with sig> saplinux systemd[1]: systemd-udevd.service: Killing process 482 (systemd-udevd) with sig> saplinux kernel: input: Logitech USB Receiver as /devices/pci:00/:00:14.0/usb1/1> saplinux kernel: hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard > saplinux kernel: input: Logitech USB Receiver Mouse as /devices/pci:00/:00:14.0/> saplinux kernel: input: Logitech USB Receiver Consumer Control as /devices/pci:00/00> saplinux kernel: input: Logitech USB Receiver System Control as /devices/pci:00/> saplinux kernel: hid-generic 0003:046D:C52B.0002: input,hiddev0,hidraw1: USB HID v1.11 M> saplinux kernel: hid-generic 0003:046D:C52B.0003: hiddev1,hidraw2: USB HID v1.11 Device > saplinux kernel: usbcore: registered new interface driver usbhid saplinux kernel: usbhid: USB HID core driver saplinux systemd[1]: systemd-udevd.service: Failed with result 'exit-code'. saplinux systemd[1]: Stopped udev Kernel Device Manager. saplinux systemd[1]: systemd-tmpfiles-setup-dev.service: Succeeded.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 27, 2019 13:45 Damjan Georgievski escreveu: Thanks, I've also noticed another issue about the uefi stub and sent a PR: https://github.com/dracutdevs/dracut/pull/575 Thank you all for testing and also submitting patches to make it work better not just on Arch, but any other distro too. Regards, Giancarlo Razzolini pgphZyHYsKLta.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
> > dracut 049-3 on an Arch [testing] VM > > > > There are a few more instances where arch must be replaced with uname -m. > > I'll deploy a version of dracut with that patch later: > > https://github.com/dracutdevs/dracut/pull/573 > Thanks, I've also noticed another issue about the uefi stub and sent a PR: https://github.com/dracutdevs/dracut/pull/575 -- damjan
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 27, 2019 11:18 Damjan Georgievski via arch-general escreveu: dracut --uefi This seems to fail for me: $ sudo dracut --no-early-microcode --uefi /boot/EFI/Linux/arch-linux.efi dracut: Executing: /usr/bin/dracut --no-early-microcode --uefi /boot/EFI/Linux/arch-linux.efi /usr/bin/dracut: line 1063: arch: command not found /usr/bin/dracut: line 1069: arch: command not found dracut: Architecture '' not supported to create a UEFI executable any ideas why?? dracut 049-3 on an Arch [testing] VM There are a few more instances where arch must be replaced with uname -m. I'll deploy a version of dracut with that patch later: https://github.com/dracutdevs/dracut/pull/573 Regards, Giancarlo Razzolini pgpjvOnTU7SIr.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 2019-05-27 16:18, Damjan Georgievski via arch-general wrote:> This seems to fail for me: > $ sudo dracut --no-early-microcode --uefi /boot/EFI/Linux/arch-linux.efi > dracut: Executing: /usr/bin/dracut --no-early-microcode --uefi > /boot/EFI/Linux/arch-linux.efi > /usr/bin/dracut: line 1063: arch: command not found > /usr/bin/dracut: line 1069: arch: command not found > dracut: Architecture '' not supported to create a UEFI executable This is a bug in dracut, see https://github.com/dracutdevs/dracut/pull/573 for a fix. Regards, Jonas signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
> > > dracut --uefi > This seems to fail for me: $ sudo dracut --no-early-microcode --uefi /boot/EFI/Linux/arch-linux.efi dracut: Executing: /usr/bin/dracut --no-early-microcode --uefi /boot/EFI/Linux/arch-linux.efi /usr/bin/dracut: line 1063: arch: command not found /usr/bin/dracut: line 1069: arch: command not found dracut: Architecture '' not supported to create a UEFI executable any ideas why?? dracut 049-3 on an Arch [testing] VM -- damjan
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Eli Schwartz via arch-general wrote: > I think Chet Ramey did a pretty good explanation in the linked mailing > list about why this is a fundamental misunderstanding of what "POSIX" > means, but just to be extra sure... you are aware that POSIX defines > `command ^` as the only true, correct POSIX way to suppress shell > extensions and functions and ensure lookup as a true utility (and "^" is This is not true: "command" prevents to use functions, but it does not prevent to use shell extensions that are built in commands. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Neven Sajko via arch-general wrote: > Regarding using bash as sh: > > > Bash runs POSIX scripts just fine. > > Bash does not run some POSIX scripts fine. See > https://lists.gnu.org/archive/html/bug-bash/2017-08/msg00087.html , > for example. In that case an executable named ^ can not be called. The character '^' is amongst the characters that need quoting in the shell. This is because shells that support upper case only terminals implement it as an alias for the pipe symbol and because it is a special character in the pattern matcher. Note that older versions of the POSIX standard had a bug and did not mention that '^' needs quoting. The current version includes the needed hint. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 26, 2019 0:08 Eli Schwartz via arch-general escreveu: Anyway I suspect this thread is not the best place to begin a fundamental discussion about whether GNU bash is allowed to claim it implements POSIX. Also I doubt dracut does insane things like attempt to invoke a utility named "^", with or without doing the POSIX thing and disambiguating it with the use of the command utility. And, even if it did, dracut gives you the ability to use either dash, busybox or bash. Perhaps even more. But all this discussion about pure POSIX or not is not really related to this thread. My main concerns are: 1) Is dracut a good replacement for mkinitcpio? 2) Can it do everything mkinitcpio do? 3) And, more importantly, does it mount the root fs like it is the purpose of all initramfs? Based on the replies I've got so far, with some minor issues, dracut is working on Arch just fine. I'm working on libalpm hooks for both mkinitcpio and dracut so the image creation is done automatically. Also, both packages now provide a virtual 'initramfs' package, so we can switch to this when everything is ready. I plan also to provide with the dracut package a configuration similar to what we have today, creating a hostonly image and a fallback image. Once all this is ready, we can start deploying dracut on our ISO. Also, when the kernel packages switch to the 'initramfs' dependency, we'll be able to have pure dracut installations. Regards, Giancarlo Razzolini pgpzJfxITGyC_.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/25/19 1:54 AM, Neven Sajko via arch-general wrote: > Regarding using bash as sh: > >> Bash runs POSIX scripts just fine. > > Bash does not run some POSIX scripts fine. See > https://lists.gnu.org/archive/html/bug-bash/2017-08/msg00087.html , > for example. In that case an executable named ^ can not be called. I think Chet Ramey did a pretty good explanation in the linked mailing list about why this is a fundamental misunderstanding of what "POSIX" means, but just to be extra sure... you are aware that POSIX defines `command ^` as the only true, correct POSIX way to suppress shell extensions and functions and ensure lookup as a true utility (and "^" is not a builtin utility in bash, but if you needed to suppress those too, enable -n ^ 2>/dev/null)? Of which there are many -- by definition, creating a shell that has useful functionality above and beyond being a dumb clone of the 1980s Bourne shell requires, well, adding new things that conflict with your "unspecified functionality should do simple $PATH lookups". Anyway I suspect this thread is not the best place to begin a fundamental discussion about whether GNU bash is allowed to claim it implements POSIX. Also I doubt dracut does insane things like attempt to invoke a utility named "^", with or without doing the POSIX thing and disambiguating it with the use of the command utility. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On Sat, 25 May 2019 05:54:23 +, Neven Sajko via arch-general wrote: >Regarding using bash as sh: > >> Bash runs POSIX scripts just fine. > >Bash does not run some POSIX scripts fine. See >https://lists.gnu.org/archive/html/bug-bash/2017-08/msg00087.html , >for example. In that case an executable named ^ can not be called. My apologies, if I should misunderstand something. My understanding is, that you expect Bash to allow a non-POSIX files name in POSIX mode. See: POSIX "Fully portable filenames" https://en.wikipedia.org/wiki/Filename
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 05/22/2019 11:41 AM, Eli Schwartz via arch-general wrote: > I would rather avoid such bundles at all costs, it sounds like someone > saw a problem named bootctl and decided to create even more problems in > the name of a solution. I've always respected the Arch KISS approach. The further we stay into the ... what was the word? ... "byzantine", the further away from KISS Arch migrates. But, somehow, those charged with the stewardship of Arch seem to always make solid choices for the distro going forward. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Regarding using bash as sh: > Bash runs POSIX scripts just fine. Bash does not run some POSIX scripts fine. See https://lists.gnu.org/archive/html/bug-bash/2017-08/msg00087.html , for example. In that case an executable named ^ can not be called.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 12:24 PM, Genes Lists via arch-general wrote: > 1) Feedback: > Tested one computer and it worked fine. Working fine on a couple more I tested. Also for my custome kernel builds, I added a libalpm hook to create the dracut initrd - makes it easier for me to test. Thank you for doing this - based on the list volume, looks like there's significant interest. thanks again, gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 2019-05-22 18:41, Eli Schwartz via arch-general wrote: > True, but on the other hand bootctl sucks and you can implement a 2MB > efi partition that works everywhere and supports a single unified > kernel/microcode/initramfs setup stored on an ext4/btrfs/whatever /boot > subdirectory inside your rootfs, full disk encryption optional and > supported, no worries about your booted kernel image getting into a > mismatch with your /lib/modules directory because you have multiple > copies of your kernel flying around and most of them are just staged > data that is never used, and so on. systemd-boot was just one example where such a setup might be helpful, of course you don't have to use it: something like dracut --uefi $ESP/EFI/Arch/arch-linux.efi efibootmgr --create --disk ... --label "Arch Linux" --loader "EFI\Arch\arch-linux.efi" --verbose works equally well. > I would rather avoid such bundles at all costs, it sounds like someone > saw a problem named bootctl and decided to create even more problems in > the name of a solution. IMHO such bundles are more or less the only way to go if you want to have an encrypted system in combination with Secure Boot: you can bundle everything in a single application, sign it with your keys and put it on the EFI system partition. Currently I use sbupdate-git for this purpose, if we switch to dracut anyway, I could remove sbupdate and replace it by a simple hook that signs the EFI executable generated by dracut. The only alternative I am aware of for such a configuration is using GRUB for its encrypted /boot support, but that has some drawbacks as well (is LUKS2 supported by now?) and is much harder to customise: for example, I store the disk encryption key in a Trusted Platform Module (TPM). Retrieving it from the TPM is easy using a custom script run as a mkinitcpio hook/dracut module, writing a GRUB module is much less fun... Cheers, Jonas signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/22/19 12:22 PM, Jonas Witschel wrote: > On 2019-05-22 17:25, Giancarlo Razzolini via arch-general wrote: >>> Unfortunately this process currently only works for AMD, but not for >>> Intel, since Arch Linux doesn't package the necessary files standalone: >>> they are downloaded by intel-ucode and used to produce a CPIO image, but >>> not added to /usr/lib/firmware/intel-ucode/ separately. If dracut >>> becomes the default initramfs generator, this should be changed so that >>> microcode updates work out of the box with dracut. >>> >> >> This is not a huge issue, if the microcode is passed alongside the >> initramfs >> on the cmdline, like we have been doing. >> >> We might also change the intel-ucode package, but it is not a >> requirement and >> will not prevent the move to dracut. > > This is certainly not a blocker, no, but would be very nice to have: > dracut can bundle kernel, kernel command line, microcode updates and > initramfs in a single EFI executable using the "--uefi" parameter. This > means setting up booting becomes as simple as > > dracut --uefi > bootctl install > > No further configuration is needed at all because dracut and bootctl > implement the Boot Loader Specification [1] (slight caveat: there is > currently a small bug if the EFI system partition is mounted to /efi [2]). > > Regards, > Jonas > > [1] > https://systemd.io/BOOT_LOADER_SPECIFICATION#type-2-efi-unified-kernel-images > [2] https://github.com/dracutdevs/dracut/pull/574 True, but on the other hand bootctl sucks and you can implement a 2MB efi partition that works everywhere and supports a single unified kernel/microcode/initramfs setup stored on an ext4/btrfs/whatever /boot subdirectory inside your rootfs, full disk encryption optional and supported, no worries about your booted kernel image getting into a mismatch with your /lib/modules directory because you have multiple copies of your kernel flying around and most of them are just staged data that is never used, and so on. All those benefits just because you did the *simple* thing and didn't use byzantine fstab layouts which uefi+bootctl makes mandatory. :) (Yes, I am bitter that supporting systemd-boot as a target bootloader means we cannot trust /boot to be a sane filesystem.) I would rather avoid such bundles at all costs, it sounds like someone saw a problem named bootctl and decided to create even more problems in the name of a solution. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 2019-05-22 17:25, Giancarlo Razzolini via arch-general wrote: >> Unfortunately this process currently only works for AMD, but not for >> Intel, since Arch Linux doesn't package the necessary files standalone: >> they are downloaded by intel-ucode and used to produce a CPIO image, but >> not added to /usr/lib/firmware/intel-ucode/ separately. If dracut >> becomes the default initramfs generator, this should be changed so that >> microcode updates work out of the box with dracut. >> > > This is not a huge issue, if the microcode is passed alongside the > initramfs > on the cmdline, like we have been doing. > > We might also change the intel-ucode package, but it is not a > requirement and > will not prevent the move to dracut. This is certainly not a blocker, no, but would be very nice to have: dracut can bundle kernel, kernel command line, microcode updates and initramfs in a single EFI executable using the "--uefi" parameter. This means setting up booting becomes as simple as dracut --uefi bootctl install No further configuration is needed at all because dracut and bootctl implement the Boot Loader Specification [1] (slight caveat: there is currently a small bug if the EFI system partition is mounted to /efi [2]). Regards, Jonas [1] https://systemd.io/BOOT_LOADER_SPECIFICATION#type-2-efi-unified-kernel-images [2] https://github.com/dracutdevs/dracut/pull/574 signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 22, 2019 9:25 Jonas Witschel escreveu: On 2019-05-22 14:00, Giovanni Harting via arch-general wrote: Unfortunately this process currently only works for AMD, but not for Intel, since Arch Linux doesn't package the necessary files standalone: they are downloaded by intel-ucode and used to produce a CPIO image, but not added to /usr/lib/firmware/intel-ucode/ separately. If dracut becomes the default initramfs generator, this should be changed so that microcode updates work out of the box with dracut. This is not a huge issue, if the microcode is passed alongside the initramfs on the cmdline, like we have been doing. We might also change the intel-ucode package, but it is not a requirement and will not prevent the move to dracut. Regards, Giancarlo Razzolini pgp4vqf0HXENE.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 2019-05-22 14:00, Giovanni Harting via arch-general wrote:
> AMD's microcode is in linux-firmware: /usr/lib/firmware/amd-ucode/
Dracut indeed looks in /usr/lib/firmware/{amd,intel}-ucode/ for
microcode updates to include in the initramfs. When using a host-only
initramfs, only the relevant files are included, otherwise the image is
supposed to contain the updates for both AMD and Intel.
Unfortunately this process currently only works for AMD, but not for
Intel, since Arch Linux doesn't package the necessary files standalone:
they are downloaded by intel-ucode and used to produce a CPIO image, but
not added to /usr/lib/firmware/intel-ucode/ separately. If dracut
becomes the default initramfs generator, this should be changed so that
microcode updates work out of the box with dracut.
Cheers,
Jonas
[1]
https://github.com/dracutdevs/dracut/blob/8365177644bee107dcb66a71c8a7509900c9ece4/dracut.sh#L1678
[2]
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/intel-ucode=205127aa79bcd2a06f88c80d38e8bf8aac60bb43#n20
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 21/05/2019 20:55, Genes Lists via arch-general wrote: Funnily enough, while I do have intel-ucode package installed I don't have amd-ucode. The dracut script seems to have found it somewhere I suppose - not sure where yet. AMD's microcode is in linux-firmware: /usr/lib/firmware/amd-ucode/
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Hi, > This output is a json file, so I'm not sure what you're outputting there. > Something was wrong with the pastebin-service, I pasted it again: http://sprunge.us/3rXzR4 root is an XFS on an encrypted luks device. BR Bjoern signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 17:29 Bjoern Franke via arch-general escreveu: Just dracut -f /boot/initramfs-linux.img. It is that simple. Tried it, the output looked fine: https://p.rrbone.net/paste/FV7HMpE7# But while booting dracut hang on "initqueue hooks" This output is a json file, so I'm not sure what you're outputting there. Anyway, I got this as well on a VM. You can pass rd.shell, rd.timeout and rd.retry to your cmdline. Please refer to dracut.cmdline man page. Also, make sure you have the proper root= and other arguments as well on your cmdline. Regards, Giancarlo Razzolini pgpF9vEbHMPrB.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
> Just dracut -f /boot/initramfs-linux.img. It is that simple. Tried it, the output looked fine: https://p.rrbone.net/paste/FV7HMpE7# But while booting dracut hang on "initqueue hooks" Thanks for your efforts, Bjoern signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 1:21 PM, Giancarlo Razzolini wrote: >> Got text prompt for passphrase not graphical - think there is a way to >> get graphical as well but need to read further how to do that. I prefer >> text as I also can see the boot progress details which is helpful. >> Still, be good to know how to get the graphical prompt anyway. >> > > I suppose as more and more people start using it, we'll eventually have > instructions on how to do these more custom environments. > Definitely - getting dracut in first then later on it should not be too hard to add a plymouth[1] package if there's interest in a more graphical boot. thanks again for doing this. gene [1] https://github.com/freedesktop/plymouth/tree/master/src
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 2:48 PM, Giancarlo Razzolini wrote: > Em maio 21, 2019 15:42 Genes Lists via arch-general escreveu: ... > > Loading the microcode before will probably always work and should > continue to be the desirable solution. .. Funnily enough, while I do have intel-ucode package installed I don't have amd-ucode. The dracut script seems to have found it somewhere I suppose - not sure where yet. thank you. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
W dniu 21.05.2019 o 20:48, Giancarlo Razzolini via arch-general pisze: > Em maio 21, 2019 15:42 Genes Lists via arch-general escreveu: >> Early Microcode and initrd. >> >> I notice that the AMD microcode is [1] in the initrd while the intel >> microcode is not. >> >> Booting with option: >> initrd=/boot/intel-ucode.img >> to get the microcode installed early works fine with dracut as it always >> has. >> >> Is this something that will remain the same as now or does this >> potentially change under dracut? >> > > This probably needs to be changed. No point in having AMD microcode into > the initramfs > if you have an intel processor. It's wasted space. > > Loading the microcode before will probably always work and should > continue to be the > desirable solution. > > Regards, > Giancarlo Razzolini But I believe dracut may handle microcode itself too, at least in fedora it is packed with the core initramfs somehow. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 15:42 Genes Lists via arch-general escreveu: Early Microcode and initrd. I notice that the AMD microcode is [1] in the initrd while the intel microcode is not. Booting with option: initrd=/boot/intel-ucode.img to get the microcode installed early works fine with dracut as it always has. Is this something that will remain the same as now or does this potentially change under dracut? This probably needs to be changed. No point in having AMD microcode into the initramfs if you have an intel processor. It's wasted space. Loading the microcode before will probably always work and should continue to be the desirable solution. Regards, Giancarlo Razzolini pgppbqe8Wqzbi.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Early Microcode and initrd. I notice that the AMD microcode is [1] in the initrd while the intel microcode is not. Booting with option: initrd=/boot/intel-ucode.img to get the microcode installed early works fine with dracut as it always has. Is this something that will remain the same as now or does this potentially change under dracut? thanks gene [1] lsinitrd shows: Early CPIO image drwxr-xr-x 3 root root0 May 21 11:48 . -rw-r--r-- 1 root root2 May 21 11:48 early_cpio drwxr-xr-x 3 root root0 May 21 11:48 kernel drwxr-xr-x 3 root root0 May 21 11:48 kernel/x86 drwxr-xr-x 2 root root0 May 21 11:48 kernel/x86/microcode -rw-r--r-- 1 root root30546 May 21 11:48 kernel/x86/microcode/AuthenticAMD.bin
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 15:15 Andy Pieters escreveu: What's the rationale for going dracut? I'm quite happy with mkinitcpio I think I've addressed this in the first email. I'm also quite happy with mkinitcpio, and I myself maintain several mkinitcpio hooks that would need to be re-written for dracut. But, from the mkinitcpio development perspective, it lacks several things that would be necessary to develop it further. We don't have a testing suite, which makes the development process quite tiresome and error prone. Our network booting code is not working for even the simplest cases. We have two ways to boot the system today, and depending on the hooks combinations we have issues. Dracut by default uses systemd and I think that will be the supported way to boot Arch. Even though dracut can use a non systemd initramfs, we should make things more uniform. Whomever wants to hack dracut, will have much more ways to do so than we have with mkinitcpio currently. I know, change is not always good for everyone, but I think that in the long term Arch will only benefit from this change. Also, I believe that people interested in using mkinitcpio, will be more than able to help maintain it, when we eventually (if) remove it from our repositories. Heck, I might maintain it myself on the side, since I have a lot of stuff going on for it. But, I believe that for Arch official initramfs system, we should replace it. There are other options too, I have considered dracut because it currently fills in a gap we have on the development process, while also fixing all the corner cases mkinitcpio doesn't support well today. Regards, Giancarlo Razzolini pgpKX26GCp9qZ.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 05/21/2019 12:06 PM, Giancarlo Razzolini via arch-general wrote: > I'll stress this, dracut and mkinitcpio will co-exist for a *long* time. So, > each will have their own hooks for updating the images. > Thank you. mkinitcpio isn't broken and using both SuSE with dracut and Arch with mkinitcpio -- I prefer the Arch mkinitcpio approach. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
What's the rationale for going dracut? I'm quite happy with mkinitcpio
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 13:24 Genes Lists via arch-general escreveu: 1) Feedback: Tested one computer and it worked fine. Used refind to boot - it has encrytped /home but not root. Got text prompt for passphrase not graphical - think there is a way to get graphical as well but need to read further how to do that. I prefer text as I also can see the boot progress details which is helpful. Still, be good to know how to get the graphical prompt anyway. I suppose as more and more people start using it, we'll eventually have instructions on how to do these more custom environments. Created initrd using # dracut --kver xxx No need for using --kver, unless your booted kernel differs from the installed one. The pacman hooks will have to use kver, most likely. This seems to contain pretty much everything best I can tell 2) Question: Arch typically has used unversioned initrd images which has the convenience that the boot standzas don't need updating on new kernel. Just dracut -f /boot/initramfs-linux.img. It is that simple. or perhps soft link (ln -s)? We don't need to make things that complex. Regards, Giancarlo Razzolini pgpAlo4QSl3Qg.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 12:21 Lone_Wolf escreveu: from https://dracut.wiki.kernel.org/index.php/Main_Page : * Scripts that end up on the initrd should be POSIX compliant. dracut will try to use /bin/dash as /bin/sh for the initrd if it is available, so you should install it on your system -- dash aims for strict POSIX compliance to the extent possible. * Hooks MUST be POSIX compliant -- they are sourced by the init script, and having a bashism break your user's ability to boot really sucks. Seems like having dracut depending on bash may not be a good idea. Or is there a way to make sure dracut scripts & hooks will use bash in POSIX-compliant mode ? If you have dash installed dracut will use it instead of bash. It is *that* simple. But, I'm not much concerned here about POSIX compliance as I'm concerned about it actually being a good replacemente to mkinitcpio *and* actually booting the machines of users. I based my package on fedora's. So, the dependencies were carefully replicated to avoid issues. But anyone can hack it later to use dash or busybox. Regards, Giancarlo Razzolini pgpUjUthoV3Xo.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 11:26 Genes Lists via arch-general escreveu: ... I'm an arch tester and I'd be happy to test dracut. It would be helpful if you could create a little write-up on 'how to switch' from mkinitcpio to dracut. Just run dracut =D. But seriously, I'll work on a wiki page about this. Dracut has several man pages too, I suggest starting with dracut.cmdline. And I assume modules now in HOOKS would move to /etc/dracut.conf.d/hooks.conf or similar. I have not yet decided on the configuration, but I think I'll have something similar to mkinitcpio.conf as /etc/dracut.conf. All being well, the kernel package will need to be modified to update /usr/share/libalpm/hooks/60-linux.hook to now call dracut. I'll stress this, dracut and mkinitcpio will co-exist for a *long* time. So, each will have their own hooks for updating the images. Regards, Giancarlo Razzolini pgpWzD8ShnTjf.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 12:41 PM, Doug Newgard via arch-general wrote: > > > Since ln won't work on vfat, that's not really an option for a lot of people. > Ah thanks and good point. While it would actualy work with refind ( as the images are on ext4 /boot partition and only the refind efi images sit in the ESP partition) the solution should be agostic to boot manager. So that means no links; easy enough and same as we do now anyway. Thank you. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On Tue, 21 May 2019 18:28:50 +0200 Damjan Georgievski via arch-general wrote: > > 2) Question: > >Arch typically has used unversioned initrd images which has the > >convenience that the boot standzas don't need updating on new kernel. > > > > This can (also) be fixed if Arch implements the `kerne-install` [1] > mechanism to update the boot-loader stanzas. > > > [1] > https://www.freedesktop.org/software/systemd/man/kernel-install.html > Automated config is evil.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On Tue, 21 May 2019 12:24:09 -0400 Genes Lists via arch-general wrote: > 1) Feedback: > Tested one computer and it worked fine. > Used refind to boot - it has encrytped /home but not root. > Got text prompt for passphrase not graphical - think there is a way to > get graphical as well but need to read further how to do that. I prefer > text as I also can see the boot progress details which is helpful. > Still, be good to know how to get the graphical prompt anyway. > > Created initrd using > # dracut --kver xxx > > This seems to contain pretty much everything best I can tell > > 2) Question: >Arch typically has used unversioned initrd images which has the >convenience that the boot standzas don't need updating on new kernel. > > Which is preferable way to deal with this with dracut: > > 1) Unversioned: > ># dracut initramfs-linux.img --kver 5.1.3-arch1-1-ARCH > > 2) Keep version but link to unnamed: > ># dracut --kver 5.1.3-arch1-1-ARCH ># ln /boot/initramfs-5.1.3-arch-1-ARCH.img initramfs-linux.img > > or perhps soft link (ln -s)? > > thanks. Since ln won't work on vfat, that's not really an option for a lot of people.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
1) Feedback: Tested one computer and it worked fine. Used refind to boot - it has encrytped /home but not root. Got text prompt for passphrase not graphical - think there is a way to get graphical as well but need to read further how to do that. I prefer text as I also can see the boot progress details which is helpful. Still, be good to know how to get the graphical prompt anyway. Created initrd using # dracut --kver xxx This seems to contain pretty much everything best I can tell 2) Question: Arch typically has used unversioned initrd images which has the convenience that the boot standzas don't need updating on new kernel. Which is preferable way to deal with this with dracut: 1) Unversioned: # dracut initramfs-linux.img --kver 5.1.3-arch1-1-ARCH 2) Keep version but link to unnamed: # dracut --kver 5.1.3-arch1-1-ARCH # ln /boot/initramfs-5.1.3-arch-1-ARCH.img initramfs-linux.img or perhps soft link (ln -s)? thanks.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 11:21 AM, Lone_Wolf wrote: > > On 21-05-2019 16:26, Genes Lists via arch-general wrote: >> On 5/20/19 10:41 PM, Giancarlo Razzolini via arch-dev-public wrote: >>> Hi All, >>> >> ... >>> In this initial phase I want to ask as many of you to test this as a >>> replacement to mkinitcpio in your setups, >>> as many as possible, and in as many scenarios as possible. We will >> ... >> >> I'm an arch tester and I'd be happy to test dracut. >> >> It would be helpful if you could create a little write-up on 'how to >> switch' from mkinitcpio to dracut. >> >> Its straightforward for me to add a boot stanza to refind to use the >> dracut img. >> >> And I assume modules now in HOOKS would move to >> /etc/dracut.conf.d/hooks.conf >> or similar. >> >> All being well, the kernel package will need to be modified to update >> >> /usr/share/libalpm/hooks/60-linux.hook >> >> to now call dracut. >> >> Thanks for working on this. >> >> gene > > > from https://dracut.wiki.kernel.org/index.php/Main_Page : > > > * Scripts that end up on the initrd should be POSIX compliant. dracut > will try to use /bin/dash as /bin/sh for the initrd if it is > available, so you should install it on your system -- dash aims for > strict POSIX compliance to the extent possible. > * Hooks MUST be POSIX compliant -- they are sourced by the init > script, and having a bashism break your user's ability to boot > really sucks. > > > Seems like having dracut depending on bash may not be a good idea. > > Or is there a way to make sure dracut scripts & hooks will use bash in > POSIX-compliant mode ? POSIX compliant means that scripts must run with either bash or POSIX sh, not "only in bash". So, on the contrary, dracut is broken stuff when trying to use POSIX, because their own current official hooks bundled by the upstream dracut project are not POSIX compliant and therefore only work with bash, but they intend to fix that and at least some are fixed in git master (although I haven't tested), see for example https://github.com/dracutdevs/dracut/pull/516 POSIX-compliant mode is exactly the opposite of what we want. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On Tue, 21 May 2019 17:21:31 +0200 Lone_Wolf wrote: > Seems like having dracut depending on bash may not be a good idea. > > Or is there a way to make sure dracut scripts & hooks will use bash in > POSIX-compliant mode ? > > LW Bash runs POSIX scripts just fine. No need to do anything.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 21-05-2019 16:26, Genes Lists via arch-general wrote: On 5/20/19 10:41 PM, Giancarlo Razzolini via arch-dev-public wrote: Hi All, ... In this initial phase I want to ask as many of you to test this as a replacement to mkinitcpio in your setups, as many as possible, and in as many scenarios as possible. We will ... I'm an arch tester and I'd be happy to test dracut. It would be helpful if you could create a little write-up on 'how to switch' from mkinitcpio to dracut. Its straightforward for me to add a boot stanza to refind to use the dracut img. And I assume modules now in HOOKS would move to /etc/dracut.conf.d/hooks.conf or similar. All being well, the kernel package will need to be modified to update /usr/share/libalpm/hooks/60-linux.hook to now call dracut. Thanks for working on this. gene from https://dracut.wiki.kernel.org/index.php/Main_Page : * Scripts that end up on the initrd should be POSIX compliant. dracut will try to use /bin/dash as /bin/sh for the initrd if it is available, so you should install it on your system -- dash aims for strict POSIX compliance to the extent possible. * Hooks MUST be POSIX compliant -- they are sourced by the init script, and having a bashism break your user's ability to boot really sucks. Seems like having dracut depending on bash may not be a good idea. Or is there a way to make sure dracut scripts & hooks will use bash in POSIX-compliant mode ? LW
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/20/19 10:41 PM, Giancarlo Razzolini via arch-dev-public wrote: > Hi All, > ... > > In this initial phase I want to ask as many of you to test this as a > replacement to mkinitcpio in your setups, > as many as possible, and in as many scenarios as possible. We will ... I'm an arch tester and I'd be happy to test dracut. It would be helpful if you could create a little write-up on 'how to switch' from mkinitcpio to dracut. Its straightforward for me to add a boot stanza to refind to use the dracut img. And I assume modules now in HOOKS would move to /etc/dracut.conf.d/hooks.conf or similar. All being well, the kernel package will need to be modified to update /usr/share/libalpm/hooks/60-linux.hook to now call dracut. Thanks for working on this. gene
