How to extract modern Ubuntu initramfs
Just to remember, there is an explanation here, from which the following directive can be taken:
(cpio -id; zcat | cpio -id) < /path/to/initrd.img
I encountered an intriguing issue recently after replacing my motherboard. Some block devices underwent a change in their order, causing /dev/sda to appear as /dev/sdy due to a modification in the PCI-e enumeration. This change, though seemingly insignificant, led to an unexpected consequence. Since the disk was subject to a specific mdadm filter, its altered…
As you can see in my previous posts, I have an NVidia card. It worked quite well while using XGL, but due to XGL’s memory consumption (it takes a lot of memory), I have decided to try for AIGLX, which is part of the X.org system. In my previous post you can see that (and…
To burn Dual-Layer (or Double-Layer, of you stick to the official name for DVD+R) medias, I use growisofs. The syntax is as follow: growisofs -dvd-compat -use-the-force-luke=break:1913760 -Z /dev/scd0=file.iso Change the break blocks to match your own values, and replace the file.iso with the actual name of your ISO file. If you do not set layer…
This post is for the users of the great dm-multipath system in Linux, who encounter a major availability problem when attempting a resize of mpath devices (and their partitions), and find themselves scheduling a reboot. This documented is based on a document created by IBM called “Hot Resize Multipath Storage Volume on Linux with SVC”,…
I have uploaded a replacement wvdial.conf for the cellular entry below. Notice that for Cellcom in Israel, you need an init string AT+CGDCONT=1,”IP”,”internetg” . which is embedded into the file. For other cellular providers, you might need a different string. For Cellcom users out there – this is the right init string. If you are on…
We have one connection via ATM like interface and we have one PPP connection via xDSL (described here), and we want load balancing for this whole party. Following this specific part of lartc.org guide, we’ve managed to get this to work. The idea goes like this (Centos 4.3): 1. Do not state default route for…
This site uses Akismet to reduce spam. Learn how your comment data is processed.
I am working on Lubuntu 22.04, and either the lubuntu team creates the ramdisk differently, or the command is now out of date.
This works for me:
(cpio -id; cpio -id; zstdcat | cpio -id) < /path/to/initrd.img The ramdisk I am working with now has 2x uncompressed CPIO archives, prepending a "Z Standard" compressed main ramdisk.
They can modify it, however – how? Can you run the command ‘file’ on the initrd file? Or ‘lsinitrd’? It will give you a lot of details and insights.
In any case, on Ubuntu 22.0.4 my command works, and there is no reason to assume that this mechanism has changed. Just to be clear – your command failed on my test with the following output:
cpio: Malformed number
and
cpio: premature end of archive
Hi etzion, while I was initially confused by your response, I think I understand where the difference comes from. With my initrd I have 3 CPIO archives, the first 2 being microcode for AMD and Intel CPUs respectively – they each have their own CPIO archive. Then the third archive is the main initial ramdisk, encrypted Z standard encryption.
My ramdisk comes from the Lubuntu ISO. It is the ramdisk used to load the live environment. I assume the ramdisk you are using is for Ubuntu, installed on your computer? It would make sense to me that they would drop one of the first two microcode ramdisks, depending on what is applicable to the machine’s processor.
Thanks for your response, by the way you have some great info on your website. Thanks for what you do!
I understand. You were using the special LiveCD initrd. On systems which are on-disk, the initrd is created per the hardware configuration and layout of the system. Your note is good and important – and it exposes a structure including both microcodes as the same time, for both types of CPUs. When the system is installed on disk, it will integrate only the CPIO image for the relevant microcode. Makes a lot of sense.
I really appreciate the feedback. I have been collecting and sharing (and using it as an extended memory) for a long while. Some of it is still relevant even today 🙂
Thanks!