How to edit initrd to fit your liveUSB - liveUSB preparation (openSUSE and others)
 

I am interested in the process of creating live linux USBs :) so I spent 2 hours playing with "multisystem usb creator" and two USBs to prepare a working openSUSE live USB. I prepared two USBs using the same input OenSUSE.iso and the same "tool" so I can have two "identical" USBs. If the content of USB1 is copied over onto USB2, USB2 will not boot, even though the USBs were supposed to be "identical" ;)
I swapped files between the two USBs, until testing proved, that initrds were USB-specific, and if the original initrd is used, the USB will boot. Most of the other files were really identical, anyway.
That is why I came to the conclusion, that every initrd prepared with a live USB creator is specific for the pendrive.
Please, confirm ;)
If initrd is vital for the USB booting, please, tell me how to unpack, which files to edit and repack initrd files, so the usb will boot( how the initrd is edited during live USB preparation.

Doesn't sound right to me. Did you copy the contents of the device as opposed to just a partition? You should be able to make an image on disk, and write that image to any USB that is large enough to hold it. Each of them should boot (or at least do what the original did). I do this routinely with SD flash cards that are use to boot embedded ARM CPUs.

--- rod.

It seems I am not clear enough. I am talking about simple copy/paste of files, MBRs and PBRs are created automatically.
I prepare two USBs. Both boot OK. I use the same iso file namely: OpenSUSE-KDE-x86.iso. I use this tool LiveUSB Multiboot here(I will explain why this one later in the post).
Lets call the two USBs USB1 and USB2. Both USBs have their own, unique initrd. If I replace initrd of USB1 (initrd1) with initrd of USB2 (initrd2), USB1 ( with initrd2) will boot, but will fire an error during the load process that RW system was not found.
Why do I do this - I want to finally install OpenSUSE to a logical partition on a USB. Ubuntu and Fedora will install correctly with with tools, provided by the distros, Unetbootin or LiVEUSB install. OpenSUSE will not. The tool provided will simply execute dd if=/open/suse/iso of=/dev/sdb. This is the way to install in under linux proposed by the developers.
If I dd the iso to a partition (of=/dev/sdb1) the partition will be corrupted.
So I decided to experiment - first find a tool that will create really bootable OpenSUSE. LiveUSB Multiboot is the only one that really worked without dd command. I got a USB with syslinux MBR and syslinux PBR which chainloads to GRUB2 and GRUB2 is used to boot the iso (openSUSE in that case).
After lots of tests I came to the conclusion that initrd is modified in the process of USB preparing (dumping the OpenSUSE.iso to the USB), and the resulting initrd is USB-specific.
I want to know how to reproduce the initrd preparing process so I can locate the OpenSUSE to a logical parition :)

Okay, one thing quickly jumps out at me:
This command will write an entire device (MBR, partition table, and all partitions) to the USB device. While you seem to call it an ISO image, it cannot be, as an ISO image contains only the ISO-9660 filesystem for a single partition. And this is consistent with the behavior you see when trying to write that to a partition.

You say 'OpenSUSE will not. The tool provided will simply execute dd if=/open/suse/iso of=/dev/sdb.' but don't say in what way this fails. In principle, I see nothing wrong with this approach. What about that does not work?

Your conclusion that initrd is 'modified' as part of an install process is probably close to correct. An initrd is simply a RAM disk image. It is likely that the files installed in the RAM disk image are specific to the distro, and the methods it uses to bootstrap itself. It may be composed in some way that reflects your hardware, in order to minimize its size or optimize it in other ways.

You can unroll the initrd, using cpio and gunzip, and poke around in its files. Doing this will allow you to compare the contents of each, even modifying them if required.

It is likely that the bootloader plays a role in the process, or that there is a kernel commandline built into the kernel that requires some accordant makeup of the initrd. It is not surprising that an initrd for one distro will fail when used with a kernel from another distro.

It sounds like what you need to do is use kparted to extract the components of the OpenSUSE image. That will give you access to its partitions, which you can then write to partitions of the USB drive.

--- rod.

