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.
- 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
On Tue, 21 May 2019 18:28:50 +0200 Damjan Georgievski via arch-general arch-general@archlinux.org wrote:
- 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.
On Tue, 21 May 2019 12:24:09 -0400 Genes Lists via arch-general arch-general@archlinux.org wrote:
- 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
- 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:
Unversioned:
# dracut initramfs-linux.img --kver 5.1.3-arch1-1-ARCH
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.
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
Em maio 21, 2019 13:24 Genes Lists via arch-general escreveu:
- 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
- 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
What's the rationale for going dracut? I'm quite happy with mkinitcpio
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
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
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
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
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:
root is an XFS on an encrypted luks device.
BR Bjoern
On 5/21/19 12:24 PM, Genes Lists via arch-general wrote:
- 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
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.
On Sat, 25 May 2019 05:54:23 +0000, 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
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.
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
Eli Schwartz via arch-general arch-general@archlinux.org 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
On 5/27/19 6:10 AM, Joerg Schilling wrote:
Eli Schwartz via arch-general arch-general@archlinux.org 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).
Neven Sajko via arch-general arch-general@archlinux.org 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
arch-general@lists.archlinux.org