Arch Linux

@rne: Thanks for the report.

I'll look into this as soon as I can. There are a few patches that need to be merged as well. I'll try to make room for this over the weekend.

I can confirm the same issues.

The lack of login prompt only happens on my older board. It works fine on newer (after 2018) and VMs.

I don't know about #1, but #2 and #3 are probably  FS#66397 

Just realized you said GRUB for #1. GRUB is not on the ISO, so that sounds like something else is going on completely, not an ISO issue.

rne mistook systemd-boot for GRUB, but #1 is indeed an Archiso issue. There's a patch in the mailing list that fixes it: https://lists.archlinux.org/pipermail/arch-releng/2020-March/003950.html .

I'm running into the same issue - is there any timeline on this? I'm happy to assist if there's any suggestions.

Should note a couple of things:

I managed to get it to boot occasionally (probably 1/10 reboot attempts) when initializing Pacman keyring doesn't fail. I'm not sure why it fails vs doesn't fail. I just booted the live CD as fast as possible and it seems to work. My guess is there's a race condition.

To add: when I enabled systemd.debug-shell on kernel commandline to peek what is happening - all the related services complain about being unable to create cgroup; this includes getty@tty1, systemd-logind, systemd-user-sessions and pacman-init.

Attempt to start anything (eg. sshd service) ends with same reason.

From other extremely weird issues - mounts are messed as hell - with directories bind mounted on top of each other 8 times in a row. This actually looks like some odd systemd issue. `findmnt` output is particularly entertaining.

Just boot May edition of arch iso with systemd.debug-shell=1 (in uefi mode) to double check this.

@rne, @lettergram, @msoltyspl: I can not reproduce this behavior (so far), using a virtualized environments.

Could you give some background on your respective hardware in use?

Are you also experiencing these issues, if you build an image yourself and boot that?

Most recently I've experienced that on Dell R320 server when booting in uefi mode (didn't test in bios) - this is with official arch iso. Haven't build the image myself.
I've also experienced it with some older desktop (old amd motherboard) which I just use occasionally with arch iso images - I'll provide the exact model on monday.

> 1) Grub's default entry is not the Live ISO entry, but an EFI shell.

Ran into this too, screen didn't show anything and then I was already in an EFI shell.

I logged in remotely to such iso booted machine

- changed topmost /dev propagation to private
- mounted devpts manually
- started sshd directly

Attached file has full journalctl -b and findmnt output.

I just encountered this as well. I tried a bunch of options and was finally able to get a prompt by adding "systemd.unified_cgroup_hierarchy=0" to the kernel command line arguments. I don't think it fully addressed the issue though as I'm still experiencing other odd issues such as SSH being unable to allocate PTYs. Mounting a devpts filesystem on /dev/pts at least resolved that and got me far enough along that I could continue my install.

FYI: #1 is now fixed and will be part of the next release: https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/3/diffs

For #2/#3 I have just created a merge request [1] and it would be immensely helpful, if you could test your respective systems with an iso built from the "issues/10" branch.
Depending on your system, this should not take much longer than a few minutes:

```
sudo pacman -S archiso
git clone --branch "issues/10" https://gitlab.archlinux.org/archlinux/archiso.git
cd archiso
sudo ./configs/releng/build.sh -v
```

Then you'll be able to use the resulting iso in the `out` directory.
Please let me know, if this works for you!

[1] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/7

@dvzrv

Can you please rename the systemd.network files with a numeric ID in front?

For example:
ethernet.network to 50-ethernet.network
wireless.network to 50-wireless.network

This is what the standard practice is. If you see EXAMPLES under man systemd.network, all the configuration file names start with two digit number.

Even earlier udev rule for dhcpd (which was deleted) - that file also started with a two digit number.

I use custom Archiso. I chose 50 because its middle of 00 to 99 and it makes it is easy to add some custom .network files before OR after the default files.

Thank you

Please test whether you still experience issues with the 2020.06.01 image from the mirrors.

@amish I can rename them for the next release, for sure!

The latest ISO from the mirrors boots into command prompt for me. Thanks

@p0tr3c: Excellent. Thanks for the confirmation.