Is there a way to prepend a CPIO archive file to an Gzip archive file?

The following is a quotation from another post:


Yes iucode_tool and intel-microcode are what you need.

(1) build and install iucode_tool from SBo

(2) build and install intel-microcode from SBo, this creates a file /boot/intel-ucode.cpio

(3) If you do not use an initrd at the moment, use /boot/intel-ucode.cpio as your initrd -- for example, with lilo you will have to modify /etc/lilo.conf and then re-run /sbin/lilo, or with elilo you will have to edit /boot/efi/EFI/Slackware/elilo.conf and copy /boot/intel-ucode.cpio to /boot/efi/EFI/Slackware/

(4) If you do use an initrd (presumably /boot/initrd.gz) do this:

Code:
cp /boot/initrd.gz /tmp
cat /boot/intel-ucode.cpio /tmp/initrd.gz > /boot/initrd.gz
[/B]
and then (important) re-run /sbin/lilo, or copy the new /boot/initrd.gz to /boot/efi/EFI/Slackware, or do whatever your own boot loader wants. And you will have to repeat this after every time you run mkinitrd.

I wonder, if someone added support to mkinitrd for /boot/intel-ucode.cpio and sent a patch to volkerdi, would that be welcomed?
_______________

I copied the above lines from a post ([SOLVED] Broken HyperThreading in SkyLake and Kaby Lake Processors), on a reply to it by senior member 55020.

The problem does not affect me because I have an older system: core i5-2500K @3.30 with an Asus P8Z77-V LX motherboard. I am using Slackware64 14.2 with linux 4.4.38 and GNU coreutils 8.25. Normally I use the the vmlinuz-generic kernel with initrd. Nevertheless it seems a good thing to keep track of potential flaws and been able to fix them. Asus no longer issues upgrades for the bios (last one I got was from 1915, probably earlier). The last microcode for the processor was issue 20150121; although according to the intel website 201705 applies to all intel processors.

The above recommendation does as it pertain to kernel huge but not with generic+intitrd.

The problem seems that it is not possible to use 'cat' to prepend intel-ucode-cpio (a CPIO archive) to the inird.gz (a Gzipped CPIO archive), instead cat override initrd (the compressed CPIO archive).

The result is that with vmlinuz-generic-4.438 the system hangs. If I want to use the microcode I have to revert to using a huge kernel.

So my question is: Is there a way to prepend a CPIO archive file to an Gzip archive file?

Just out of curiosity, would the following work for you?

cat /boot/intel-ucode.cpio | gzip > /boot/initrd.gz

then run lilo.

The goods only know why we should stuck in a specific name of initrd...

PS. When you merge two initrd, both should be the same, compressed or not.

Far from expert, but think that upgrade of BIOS is needed for microcode updates to work properly.

The kernel knows exactly what to do with an uncompressed cpio followed by a compressed cpio in one file. See https://www.kernel.org/doc/Documenta...-microcode.txt

What I posted works for me, and works for multiple other people. It's probable your initrd and/or intel-ucode.cpio and/or bootloader config is broken some other way.

If I was you, I would start again with mkinitrd. Verify the contents of intel-ucode.cpio. Be sure to copy the initrd.gz somewhere else, because 'cat a b >b' won't work. And be sure to update your bootloader before you reboot.

2 members found this post helpful.

BTW, maybe the system hang is similar with my (not so fun) adventures on Slackware 14.2, where its graphics stack, who know? from kernel to whatever GL crap, well... something hate with passion my unlucky hardware. SIX computers in line.

Usually I call that naughty behavior: "it freeze", but also "it hang" is a good word to describe the phenomena.

IF that OP's computer is not on critical duty, I suggest using/upgrading to Slackware-current, which acts like a nice pal, at least on my hardware.

Roberto Alvarez --

55020's instructions worked perfectly for me this morning on two different kernels.

But one thing not explicitly stated in 55020's original instructions is that you've got to first create an initrd.gz file as you've always done for your kernel.

Once you've got a /boot/initrd.gz file for your new kernel, proceed:

substitute the `basename` of your initrd.gz as required ...

edit /etc/lilo.conf with the new /boot/initrd.gz file ; run lilo and reboot.

HTH.

-- kjh

I thank all the replies for their attention and help, but the question still stands--How do we prepend a type of archive to another type of archive?

My understanding is that cat is used to concatenate 'files' not archives or directory trees. Sorry I don't think my system is broken.

I do use a generic kernel with an initrd and elilo for boot loader. My understanding so far is that in order to modify the system initialization one modifies the /boot/initrd-tree, then run mkinitrd in order to sync the tree with the contents of the initrd file, and then, in my case run eliloconfig.

