Enabling GZIP compression support in initrd for x220

[spacekookie]

Without this option set by default, images built for
the x220 will kernel panic shortly after boot, failing
to unpack their initrd.

[BlackMaria]

Sorry if I am adding noise, I lost track of this thread. @SebastianMcMillan was looking at an issue where after a power up, the x220 would take 60 seconds before displaying anything. @spacekookie Have you waited 60+ seconds, or do you actually see a segfault or like?

Sebastian perhaps this is a/the regression merged earlier causing the 60 second delay?
Danke

PS your issue refers to the x220 but the diff is for the x230 ( perhaps I am misunderstanding? )

[spacekookie]

On July 22, 2019 10:28:56 AM UTC, "Hroðgar Skjöldung" ***@***.***> wrote: Sorry if I am adding noise, I lost track of [this thread](#539). @SebastianMcMillan was looking at an issue where after a power up, the x220 would take 60 seconds before displaying anything. @spacekookie Have you waited 60+ seconds, or do you actually see a segfault or like? Sebastian perhaps this is a/the defect merged earlier causing the 60 second delay? Danke PS your issue refers to the x220 but the diff is for the x230 ( perhaps I am misunderstanding? )

Both! It's taking like 60 seconds to display something, then there's a kernel panic. I ended up replacing "quiet" with "panic=30" in the Linux command. Ultimately, that issue went away when enabling gzip compression

[paulmenzel]

I prefer imperative mood in the commit message:

Enable GZIP compression support in initrd for x220

Do you know, how that regression was introduced? The Linux kernel has not been updated for a long time, so the default for that Kconfig symbol should not have been changed.

Also, I thought, that XZ compression is used by default for Heads for smaller images.

[snmcmillan]

I'll have to test these changes as well, but this delay is confirmed to be either a TPM issue or a ME issue, as the delay takes place long before we get to loading the kernel.

Another thing is that X220 isn't panicking on my end without the gzip.

[BlackMaria]

@SebastianMcMillan Sorry, I seem to have confounded the issue with what you were working on.
FWIW I dont have the gzip issue on my end either ( but haven't built from master for about a month )

[snmcmillan]

Just rebased my build on my changes with an up-to-date master, do not have this problem.

[spacekookie]

@SebastianMcMillan That's strange. The commit I was using to build my images was 20d79f5, which resulted in unbootable images.

[spacekookie]

@paulmenzel I updated the commit description. Also, yea I was under the impression that kernel images should be using XZ compression as well. At least that's the feeling one could get from the configs.

The build command I used wasn't customised in anyway, just make BOARD=x220, so not sure what might be going on there 🤷‍♀️

[tlaurion]

@spacekookie @BlackMaria @SebastianMcMillan
Please
make BOARD=x220 real.clean && rm -rf crossgcc build/*/

And report issues in good tickets, including this one. Heads doesn't redownload, doesn't reapply patches, doesn't recompile everything at each builds, so your states are obviously different and you all have nothing to compare against.

A good advice until we have working CIs would be to give a commit ID and the sha256sum hash given for a specific build tested, so you know you are talking about the same built rom. Otherwise, you are all testing different roms.

@spacekookie I confirm xz is supposed to be used. You should't have a kernel panic because of gzip not being available.

Please close if issue not relevant anymore.

[tlaurion]

Is it still relevant @spacekookie?

[tlaurion]

Ping @spacekookie.
If the issue is still relevant after building with clean environment, please reopen.

cd heads
git fetch
git pull
make BOARD=x220 real.clean && rm -rf crossgcc build/*/