Database Info

[HOWTO] porting a ROM for old radio to work with new radio

I would love to help the community by using your kernel for the newer radios to port any roms for the older radio... is there any help you can give me? should i use your boot.img from the test-donut.img/test-eclair.img?
Click to expand...
Click to collapse
first, a thing we must know for porting job is what boot.img included.
here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
the ramdisk do some initializing jobs, so if we port a ROM, we should ensure that the content in ramdisk and files which are included in ramdisk (like init.rc), have necessary things the ROM needed.
for the first step, we can just extract the boot.img from the ROM, and extract the ramdisk from the boot.img which extracted just now, then repack it with my kernel (you can extract the kernel from my boot.img with same tools).
(to execute the perl script in link above, you need linux or just cygwin. )
but if we are sure that the ROM we want to port have nothing special with ramdisk, just like common ROMs, we can use my boot.img files directly. for eclair ROM, I suggest you extract the boot.img from my ROM, and don't use the first boot.img (test-NOCDB.img) I had posted.
after this, make our update.zip (use other's ROM as an example, especially the update-script in META-INF directory). sign our zip with testkey and apply it, then we can make our phone booting into desktop.
(you can find information about sign and download tools here: http://forum.xda-developers.com/showthread.php?t=471586, though the thread is not talk about how to sign things)
the main troubles we may meet probably are symlinks and setperm* in the update-script. if there is already a file/link has a name we want to symlink to, or if there isn't a file we want to symlink from or setperm, we will fail. so check the files carefully.
the next step is make everything work properly. we can use file from a ROM which made for new radio (and work well of course) to replace the one in the ROM we are porting. we can find these files in my 2.x ROM for eclair, or other's 1.6 ROM for donut (and for new radio, since the maker of them tested them already).
the most important files are (to my knowledge):
system/lib/libhtc_acoustic.so
system/lib/libhtc_ril.so (if something wrong with mobile network)
system/lib/libcamera.so
system/lib/libcameraservice.so
system/lib/liboemcamera.so (for 2.x) or system/lib/libqcamera.so (for 1.6)
system/lib/libgps.so
system/bin/akmd
(are there something I missed?)
(if we want to use NCommander's work on CameraHardwareInterface with a 2.x ROM, we should use my kernel for DONUT instead. I didn't try it, and I don't recommend it.)
these files are some thing work with hardware partially, so different radio may need different files. but if something just work fine, don't hurry to replace the file for it.
and now...., I don't have more thing to talk about, since we have most things work well. but for further tweaks, there are lots of things to do.
everyone can post your question here. if I know the answer I will post it. if I don't or I am not online, I think others will response you. and if there are things I missed or made some mistake, plz point it out
I will update this post when we collection more info or correct something. I find that I don't organized everything in order . I will update it later.

Thanks for the post... what's the difference between your eclair/donut kernel? (This is based on your original post about your kernel... is there an updated kernel somewhere i should know about?)
Edit
Nevermind i figured it out by reading your post more. carefully thanks for the detailed instructions

Thank you very much for this sanpei. This is the type of posts that really should be on this forum
Appreciated so much. waiting for your next updates.

Phil_McRevis said:
Nevermind i figured it out by reading your post more. carefully thanks for the detailed instructions
Click to expand...
Click to collapse
sorry for my poor ability of expression
asero said:
This is the type of posts that really should be on this forum
Click to expand...
Click to collapse
I expect more people can share their knowledge, and we can make a wiki for all

Hello!
I have to edit some lines of init.rc of your kernel. I've thus extracted the ramdisk, edited the file, repacked and tried booting with fastboot boot kernel-img ramdisk-img, but the phone hangs on the operator logo. I've tried even just extracting kernel+ramdisk and boot them - same result (the boot.img works well).
how can I fix it? Thanks

Wrong post

[help]anybody can tell me how to convert official ROM to update.zip

anybody can tell me how to convert official ROM to update.zip
I want to know how to make an official from the ROM can customize the ROM, instead of only at others do the update.zip in thickening delete...

First, you need to run the RUU.
Check in your system TEMP folder, and you should have an update.zip there.
Unzip that, and you'll have amongst others, system.img
Extract the files via unyaffs or other means, customize your build, zip and sign.
Voila.
My guess is that a simple search via the search tool would've resolved that, then again, I guess you were too lazy to do that.

adwinp said:
First, you need to run the RUU.
Check in your system TEMP folder, and you should have an update.zip there.
Unzip that, and you'll have amongst others, system.img
Extract the files via unyaffs or other means, customize your build, zip and sign.
Voila.
My guess is that a simple search via the search tool would've resolved that, then again, I guess you were too lazy to do that.
Click to expand...
Click to collapse
I have get the system.img, but I don't know what tools and methods reduction system.img to update.zip file format,can replace programs self.
Can you explain it step by step?

He actually told you in the post above to use unyaffs, all you need to know is already in this forum if you search for it. Here's a thread to get you started:
http://forum.xda-developers.com/showthread.php?t=566235

thanks , i went to see

Batch Flasher (splash, radio, and boots into bootloader/recovery)

Hi guys, don't know if I'm posting in the right section or not, if not move it please, I'm still fairly new here.
Thought I would share a tool of mine that I created for my own use.
It'd a DOS batch file that I use to reboot my phone into bootloader, reboot it into recovery, or to create and flash various splash images.
As of 22/05/2011 code was added to flash RADIO.IMG files to your phone.
I did some work extending it so its a bit more user friendly, and contains various explanations, options etc.
Like i say, its just a tool I created for my own use, but I figure you might get some use out of it, or you can use it to build your own custom boot loady thing.
included in the zip is adb.exe, nbimg.exe, fastboot.exe and the adb dll files, so that everything you need is contained in the same folder. There is a read me file that also points out a few features.
Enjoy

Downloaded,thanks mate....
SENT FROM HONEYSENSE

Boskoel03 said:
Downloaded,thanks mate....
SENT FROM HONEYSENSE
Click to expand...
Click to collapse
Apologies, going over the code and realized I forgot to remove the lines linking to my default Android directory (which it doesn't need, since its all self-contained now).
Have re-uploaded the ZIP but if you edit the batch file just remove the lines "cd c:\android" and your good to go.

[Q] Is there any APK to exact the boot.img in the phone

I want to unpack the img but don't want to use in my pc(too confused).
so I want to unpack by the phone,
thank you

ytyyutianyun said:
I want to unpack the img but don't want to use in my pc(too confused).
so I want to unpack by the phone,
thank you
Click to expand...
Click to collapse
I don't think there is. Maybe I'm wrong too.
Basically all these boot.img tools are written in shell/bash and is made specifically to run in Linux distros.
Anyways there is an Android app called, Complete Linux Installer that lets you install any Linux OS in your phone. But I doubt whether boot.img tools work, as it needs various library files for it to work.
On a side note, I guess it would be more complex to do it in phone rather than in PC, if there is some way for it to work.

coolsandie said:
I don't think there is. Maybe I'm wrong too.
Basically all these boot.img tools are written in shell/bash and is made specifically to run in Linux distros.
Anyways there is an Android app called, Complete Linux Installer that lets you install any Linux OS in your phone. But I doubt whether boot.img tools work, as it needs various library files for it to work.
On a side note, I guess it would be more complex to do it in phone rather than in PC, if there is some way for it to work.
Click to expand...
Click to collapse
Thank you for your reply, but do you feel strange that the IMG is created by the recovery, so it is rational that there is a tool about IMG building. then why there is no apk. I mean some professional can extract just from the CWM recovery, I think.

need root
if you wanna get boot.img i think you must be rooted.

k0tsompakos said:
if you wanna get boot.img i think you must be rooted.
Click to expand...
Click to collapse
yes, I root, so I can use the recovery to back and restore,

I think any app that can access zip files in the internal and external memory can extract boot.img.
Like ASTRO File Manager and stuff...

recovery?
You wanna install a rom?
or recovery??
or we speak about boot.img? (Boot img is the boot animation when you turn on your phone.)

k0tsompakos said:
You wanna install a rom?
or recovery??
or we speak about boot.img? (Boot img is the boot animation when you turn on your phone.)
Click to expand...
Click to collapse
Nooooo
boot.img is the kernel (zImage + Ramdisk packed into an image file) that lies in the /boot partition
@ OP - If you want to extract boot.img itself, there are various methods and from CWM recovery like you said. I thought you were mentioning about how to unpack the contents of the boot.img say like zImage, Ramdisk and other files.

0ops
0ops yeah... :silly:
Searching for 1 minute and found this tool :good:
--> [TOOL] Boot.img tools [unpack, repack, ramdisk] <--
( I do not send link cause i am new here and can't :angel: )
It works. Have a nice day

k0tsompakos said:
0ops yeah... :silly:
Searching for 1 minute and found this tool :good:
--> [TOOL] Boot.img tools [unpack, repack, ramdisk] <--
( I do not send link cause i am new here and can't :angel: )
It works. Have a nice day
Click to expand...
Click to collapse
Yes, that's the tool and it works :good:
But as OP mentioned, he wanted to do it within phone, I highly doubt though.

coolsandie said:
Yes, that's the tool and it works :good:
But as OP mentioned, he wanted to do it within phone, I highly doubt though.
Click to expand...
Click to collapse
It could be done using this post http://forum.xda-developers.com/showpost.php?p=20227868&postcount=1124 and a hex editor from play store on your phone. But would be even more fiddly than on pc I would imagine, unless your phone has a largish screen. It could be done though.
If editing the ramdisk, you would need to unpack and repack after editing, which usually requires linux. I recently found http://forum.xda-developers.com/showthread.php?t=2036528 for PC, but have not had a chance to try it yet, seems best solution for OP

coolsandie said:
Yes, that's the tool and it works :good:
But as OP mentioned, he wanted to do it within phone, I highly doubt though.
Click to expand...
Click to collapse
thank you coolsandie, the android is based on linux, isn't it, and if I can, I can install busybox.and using the terminal like Android Terminal Emulator, but I do not know the procedure. like you, it's more complex,

Robbie P said:
It could be done using this post http://forum.xda-developers.com/showpost.php?p=20227868&postcount=1124 and a hex editor from play store on your phone. But would be even more fiddly than on pc I would imagine, unless your phone has a largish screen. It could be done though.
If editing the ramdisk, you would need to unpack and repack after editing, which usually requires linux. I recently found http://forum.xda-developers.com/showthread.php?t=2036528 for PC, but have not had a chance to try it yet, seems best solution for OP
Click to expand...
Click to collapse
it's good tool, it can unpack the boot.img, but as to the kernel, I don't know how to unpack. but this tool add to my favorite, thanks Robbie.

OK, I find the app, names: yaffs, the author I don't know because I found in the search engine. so I also cannot find the course
then the app,

[Q] Boot.img?

Sooo yeah.... anybody got some help for this one? I have searched google and the forums but can't clearly figure this out, but how do I get a Boot.img for this phone??? I have rebuilt the kernel 3 or 4 different ways and the output never yeilds one, however I apparently NEED one so I can peel away the ramdisk x( any ideas?
EDIT: Okay, so now that I can compile a working stock kernel for the Sidekick, where should I start now? I know we already have a working voodoo lagfix kernel, but I want to make CWM for the stock kernel, that sounds like a good spot. And adding in init.d sounds like another good start. Making my own may help me in understanding it all. I AM taking notes too

Zydrate_blue said:
Sooo yeah.... anybody got some help for this one? I have searched google and the forums but can't clearly figure this out, but how do I get a Boot.img for this phone??? I have rebuilt the kernel 3 or 4 different ways and the output never yeilds one, however I apparently NEED one so I can peel away the ramdisk x( any ideas?
Click to expand...
Click to collapse
If I recall correctly, I used the split_bootimg.pl script, and accompanying instructions, found here:
http://www.android-dls.com/wiki/?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
Start by unpacking and repacking a kernel that you already know is functional -- i.e. a copy of a kernel you have already successfully flashed. Once that repack can be flashed successfully, you can move on to making modifications to it, or packing a whole new initramfs and kernel.
I had to remove references to a few of Samsung's proprietary modules to get the kernel to build -- Samsung helpfully supplies the places for those sources to be put (IN TREE -- shame on you Samsung), but not the sources themselves. One such module was rfs, IIRC. I removed the Makefile references so I could finish a compile, then used copies of the compiled modules from an existing initrd. Where you run into compile failures, where the source code appears to be simply missing, this is probably the cause.
I found that I had to manually strip at least the modules that resulted when I built from sources, otherwise the finished image was far too large. Compare the sizes of your compiled kernel and module files to those of a known-working reference image. They should not be too far out of line.
I wish I had saved more notes from my own kernel builds. Regular Linux kernels are so easy, but earlier Android kernels are unnecessarily horrible to build. Still, if you run into any more issues, I'll try to help...
Oh, and please disable the keystroke logger!

nxd said:
If I recall correctly, I used the split_bootimg.pl script, and accompanying instructions, found here:
http://www.android-dls.com/wiki/?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
Start by unpacking and repacking a kernel that you already know is functional -- i.e. a copy of a kernel you have already successfully flashed. Once that repack can be flashed successfully, you can move on to making modifications to it, or packing a whole new initramfs and kernel.
I had to remove references to a few of Samsung's proprietary modules to get the kernel to build -- Samsung helpfully supplies the places for those sources to be put (IN TREE -- shame on you Samsung), but not the sources themselves. One such module was rfs, IIRC. I removed the Makefile references so I could finish a compile, then used copies of the compiled modules from an existing initrd. Where you run into compile failures, where the source code appears to be simply missing, this is probably the cause.
I found that I had to manually strip at least the modules that resulted when I built from sources, otherwise the finished image was far too large. Compare the sizes of your compiled kernel and module files to those of a known-working reference image. They should not be too far out of line.
I wish I had saved more notes from my own kernel builds. Regular Linux kernels are so easy, but earlier Android kernels are unnecessarily horrible to build. Still, if you run into any more issues, I'll try to help...
Oh, and please disable the keystroke logger!
Click to expand...
Click to collapse
Wow thanks nxd! I don't know if you have seen my other posts, but I'm a newbie at this stuff. Never too late to learn though right?
Now, as for the issues in the build, when I first tried to compile I was getting errors of an undeclared SEGMENT_SIZE in binfmt_aout.c so I searched around and was informed that the aout method is outdated? So I removed it from the config as instructed, seeing as it wasn't needed.
I've gotten to a compile resulting in the zImage and about 8 modules created. Now, the zImage is incomplete at this point if I am correct? If it's flashed, it will simply bootloop. (Because there is more to be done? i.e the ramdisk gz that loads the rom at the bootloader?)
Also, I will check the link about the logger, so I can disable it.
I appreciate all your help I really want to get this stuff down-pat eventually.

Zydrate_blue said:
I've gotten to a compile resulting in the zImage and about 8 modules created. Now, the zImage is incomplete at this point if I am correct? If it's flashed, it will simply bootloop. (Because there is more to be done? i.e the ramdisk gz that loads the rom at the bootloader?)
Click to expand...
Click to collapse
Correct, you need to put the modules onto an initramfs, and then assemble the zImage and initramfs into a boot.img. The URL I posted has instructions to both unpack and repack. I suggest that you obtain repack settings (command line, perhaps memory addressing) from an existing working image.
You can probably use the initramfs from an existing image as the basis for your new boot.img as well, replacing the modules from the old imitramfs with your new modules.

nxd said:
Correct, you need to put the modules onto an initramfs, and then assemble the zImage and initramfs into a boot.img. The URL I posted has instructions to both unpack and repack. I suggest that you obtain repack settings (command line, perhaps memory addressing) from an existing working image.
You can probably use the initramfs from an existing image as the basis for your new boot.img as well, replacing the modules from the old imitramfs with your new modules.
Click to expand...
Click to collapse
I hate to ask this because I'm afraid of being a pain in the a**.... but I hope you won't mind working with me, I'm in for the long run. Anyway, am I supposed to have a initramfs after the compile somewhere within the source? Or is this something I acquire from an an outside source? I promise I have done like 30-40 searches before hand. I have a feeling am missing something obvious -_-
Again, thank you for your generous help

Zydrate_blue said:
I hate to ask this because I'm afraid of being a pain in the a**.... but I hope you won't mind working with me, I'm in for the long run. Anyway, am I supposed to have a initramfs after the compile somewhere within the source? Or is this something I acquire from an an outside source? I promise I have done like 30-40 searches before hand. I have a feeling am missing something obvious -_-
Again, thank you for your generous help
Click to expand...
Click to collapse
The kernel compile will NOT produce an initramfs for you. It will produce the zImage (compressed kernel image) and modules.
The initramfs is an archive containing some files. During boot, when the kernel reaches the end of device initialization, it then creates an empty memory-backed filesystem, and extracts the initramfs contents into that new filesystem.
Ideally the initramfs would be generated by the Android build system, using the binaries produced by the kernel compile. But Samsung provides the bare minimum for GPL compliance, and so we don't get all the pieces we'd need for that. Presumably assembling those pieces is a big part of what windxixi has done, however.
When I worked up my boot.img, I used someone else's existing initramfs, dropped in my compiled modules and a few other minor changes, and then re-assembled it with my compiled zImage. If you're already working with windxixi's build kit and kernel sources, it might save you some time to use his initramfs as a basis for your own.
Really, once you've unpacked basically any SK4G boot.img, and extracted the files from the initramfs, I think you'll see the layout and that aspect the process will be clearer to you.

nxd said:
The kernel compile will NOT produce an initramfs for you. It will produce the zImage (compressed kernel image) and modules.
The initramfs is an archive containing some files. During boot, when the kernel reaches the end of device initialization, it then creates an empty memory-backed filesystem, and extracts the initramfs contents into that new filesystem.
Ideally the initramfs would be generated by the Android build system, using the binaries produced by the kernel compile. But Samsung provides the bare minimum for GPL compliance, and so we don't get all the pieces we'd need for that. Presumably assembling those pieces is a big part of what windxixi has done, however.
When I worked up my boot.img, I used someone else's existing initramfs, dropped in my compiled modules and a few other minor changes, and then re-assembled it with my compiled zImage. If you're already working with windxixi's build kit and kernel sources, it might save you some time to use his initramfs as a basis for your own.
Really, once you've unpacked basically any SK4G boot.img, and extracted the files from the initramfs, I think you'll see the layout and that aspect the process will be clearer to you.
Click to expand...
Click to collapse
I haven't found any boot.img from another kernel, however I have finally figured out how to unpack the zImage D I think I'm a bit closer now, however, now I need to figure out how to un-cpio the initramfs.cpio and/or use the intramfs folder I now have. (in the unpacked zImage)
Then the next step I suppose would be learning how to incorporate the modules that I have. hmm..

Zydrate_blue said:
I haven't found any boot.img from another kernel, however I have finally figured out how to unpack the zImage D I think I'm a bit closer now, however, now I need to figure out how to un-cpio the initramfs.cpio and/or use the intramfs folder I now have. (in the unpacked zImage)
Then the next step I suppose would be learning how to incorporate the modules that I have. hmm..
Click to expand...
Click to collapse
On the page I linked to in my first reply, under "Alternative Method", those instructions worked for me to split, unpack, repack, and assemble. Did they not work for you?
Regarding how to incorporate the modules, you would copy them into the extracted directory in the same locations in the initramfs as the existing module files. Generally something like /lib/modules. Look for files ending in '.ko'. They may be spread out a bit in your compiled kernel sources, but they should all be in one directory in your extracted initramfs directory.
As for an existing boot.img, it's a Froyo kernel, but there's this: http://forum.xda-developers.com/showthread.php?t=1663622.

nxd said:
On the page I linked to in my first reply, under "Alternative Method", those instructions worked for me to split, unpack, repack, and assemble. Did they not work for you?
Click to expand...
Click to collapse
I tried this method of repacking, but so far I have not been able to re-pack my zImage successfully. (I feel pretty close to getting this) Maybe I am putting the modules in the wrong place? Or perhaps I am skipping a step. I believe I need to assign more room for the modules. I am getting the error that initramfs_cpio is too large.
My initramfs has 2 directories in it- and I created a folder within called lib and placed the modules in there... that may be the wrong way, but I don't think it changes the need for more room in the kernel. Something to do with padding values maybe? /:
Also, the script I am using for this is from JunYoung- it is repack-zImage.sh a tool for de-compiling and recompiling a zImage. That's how I got to my initramfs directory in the new zImage I built with the source.

Zydrate_blue said:
I tried this method of repacking, but so far I have not been able to re-pack my zImage successfully. (I feel pretty close to getting this) Maybe I am putting the modules in the wrong place? Or perhaps I am skipping a step. I believe I need to assign more room for the modules. I am getting the error that initramfs_cpio is too large.
My initramfs has 2 directories in it- and I created a folder within called lib and placed the modules in there... that may be the wrong way, but I don't think it changes the need for more room in the kernel. Something to do with padding values maybe? /:
Click to expand...
Click to collapse
I think your extracted initramfs should have more than two directories.
Would you paste a listing of the files and directories here? Do this:
Code:
cd [path_to_extracted_initramfs] && find *

nxd said:
I think your extracted initramfs should have more than two directories.
Would you paste a listing of the files and directories here? Do this:
Code:
cd [path_to_extracted_initramfs] && find *
Click to expand...
Click to collapse
This is what I have after I unpack the zImage:
cpio-t
decompression_code
initramfs
initramfs/root
initramfs/dev
initramfs.cpio
kernel.img
padding3
padding_piggy
part3
piggy
piggy.gz
piggy.gz+piggy_trailer
piggy_trailer
ramfs+part3
sizes
EDIT: I also tested unpacking another zImage that is working, in fact I tried it on the Bali SK4G that we use currently (I hope that was okay with you /: I probably should have asked) but it just keeps displaying code as if it won't finish unpacking. It makes sense because there is a lot more to unpack, I think it is because it is compressed.

Zydrate_blue said:
This is what I have after I unpack the zImage:
cpio-t
decompression_code
initramfs
initramfs/root
initramfs/dev
initramfs.cpio
kernel.img
padding3
padding_piggy
part3
piggy
piggy.gz
piggy.gz+piggy_trailer
piggy_trailer
ramfs+part3
sizes
EDIT: I also tested unpacking another zImage that is working, in fact I tried it on the Bali SK4G that we use currently (I hope that was okay with you /: I probably should have asked) but it just keeps displaying code as if it won't finish unpacking. It makes sense because there is a lot more to unpack, I think it is because it is compressed.
Click to expand...
Click to collapse
You don't need my permission to use my Bali-based Linux kernel image or patches.
Where can I get a copy of this other boot.img you're working with? It seems clear the hacks and workarounds I used with the Bali-era kernel don't translate directly across. I'd like to take a look and see what I can make of it.

nxd said:
You don't need my permission to use my Bali-based Linux kernel image or patches.
Where can I get a copy of this other boot.img you're working with? It seems clear the hacks and workarounds I used with the Bali-era kernel don't translate directly across. I'd like to take a look and see what I can make of it.
Click to expand...
Click to collapse
Well, I never really found a literal "boot.img" from what I read I have to compile a zImage and in the sidekick's style system boots this as a boot.img??? And I have only used the one from kernel source so far, seeing as I could not get the Bali zImage to split.
As for the initramfs.cpio that us within the zImage, I tried to un-cpio it and I get an error about removing '/ from name?
I could send you the zImage I got from source o.e
EDIT: I never found a copy of boot.img, I couldn't even get one from an outer-source.
Sent from my SGH-T959V using xda app-developers app

Zydrate_blue said:
As for the initramfs.cpio that us within the zImage, I tried to un-cpio it and I get an error about removing '/ from name?
Click to expand...
Click to collapse
That's more of an advisory than an error. It's just telling you that it's stripping off the leading /, i.e. extracting to a relative path.
It sounds like you probably succeeded in extracting the initramfs.

nxd said:
That's more of an advisory than an error. It's just telling you that it's stripping off the leading /, i.e. extracting to a relative path.
It sounds like you probably succeeded in extracting the initramfs.
Click to expand...
Click to collapse
Well, then that sounds better! But what about this one:
cpio: dev/console: Cannot mknod: Operation not permitted
1 block
I forgot there was a following error

Zydrate_blue said:
Well, then that sounds better! But what about this one:
cpio: dev/console: Cannot mknod: Operation not permitted
1 block
I forgot there was a following error
Click to expand...
Click to collapse
You'll probably want to extract the files as root. Otherwise device nodes won't be created, like above, and permissions won't be kept on any of the files.
Be careful to be in a safe (i.e. empty) working directory when you do that. It will extract the files into your current working directory.

nxd said:
You'll probably want to extract the files as root. Otherwise device nodes won't be created, like above, and permissions won't be kept on any of the files.
Be careful to be in a safe (i.e. empty) working directory when you do that. It will extract the files into your current working directory.
Click to expand...
Click to collapse
Okay so now after I execute as root, it gives me this message:
cpio: /dev/console not created: newer or same age version exists
So the directories are empty after extracted?

Zydrate_blue said:
Okay so now after I execute as root, it gives me this message:
cpio: /dev/console not created: newer or same age version exists
So the directories are empty after extracted?
Click to expand...
Click to collapse
There's another argument you needed: --no-absolute-filenames
Unfortuantely it looks like cpio will have kept the absolute path and overwritten files on your real machine.
Extract into a directory using --no-absolute-filenames and see what files on your host system were overwritten. Those files should be recovered somehow before proceeding.
Sorry I didn't catch that.

nxd said:
There's another argument you needed: --no-absolute-filenames
Unfortuantely it looks like cpio will have kept the absolute path and overwritten files on your real machine.
Extract into a directory using --no-absolute-filenames and see what files on your host system were overwritten. Those files should be recovered somehow before proceeding.
Sorry I didn't catch that.
Click to expand...
Click to collapse
Oh god -_- wow I messed up then. well....the only file that was within the cpio was a file named console.... so I think I need to fix that?
I'm not mad or anything, it's a risk you take ya know? But I may need help.
EDIT: Okay so I reboot my laptop and it reboot fine, no issues. I don't think it actually overwrote any file (luckily because that cpio file didn't have anything in it...heh) So should I now try the command with the new argument?

Zydrate_blue said:
Oh god -_- wow I messed up then. well....the only file that was within the cpio was a file named console.... so I think I need to fix that?
I'm not mad or anything, it's a risk you take ya know? But I may need help.
EDIT: Okay so I reboot my laptop and it reboot fine, no issues. I don't think it actually overwrote any file (luckily because that cpio file didn't have anything in it...heh) So should I now try the command with the new argument?
Click to expand...
Click to collapse
I'll take a look at the boot image this evening. It would seem very odd to me if the only file on the initramfs was /dev/console.