Hi Jose,
I'm dropping off the cc of "debian-cloud at l.d.o", because this is
really a kernel matter, so I see no reason for cross-posting. I can
post the outcome in there when we reach a solution.
On 1 February 2016 at 08:37, Jose R R <Jose.r.r@xxxxxxxxxxxxxx> wrote:
> Does the kernel boot after after you rebuild it with GZIP=y?
Yes it does. The only problem with this approach is the effort needed
to rebuild the package and keep it updated.
> The script is not without its issues, apparently, but you can modify
> xxx[1] in script if that is causing your hang.
>From what I understood in the reference, one should do this only if
the "mktemp" call fails. This doesn't looks to be related to the
problem I encountered.
> In Google Cloud Engine (GCE) I have not experienced those issues as I
> have created several images in Jessie and Stretch -- manually at the
> moment. They are Debian vanilla except for Reiser4 -patched kernel and
> root (/) Reiser4 -formatted.
You are rebuilding/recompiling the kernel packaging like I did? Or are
you talking about decompressing the kernel image? Because, as I said,
I had no problem with the first one. What I'm reporting here is solely
related to an uncompressed (or compressed with other method than XZ)
kernel.
> PS I have also found binwalk [2] useful when examining contents of
> compressed kernel
> apt-get install binwalk
Thanks for the tip - although I got a little bit surprised with so
many dependencies in what should be a simple command-line utility.
Here's what I got from "binwalk /boot/vmlinuz-3.16.0-4-amd64":
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Microsoft portable executable
18356 0x47B4 xz compressed data
3108600 0x2F6EF8 xz compressed data
Not sure about what bytes "0-18355" means. Maybe a false-positive?
If I run it with "-e", it get two files ("47B4.tar" and "2F6EF8.tar")
that can't be decompressed with "tar"/"unxz".
-
Ben,
On 1 February 2016 at 06:03, Tiago Ilieve <tiago.myhro@xxxxxxxxx> wrote:
> Yesterday, Ben Hutchings itself (...)
Sorry. It should be "himself". If it helps you to accept my apologies,
I have written that message at 6 AM after tackling this issue
overnight. :-(
Regards,
Tiago.
--
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