When I prepare the USB that way and run boot-info-script, the script reports that the USB:
MBR
PBR
I meant the extension is .iso, obviously this is not a CD-image( as far as I get it)
I want to make a multi-boot multi-partition USB with various Linux distros, and place every disto into its own partition. dd will obviously destroy anything on the USB :) I want to place the distro on its own extended partition, but dd will only create MBR where PBR should be, and will destroy the partition. I even tried it, and, of course, it did not work.
The USB is meant to boot on every PC. I assume changes are made so the correct path to a file is specified. Since the only different thing is the USBs, I assume a reference to the UUID of the USB is made.( a HUGE assumption by me) This assumption I need to be confirmed ( or rejected) , and the location( the file into the initrd modified) to be specified.
This whole compare thing I wanted to escape. This way I found that initrd are the only difference. Anyway, a good compare software with GUI ( gtk is better, Ubuntu 11.10) could be recommended ;) I tried UltraCompare (commercial) but it hanged ;)
It is the same distro :), deployed on the USBs the same way, only the USB-s are different.
Thank you for your help :)

It turns I am right - the only difference between the to initrd files appears to be a gingle line of code, the uuid of the 2 different USBs. here is the output of the diff command between the two unpacked initrd-s
I will have to find way to correctly pack the damn thing, and if anything successful comes out of this, I will report.

Well, regardless of the filename extension, it IS a 'CD' image. It contains more than just a filesystem; it also has the partition table, MBR, and at least one partition with a filesystem.
You cannot write an image file containing a complete device image to a single partition. It isn't dd that is destroying anything. Storage devices are not interchangeable with partitions. The image that was created was not intended to be installed on a single partition.
I guess it depends whether the UUID of each USB device is defined somewhere on the USB device before or during the installation process. If the installer uses a UUID it finds already installed, then you can never transfer the image to another USB drive. If the the UUID of the USB disk is created by the installer, then you should be able to transfer the image. Otherwise, the image is tied to a specific USB device. The latter aproach seems broken, to me.

Seems improbable that any GUI exists to do all of these highly esoteric things. You need to unroll the initrd, modify the file containing the USD device's UUID reference, and roll the whole thing back up. Since the image contains the contents of a device, you will need to extract the filesystem components, and mount them on loop devices. You can do a little bit of disk image gymnastics with fdisk for help, or use kpartx. It might be possible to modify the initrd so that it is not tied to the UUID of the USB device. In order to tell, I think you will need to extract the file, and see how the reference is being used.
It may also be possible to modify the UUID of the USB device, so that it matches the UUID embedded in the initrd. That would seem to defeat the purpose of the UUID, but perhaps it doesn't matter.

--- rod.

I dont know anything on the topic of what is inside a (bootble) CD. Thank you.
I mean the same thing. Probably I could not express myself clearly.
The original initrd was never bound to a specific USB partition by a UUID. The original code into initrd is

...........

It is the "third-party" solution LiveUSB MultiBoot that modifies the initrd, and changes file /include(root of initrd) at line 3315:

ORIGINAL initrd

to

Changes are bold. This changes obviously provides that the correct media is searched.
It might be improbable, but it seems that LiveUSB MultiBoot does this exactly: it unpacks the initrd, edits some code so the initrd is USB bound. You see the changes the installer makes to initrd (/include).

I managed to solve my problem, though. This is what I did. The aim was to create a OpenSUSE bootable media, placed on a extended partition of a multi-boot , multi-partition USB, with every distro on its own partition
1. I used LiveUSB installer( under WIndows) to create a Live USB. This Live USB will not boot, though, since the intrd seaches for hybrid media, but this just an "ordinary" USB. I chose this installer, cos it keeps the original menu of the OpenSUSE media. You might not want to use the MultiUSB, but another one.
2. Choose a partition you want, on an USB you want and install syslinux on the partition. Extended partition is OK:
3. Copy all of the content of the of the dummyUSB to the partition of the MultiUSB. /dev/sdb11 in my case.
4 Get the partition UUID of the USB with
5. Unpack the initrd you have. One gets a dir full of text files. There is include file in the root dir. Line 3315 should be changed as described above. Use the UUID you got as a result for the partition you use for OpenSUSE.
6. Re-pack the initrd and replace the original one.
7. Use whatever method you like to chainload to this partition, I use Grub4DOS.
This method worked for me :) I hope this post helps someone :)