#EFI Stub + LUKS without initramfs?
1 messages ยท Page 1 of 1 (latest)
no
just no lol
you need an initramfs for Luks at this point
maybe forever
but it makes sense, otherwise you'll have to include a ton of stuff that's only used once at boot in the kernel
esp more clear "user space" stuff such as things for key entry
you're kernel image name does not have to provide a .efi file name suffix. that may help you simplify the vfat efi partition config somewhat
if you can mounting esp vfat partition to /boot works great
that depends, some UEFIs do enforce the suffix
what is the problem with using an initramfs?
if security is the issue, then just combine it all into an UKI and boot that
I think that does a raw dm-crypt device
so it's not luks
and it basically means you have to have your key laying around in plaintext ready to be read
if you think that's fine, go for it, but you also lose all the LUKS features like multiple keyslots
that method as a whole is very unsupported and is not particularly safe
using an initramfs is "the way" to do this
that LITERALLY builds the key into the kernel command line, so anyone who can copy your kernel can obtain your key
this reply sums it up well
also this
just everything about this method is error prone and not very safe
not to say it's impossible, just not a great idea for most cases
yeah i do that currently
with an initramfs
the bottom line is that doing that means if someone steals your usb they have your keys...
unless you enter in the hex representation of the dm-crypt key in the efi shell
which will not be fun
your key will be present in /proc/cmdline as well
for everyone to read
it's just a very, very bad idea to do this, i think it also means you're not using LUKS
i mean bad idea for most usage, it makes things a lot more breakable and less secure



Why? What's wrong with using an initramfs?
i would like to know as well, reasons I've heard seem to be that it's an extra part and complicated
not from this user but from others
using an initramfs is in some ways digital foreplay. Just warming up before mounting that root filesystem partition ๐
maintaining an initramfs can be simpler when using the distro kernels
installkernel makes the maintenance part easy
that's the real key, dist-kernel doesn't technically care too much about your initrd
buuuuut defaults to using isntallkernel, but as a "whole package" dist-kerrel is the path of least resistance
using an initramfs is in some ways digital foreplay.
what a sentence
Use an initramfs
wait i thought i amde this non-fatal ahh
you can disable that bit tho
you can set find_libgcc = false in /etc/ugrd/config.toml
tf it should be non-fatal?
it should just return
oh wait im dumb i was looking at the wrong section lol, was focusing too much on the musl bit
i think you removed this part of the output, _mounts
for some reason it was not able to autodetect your / mount?
are you doing this ina chroot
it does it reading /proc/mounts
can you show your /proc/mounts? or at least the _mounts config?
it's failing because it doesn't see anything mounted at '/' which is kinda weird
I'm gonna improve that error real quick tho
yeah your / mount is not there?
can you show lsblk -f
are you sure you're doing this with your root on a mountpoint?
can you show your lsblk info?
it's weird that the root mount isn't seen in the chroot
arch-chroot gives no error about it not being used on a mountpoint?
im pushing this anyways, to help with the error output
if you could test the 9999 that would be appreciated, it should at least be more clear about the issue
there was a similar issue in the past where blkid didn't find the root info, but i've never seen it totally not see a / mount
this might be that problem where if a step in the chrooting is not done, then the PARTUUIDs are not visible
not even the / mount is in /proc/mounts
that is what really throws me off
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=1963054,mode=755,inode64 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,relatime,inode64 0 0
run /run tmpfs rw,nosuid,nodev,relatime,mode=755,inode64 0 0
tmp /tmp tmpfs rw,nosuid,nodev,inode64 0 0
LiveOS_rootfs /etc/resolv.conf overlay rw,relatime,lowerdir=/run/rootfsbase,upperdir=/run/overlayfs,workdir=/run/ovlwork,uuid=on 0 0```
@quick gyro what livecd image are you using?
slight chance it has a bug, and can you please share lsblk -f both inside and outside the chroot?
no
the files added to the initramfs are taken from the rootfs
so you must be chrooted for this to work properly
yeah I'm honestly not even sure how you got ugrd in the live environment
and yeah by design they pull files from the host, dracut does the same. you can technically disable the automatic stuff and specify the info yourself but they kinda defeats the purpose
if you run it in a chroot for a particular rootfs, it uses that context to autodetect how to more or less get into the same root environment
you can cook blindfolded, it's possible, idk why you would
ugrd at least more or less entirely expects it can read host info, which will be used for booting/config validation
if it can't get that info it won't work very well
dracut may work to make images like that but if you're pulling stuff from the livecd environment you can expect some compatibiltiy issues with everything else, you're sorta mashing bits from different systems together
at the very least i don't think grub-mkconfig will be happy with you generating config from another chroot. there are just countless ways this can go wrong because most of these tools are meant to be run in the context of a valid mounted rootfs
esp if you're using dracut in hostonly mode which is probably the most reasonable route
and if you disable hostonly mode on ugrd, you're kinda asking for trouble, but it can still work if you pass a valid root= to it, but if you do it in hostonly, that's not even required
uhhhh maybe?
tbh i just added a feature that could do that?
but you'd have to disable a ton of the host validation stuff
actually the feature as it is won't work because it attempts to make a mountpoint in the image using the same destination
so it really wants it to be read from /, but i think you may be able to trick it into working if you do auto_mounts = ['/rootfs'] and have the root filesystem mounted there
but really, it's just best to do it in a chroot
like imagine future upgrades, they will likely be done from the context of the running system, so you want it to be as close to that as possible to ensure it's done reliably
this is an absolute hack. you could also disable hostonly mode and more or less pray lol, ugrd could do that, but the only part of it that i think is "better" than dracut is that it does all this validation and auto-config. if you're using it without that it's probably harder to use than dracut
is there some reason you're avoiding chrooting? tbh ugrd is designed under the assumption that you're running it against your host in most cases, and it expects to be able to read info such as the root mount, as that should always be present. if there is some reason a chroot can't be done I would like to consider that and make options for it, i've just never really seen that done
thanks i think i fixed that, my dyslexic ass can't read sometimes
which deps? and tbh ugrd is specifically designed to make an initramfs for the system running it, that's how it's able to autodetect most stuff
the fact of the matter is there is no sane way to autodetect things if you're building for another system
so dracut may work better for that, but then when you use it, you must be very careful about the cmdline args you pass
and dracut pulls binaries from the system used to build it too, so you can run into issues with it pulling things that won't run on other systems
if building an initramfs to be used on another system, there are always more considerations