The problem that the alteration of this file (initrd.gz) poses is that the content is organize as a directory tree which by the way is organize in alphabetical order. In it a directory 'kernel' would follow a dirictory 'bin'.

In our case the folder 'kernel' has to precede the folder 'bin',within the tree, for the early application of the microcode.

The name 'kernel' in the intel-ucode.cpio file is relevant, so are the names of the folders inside the initrd-tree, unlike the name of the initrd which is define in whatever configuration/initialization file as needed by the particular boot loader.

I have tried many things today in order to circumvent this problem with no success. I tried using cat, gzip, KDE's arc. I tried manually adding the contents of the intel-ucode.cpio and altering the top folder's name by prepending an 'a' to its name--the boot loader ignores the file.
I will continue looking, perhaps their is a configuration file or a means of aliasing to force the presedence of the microcode to the booting process.

Thankyou again and excuse the lateness (and the length) of my response.

Hello,

In case of trouble with a cpio+initrd archive, you can check its content as in example below :

1. Extract the cpio archive

2. Extract the gzip archive which is, in the example above 1922 blocks after the cpio archive.

--
SeB

Roberto, your understanding here is correct, cat indeed simply concatenates files. In general this won't do any good for compressed archives, but in this case the kernel code is designed to handle such concatenated initrd file.

If you have read the link provided by 55020 carefully, you have noticed the following:
And the last line of provided example script:
Please note that the output filename differs from original initrd filename. As others have already noted, this is a very likely place you have made a mistake.

Technically, you can't really prepend to a file, you have to append the second thing to the first. cat concatenates things in the order given.

If you have read the link provided by 55020 carefully, you have noticed the following:
Quote:
The format of the combined initrd image is microcode in cpio format followed by the initrd image (maybe compressed). Kernel parses the combined initrd image during boot time.
And the last line of provided example script:

Code:
cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img

Please note that the output filename differs from original initrd filename. As others have already noted, this is a very likely place you have made a mistake.
__________________
Audrius Kažukauskas

neither initrd.gz nor intel-ucode.cpio are raw disk data. They are differen archives. Perhaps in some distribution (other than Slackware), that is the case.

In inspecting a flash memmory stick that I use for installing Slackware, I found an image,

bash-4.3$ cd /run/media/roberto/SlackDVD/EFI/BOOT
bash-4.3$ ls -l initrd.img
-rw-r--r-- 1 roberto roberto 39424516 Jun 24 2016 initrd.img
bash-4.3$

which is a raw data disk. I will not tweak with things I do not understand.
But this I know cat will not concatenate the contents of a CPIO archive with a compress Gzip file; and if you pipe it to a new file, it simply will write the contents of the CPIO file into it. Might as well use mv.!

Roberto Alvarez

Roberto Alvarez --

The cat command will concatenate one-or-more 'source' files of any type to stdout.

The cat command know nothing about the content of the source files -- it simply spits the bits from each file to stdout in the order you specify

Like most of the good old UNIX commands, they do exactly what you tell them to do -- even if it makes no sense.

There is no guarantee that the results of a cat command will be useful for any purpose.

However, in the case of the intel-ucode.cpio + initrd.gz source files, as 55020 alread said, the Kernel understands that particular concatenation and it will do 'the right thing' with it.

man cat

One common gotcha with cat ( actually a gotcha with the shell ) is to redirect output into one of your source files.

For example this will not work as one might imagine: That's because the shell truncates the target file ( foo ) before it begins the cat operation so when cat 'sees' foo, foo has been truncated

! dooh ! been there, done that !!

HTH.

-- kjh

1 members found this post helpful.

kjh
Indeed, this is what happens in my case. If you have actually concatanated heterogeneous files with cat and gotten something different, please let me know. It might be that the instance of the program I have is defective or something.

During reboot the system froze and a message of something like kernel panic and not sysncing, is the same that happens when you forget to update the initrd.gz file or to run mkinitrd.

I tried, in a mock directory many combinations of files processed through cat: gzip-img gzip-cpio cpio-img in different order and in all instances got incomplete files with the content of the first readable and the rest loss, although in some cases the math of adding the single files to the combined, match. Also when the resuling file was aknowledge as gzip, the compression ratio % revealed with gzip -l was often exhorbitant (in the order of 700 and up) and in some cases negative.

About the question of presedence, I read it first from someone who uses Syslinux in his machine. I have never used this bootloader but I am contemplating trying it.

It has a very pertinent feature: it accepts multiple files in the initrd= directive and it executes them in the order given.