16:30 <Xogium> hi guys :) hopefully quick question… Basically, what happens at shutdown if a kernel has an embedded initramfs ? I think it won't do anything with it at shutdown and only at boot, and so I would be probably better off keeping them separate ? Aka, using unpacking tools to unpack it under /run/initramfs, which lets systemd pivot root to it again during shutdown

16:31 <Xogium> but can someone confirm this ?

16:32 <Xogium> I need this as it is right now because otherwise none of my filesystems are unmounted properly and corrupt

16:34 <jn> seems like a userspace question

16:35 <jn> i **heard** that systemd can pivot back into the initramfs or something like that

16:35 <jn> but i'm by no means proficient in systemd

16:36 <Xogium> yes but it pivots back because its content was extracted into /run/initramfs

16:36 <Xogium> I was wondering if kernel could natively do something similar since it would have an embedded initramfs inside itself

16:41 <Xogium> but it might be impossible for kernel

16:43 <jn> the initramfs may be freed long before shutdown

16:44 <Xogium> yeah what I was thinking…

16:45 <jn> not in all systems, but it can happen

16:45 <Xogium> how so ?

16:46 <jn> i'd have to read up on what triggers this. initrd(4) has some information, not sure if it describes the current state though

16:46 <Xogium> I mean, how could it happen, and how could it not ? What determines this ?

16:47 <jn> but it makes sense: when the initramfs is no longer needed in the system, then the occupied memory can be freed

16:47 <Xogium> ah

16:47 <Xogium> yeah I think I've seen this

16:47 <jn> how not? --- not all systems move to a different root fs

16:48 <Xogium> but I was thinking that since it has it inside still, it could unpack when it receives shutdown instruction again

16:48 <Xogium> but well maybe not ;)

16:49 <jn> ah, when it's baked in during compilation?

16:50 <jn> not sure about the exact details, but i think there's an unpacking step in the way

16:55 <Xogium> yeah baked in, linked in, embedded :D that's what I meant

16:56 <Xogium> I was hoping it would unpack again at shutdown, basically do the boot up procedure in reverse

17:11 <jn> Xogium: i suspect the packed copy is discarded pretty early

17:11 <Xogium> well damn

17:11 <Xogium> oh well

17:11 <jn> (would have to check in order to confirm, though)

17:11 <Xogium> yes, that would make sense

17:11 <Xogium> and so it can't extract it again and put it in what is already running

17:18 <Xogium> hmm

17:19 <Xogium> also I toyed with tinyconfig for the first time today, really looked at and I'm shocked at how fast the kernel grows as soon as you enable something !

17:20 <Xogium> starts off ok with 380 KB compressed, 630 uncompressed. But then, even adding something like networking, and then taking out all of the drivers/subsystems in there I don't need, adding only pseudo fs, overlayfs and squashfs, and I'm up to 1.3 MB compressed, nearing on 6 MB uncompressed

17:20 <Xogium> it probably enabled stuff behind my back when I was not looking ;)

17:21 <Xogium> I'm trying to target a 16 MB flash/32 MB ram board here :(

17:23 <Xogium> is there doc on how to properly use tinyconfig ? Or well, things to be watchful for when you enable subsystems so you don't get additional things in you hadn,t seen it toggled ?

17:23 <Xogium> or is it really that big just with what I set up ?

17:28 <Xogium> it's also my first time trying to build for such a small target

17:29 <Xogium> yeah, I know there are even smaller embedded devices around

17:30 <Xogium> I'm lucky it can access external storage I think ;) but from my understanding it would take 6 MB of memory to run this kernel, already

19:06 <Xogium> hmm. The only sort of guide for tinification I found used pictures and screenshots. Damn

19:06 <Xogium> sure not going to be that helpful when you don't see those