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.

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

What's the rationale for going dracut? I'm quite happy with mkinitcpio

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

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

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

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

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