On Mon, Feb 1, 2016 at 12:03 AM, Tiago Ilieve <tiago.myhro@xxxxxxxxx> wrote: > Hi, > > I have a scenario[1] where the default Linux kernel compressed with XZ > (from Jessie and up) cannot be booted. The first thing that I've tried > was to uncompress it using "extract-linux"[2] and it didn't worked by > the time, so I decided to rebuild the entire "linux-image-*" package > changing "CONFIG_KERNEL_XZ=y" to "CONFIG_KERNEL_GZIP=y". This, of > course, implies that it would be needed to recompile the kernel every > time a new version of the package is released, which is an overkill > for a such simple requirement. Does the kernel boot after after you rebuild it with GZIP=y? > > Yesterday, Ben Hutchings itself suggested[3] me to write a hook that > decompresses the kernel at package installation time, something which > I find a great idea. The problem is that, again, I couldn't boot a > machine (tried on VirtualBox and Xen) after uncompressing its > "/boot/vmlinuz-*" using "extract-linux". The script is not without its issues, apparently, but you can modify xxx[1] in script if that is causing your hang. > I can generate an initrd file > from this uncompressed image, "update-grub" detects it fine, but if I > reboot it the following error appears: > > Loading Linux 3.16.0-4-amd64 ... > error: invalid magic number. > Loading initial ramdisk ... > error: you need to load the kernel first. > > The same error happens if this uncompressed image is compressed again > with "gzip", for instance. > > Given this situation, I have two questions: > > - If a kernel is configured to be compressed at build time, it can't > be booted if uncompressed later? I have some doubts about this, > because there is more than one report of successfully booting > uncompressed kernels[4][5]. > - Is "extract-linux" stripping some essential information (the script > looks for an offset to start the decompression process) from the > kernel image that is needed to boot it later? If so, is there a way to > recover and insert it on the uncompressed image? 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. Best Professional Regards. PS I have also found binwalk [2] useful when examining contents of compressed kernel apt-get install binwalk Was not aware that Oracle had such an outdated cloud infrastructure ;-) [1] http://stackoverflow.com/questions/12002315/extract-vmlinux-from-vmlinuz-or-bzimage [2] http://unix.stackexchange.com/questions/163346/why-is-it-that-my-initrd-only-has-one-directory-namely-kernel -- Jose R R http://metztli.it --------------------------------------------------------------------------------------------- Try at no charge http://b2evolution.net for http://OpenShift.com PaaS --------------------------------------------------------------------------------------------- from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way! --------------------------------------------------------------------------------------------- -- 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