ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
<Dylanger> Wow, its like, impossible to statically compile cryptsetup lol
<Dylanger> 🙃
<steev> i think you need to build a static lvm2 and then it should
iivanov has joined #aarch64-laptops
<Dylanger> Anyone have an idea why this is failing?
<Dylanger> Compiling cryptsetup statically is surprisingly difficult
<Dylanger> `cannot find -ludev: No such file or directory`
<Dylanger> I wonder if I need to compile udev statically too
<Dylanger> Okay cool, so it's not just me
<Dylanger> I think right now, it's not possible to compile cryptsetup statically for aarch64
<Dylanger> It's a shame there's no direct way for the kernel to ask for password input, avoiding initramfs all together
<alpernebbi> Dylanger: I remember getting Debian's kernel/initramfs working for booting on LUKS/LVM etc. with Depthcharge but its size limit is the big problem
<Dylanger> For the moment, I'm trying amstan's hack, just created a normal ext4 partition, then gonna try point init= to that partition
<Dylanger> Then do pivot_root
<Dylanger> After everything is up
<Dylanger> Should only need busybox + cryptsetup statically compiled
<Dylanger> Shouldn't be over ~15MB?
<alpernebbi> do you have a lazor? guessing from a previous link
<Dylanger> Homestar (Duet 5)
<Dylanger> Same baseboard as Lazor tho I think
<Dylanger> strongbad
<alpernebbi> I think those are new enough to have switched to a 512MiB limit
<alpernebbi> arm64 boards had 32MiB, older arms 16MiB I think
<alpernebbi> IIRC you just gotta put it in the FIT and that works
<Dylanger> 32MB should be enough for a tiiiny shim
<Dylanger> I wish either
<Dylanger> A) There was a super smol rust bin that just did the thing and pivoted
<Dylanger> B) Kernel did the thing (yayyay more attack surface)
<alpernebbi> oh and you can compress the kernel before putting it inside the FIT, which gives you a lot of room
<alyssa> alpernebbi: Oh hi there
<alpernebbi> hello :D
<alyssa> Dylanger: I do have debian initramfs cryptsetup + debian kernel under the 32MB limit, following alpernebbi 's surface
<alyssa> though dunno if that's still possible
<alpernebbi> tbh my main motivation in working on u-boot was to get rid of that restriction
<alpernebbi> I'm also somewhat in the "whatever makes it boot" team
<Dylanger> I agree, whatever gets it to finish, without an initramfs the whole process would be much more elegant, wouldn't it?
<alpernebbi> not sure, initramfs is a powerful construct, like debian-installer completely runs as an initramfs
<alpernebbi> macc24: There's "coreboot" defconfigs for u-boot but they're x86-only, I guess the stuff those use needs porting to arm64 and into a new "coreboot_arm64" defconfig
<alpernebbi> and coreboot's build system also has to be modified to have u-boot as a choice for arm64 with that defconfig (instead of the specific board's defconfig like I did)
<macc24> alpernebbi: yea i'll tinker around it
<alpernebbi> I also tried to build it with tianocore once, but gave up when I noticed it was using x86 compilers...
<Dylanger> Does anyone know what Google's reasoning was for dropping U-Boot for Depthcharge?
<macc24> a
* alpernebbi plans to work on other u-boot things, pulseaudio, depthcharge-tools before even starting on coreboot
<alyssa> Dylanger: moar speed?
<Dylanger> Ah yeah fair enough
robher has quit [Read error: No route to host]
robher has joined #aarch64-laptops
Lucanis1 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
robher has quit [Remote host closed the connection]
robher has joined #aarch64-laptops
Lucanis1 has quit [Ping timeout: 480 seconds]
robher has quit [Read error: No route to host]
robher has joined #aarch64-laptops
robher has quit [Read error: No route to host]
robher has joined #aarch64-laptops
<gwolf> Dylanger: Well, if it's hard to compile statically... maybe it is a sign you should port cryptsetup to Rust! ;-)
hexdump01 has joined #aarch64-laptops
hexdump01 has quit []
alyssa has left #aarch64-laptops [#aarch64-laptops]
hexdump0815 has joined #aarch64-laptops
<hexdump0815> Dylanger: i'm running luks encrypted root fs on all my chromebooks - i hope this will help you to get it working for you as well: https://github.com/hexdump0815/imagebuilder/blob/main/info/generic/install-to-emmc-with-luks-full-disk-encryption.txt#L160-L190
<amstan> what is this 32MB limit people are talking about for depthcharge?
<hexdump0815> essentially the trick is to get below 32mb for kernel and initrd which is possible by heavily compressing them - works well without any extra effort on a plain debian or ubuntu system
<hexdump0815> amstan: it looks like depthcharge does not load anything larger than 32mb from the kernel partition
<amstan> that sounds like a bug
<hexdump0815> 16mb for armv7 32bit systems and maybe the limit is lifted for newer chromebooks
<amstan> i mean, i know the partition sizes are around there, you one could always make them bigger
<hexdump0815> amstan: i think the 16mb for early systems was even kind of documented somewhere
<hexdump0815> yes, but if you make them bigger booting will only work as long as the kpart is below 32/16mb
<hexdump0815> "16mb will be enough for ever" :)
<amstan> i'm pretty sure i was using kparts in arch above 32MB before i figured out how to compress them
<macc24> amstan: huh?
<macc24> i remember not getting >16mb kernel to boot on veyron
<amstan> this was lazor
<macc24> on lazor too then
<hexdump0815> as robclark mentioned: it looks like lazor and newer seems to have lifted the limed maybe - but i also verified the limit on oak and kukui to be in place still
<amstan> see linux-aarch64-rc-chromebook-5.12.rc3-3-aarch64.pkg.tar.xz
<amstan> vs linux-aarch64-rc-chromebook-5.12.rc3-2-aarch64.pkg.tar.xz
<hexdump0815> for the armv7 chromebooks its not a big deal as there is a chainloadable u-boot for nearly all of them and you can just use that for loading the initrd
<macc24> imagine needing an initrd
<hexdump0815> for aarch64 it works quite well with 32mb limit too with compression - there is still a bit of headroom, even if the initrd has a lot of modules in it etc.
<macc24> with lz4 compressed kernel i have 12mb/32mb kernel partition space used
<hexdump0815> macc24: if you want encrypt your rootfs (which makes a lot of sense for a portable device) anything without initrd is getting painful easily as Dylanger found out as well now :)
<macc24> hexdump0815: hold my beer ;)
<alpernebbi> amstan: the size limit is CONFIG_KERNEL_SIZE in Depthcharge
<alpernebbi> hexdump0815: you might want to know that I'm trying to automate the chainloading images, see https://github.com/alpernebbi/u-boot/releases/ if you'd like to test
<hexdump0815> alpernebbi: i have that on my radar already, but it might take a bit until i get to playing around with those as for now i already have my own chainload u-boot builds for all i need
<hexdump0815> but i was very happy to see this, especially the new things like gru :)
iivanov has quit []
<steev> hmm
<steev> i wonder if those nyan ones could bring mine back to life
<steev> i miss it
<alpernebbi> steev: probably not, they're meant to run from the original firmware, I didn't consider SPI ROM images as I didn't know if they'd be useful
<steev> alpernebbi: hm, well my nyan still has the original firmwares
<steev> now that it's eol, i just wanna make it easier to run "real" linux instead of cros
<steev> and also not have to deal with the 30 second timeout and beep
trench has quit [Ping timeout: 480 seconds]
<hexdump0815> steev: this should help you to get rid of the beep etc. (the setting gbb flags section): https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks
<hexdump0815> this should boot (after maybe choosing the proper u-boot version and setting the dtb from/in the 3rd boot partition): https://github.com/hexdump0815/imagebuilder/releases/tag/211114-01
<hexdump0815> here is hopefully all the info you need to get it working yourself in case you prefer that: https://github.com/hexdump0815/imagebuilder/tree/main/systems/chromebook_nyan
<hexdump0815> but i think we are getting a bit off topic :)
<alpernebbi> I looked around in my u-boot build dir but couldn't find anything like a SPI ROM image for it
trench has joined #aarch64-laptops
SallyAhaj has joined #aarch64-laptops
<Dylanger> <hexdump0815> "macc24: if you want encrypt your..." <- Yes, but it's sort of useless for the crypto directive
<Dylanger> From what I can tell the cmdline was added for verity
<Dylanger> Who wants to shove their key into cmdline 🤮
<hexdump0815> Dylanger: the key then gets asked on screen on bootup, so no key on cmdline required
<Dylanger> 🤯 are you sure?
<hexdump0815> Dylanger: at least on debian and ubuntu there are hooks for that in the update-initramfs - not sure how other distros are handling this
<hexdump0815> the password is either asked on the console or with plymouth enabled with a nice graphical screen
<Dylanger> Ah sorry I thought you meant no initramfs at all
<Dylanger> <Dylanger> "https://www.kernel.org/doc/html..."; <- With this
<hexdump0815> i looked for options to make encrypted root working on chromebooks and none of the alternative solutions to using initramfs did really convince me: they were either very cumbersome to use/setup or not working at all (like having the passphrase in /proc/cmdline :) )
<Dylanger> <hexdump0815> "Dylanger: i'm running luks..." <- How are you generating the actual initramfs image itself?
<hexdump0815> on debian/ubuntu its done via the update-initramfs command and one needs some extra options to make it use heavy compression
<hexdump0815> see the install-to-emmc-with-luks-full-disk-encryption.txt notes i linked above
<Dylanger> Thank you!
<Dylanger> I'll try this today
<hexdump0815> let me know if anything is unclear - those notes of me are often not really proper documentation :) ... but they should give a clear idea how it is supposed to work