You are not logged in.

#1 2025-04-15 21:13:24

dootfs
Member
Registered: 2024-01-27
Posts: 26

cmdline.d missing?

I've been hitting my head against the wall for a while trying to install Arch via netboot.

The system is configured in basic fashion with an encrypted LUKS root partition, and unencrypted boot and swap partitions [swap is getting the encryption treatment just as soon as the install is finished].

The problem is that I don't see the /etc/cmdline.d directory which is supposed to contain .conf files for mkinitcpio to pick up in order to generate the UKI file.

Working off of the installation guide , it looks as simple as dropping in the relevant UUIDs into corresponding .conf files contained in /etc/cmdline.d but again, there appears to be no such directory.

I wound up with the same problem in trying to build the UKI using systemd-ukify, when the cmdline parameter didn't seem to pick up anything.

I'm wondering if I'm just fooling myself into thinking that the directory is supposed to be there, when maybe the wiki authors assume the user would make the file themselves?

Last edited by dootfs (2025-04-15 21:13:54)

Offline

#2 2025-04-15 21:31:50

Scimmia
Fellow
Registered: 2012-09-01
Posts: 12,580

Re: cmdline.d missing?

Stating the obvious....make it?

Offline

#3 2025-04-15 22:21:17

mackin_cheese
Member
Registered: 2025-01-07
Posts: 429

Re: cmdline.d missing?

if it's not there.... you make it.... you put it there.

Offline

#4 Yesterday 19:14:36

qu@rk
Member
Registered: 2021-07-28
Posts: 139

Re: cmdline.d missing?

dootfs wrote:

unencrypted boot

Not ideal. Mount the unencrypted partition as /efi and use /boot on the encrypted partition.

Offline

#5 Yesterday 21:28:29

dootfs
Member
Registered: 2024-01-27
Posts: 26

Re: cmdline.d missing?

qu@rk wrote:
dootfs wrote:

unencrypted boot

Not ideal. Mount the unencrypted partition as /efi and use /boot on the encrypted partition.

The goal is to build a .uki file in /boot/efi/Linux and then sign the .uki file to render it tamper proof, making an encrypted /boot partition unnecessary. The /boot partition is simply mounted to the encrypted root partition.

Because the root partition is GPT formatted, the GUIDs for every partition is labeled. Why do I have to drop in a .conf file when the root partition is labeled? And does cryptsetup run on startup or does mkinitcpio require a HOOK to decrypt the root partition?

Offline

#6 Yesterday 23:01:24

qu@rk
Member
Registered: 2021-07-28
Posts: 139

Re: cmdline.d missing?

You also have the kernel in /boot, and in my case amd-ucode.img. No reason to have them out of encryption. I only keep uki on /efi which is outside of encryption, and of-course it gets signed.
You can choose where uki gets created, doesn't have to be in /boot/efi/Linux.

dootfs wrote:

And does cryptsetup run on startup or does mkinitcpio require a HOOK to decrypt the root partition?

You need "encrypt" hook before "filesystems"

Offline

#7 Yesterday 23:02:27

Scimmia
Fellow
Registered: 2012-09-01
Posts: 12,580

Re: cmdline.d missing?

qu@rk wrote:
dootfs wrote:

unencrypted boot

Not ideal. Mount the unencrypted partition as /efi and use /boot on the encrypted partition.

Which just moves the files from /boot to /efi. Completely useless.

Offline

#8 Yesterday 23:06:12

qu@rk
Member
Registered: 2021-07-28
Posts: 139

Re: cmdline.d missing?

Huh? It only moves the uki. What other files are you talking about?

Offline

#9 Yesterday 23:07:39

Scimmia
Fellow
Registered: 2012-09-01
Posts: 12,580

Re: cmdline.d missing?

And the UKI is the only thing that matters

Offline

#10 Yesterday 23:11:01

qu@rk
Member
Registered: 2021-07-28
Posts: 139

Re: cmdline.d missing?

I think there's some kind of miscomunication here.
My whole point is you don't have to have any other files outside of encryption, apart from uki. That's it.
But there's usually more on /boot:

# ls /efi
linux.efi
# ls /boot
amd-ucode.img  vmlinuz-linux

Again, why have /boot outside encryption?

Offline

#11 Yesterday 23:14:17

Scimmia
Fellow
Registered: 2012-09-01
Posts: 12,580

Re: cmdline.d missing?

Those are only there because you put them there. They are doing nothing at all, and since you mentioned signing, they CAN'T do anything. Hell, amd-ucode.img is completely useless for the vast majority of users, and completely unnecessary for those that can use it as it's mostly been superseded by the microcode hook. The point isn't that you should have /boot outside encryption, the point is that it doesn't matter *at all*, and criticizing someone else's setup for it, give me a break.

Offline

#12 Yesterday 23:16:25

qu@rk
Member
Registered: 2021-07-28
Posts: 139

Re: cmdline.d missing?

That's just bad practice though. You're getting annoyed by me insisting you shouldn't keep unnecessary files outside encryption? Give me a break.

Offline

#13 Yesterday 23:20:28

Scimmia
Fellow
Registered: 2012-09-01
Posts: 12,580

Re: cmdline.d missing?

It's not bad practice. Do you know what cargo culting means?

Offline

#14 Yesterday 23:23:17

qu@rk
Member
Registered: 2021-07-28
Posts: 139

Re: cmdline.d missing?

It is if they aren't required. It's just extra stuff you put outside and lock when you can just put inside.
Not familiar with that phrase but I'll take a guess you're going for something witty.
Again, I will insist it's just bad practice no matter it rubs you the wrong way. I appreciate your knowledge here but I think you are wrong with this, that's it. The "oh cmon" is not an argument.

Offline

#15 Today 08:04:53

seth
Member
Registered: 2012-09-03
Posts: 62,761

Re: cmdline.d missing?

qu@rk wrote:

That's just bad practice though. You're getting annoyed by me insisting you shouldn't keep unnecessary files outside encryption? Give me a break.

You "should" not keep unnecessary files anywhere.
The stuff in boot is supposed to be required to [checks notes] "boot" the system.
If you have other stuff there, move it out of /boot (except if it's a porn video and you loop that in the bootloader - "rule #4: boobs are always on topic") and if you have unnecessary files anywhere on your drive, just move them to /dev/null

@dootfs, I guess you managed to create that directory and now proceed with the configuration, ie. this topic is solved?
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Offline

Board footer

Powered by FluxBB