Skip to content

Conversation

@wahrwolf
Copy link
Contributor

@wahrwolf wahrwolf commented Dec 29, 2025

When "Copy network config from ISO" is selected, it sets up systemd-resolved and systemd-networkd, however, systemd-resolved requires resolve.conf to be a stub in order to work properly.

This PR addresses the issue that it's currently not a stub, but a core filesystem file meant for other types of resolvers.

@wahrwolf wahrwolf requested a review from Torxed as a code owner December 29, 2025 19:20
@svartkanin
Copy link
Collaborator

Can you provide a description of the PR and the problem

@Torxed
Copy link
Member

Torxed commented Dec 29, 2025

Can you provide a description of the PR and the problem

I filled in the blanks as I forced poor @wahrwolf to submit this PR 😅 Sorry for the confusion!

@wahrwolf
Copy link
Contributor Author

I tested the change and after the first reboot resolvectl status confirms the stub-resolver

Here is the weird part:
From the iso live system the symlink looks fine.
However if you chroot into the system after the archinstall script finished, the symlinks is not correctly displayed.
Both file and ls detect it as a local ascii file.
Tbh I do not understand it and it hints to something weird with os.symlink, the arch-chroot script, ext4 or all together.

Everything looks normal after the reboot, so I assume this can be safely ignored

@svartkanin svartkanin merged commit 9f4f29b into archlinux:master Dec 30, 2025
9 checks passed
resolv_config_path = Path(f'{self.target}/etc/resolv.conf')
if resolv_config_path.exists():
os.unlink(resolv_config_path)
os.symlink('/run/systemd/resolve/stub-resolv.conf', resolv_config_path)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is actually unnecessary, since the first boot would've created the file anyway (when it doesn't exist).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im guessing it should only be handled if chrooting into the (pre)install then ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is actually unnecessary, since the first boot would've created the file anyway (when it doesn't exist).

The problem is that the core package/filesystem contains the file, so it won't be created on the first boot. And it's better to be explicit here I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants