Jump to content

Filesystem Root Contents


Guest flurry

Recommended Posts

Guest flurry

Hi all, having copiously tinkered with my hudl, I now have extra bits and bobs in the root of my hudl's file system. I'm having a bit of a tidy up, I've managed to remove all the extraneous stuff from the /system folder as I can compare this to the stock system image to work out what's been added, however, I don't know what was original in the root of the filesystem. Could someone provide me with a list of what their hudl has as standard in / ? Thanks!

 

Side note: As I understand it, when flashing with RKFlashtool, flashing the system.img to the correct offset paramaters on the hudls storage copies the contents of the system.img and dumps it into the /system folder. Similarly, the boot goes to /boot and kernel to /kernel and so on? If this is so, where do the extra stock files on the root of the storage come from? Are they not contained by the RKFlashtool rom dump images?

Link to comment
Share on other sites

Guest flurry

nobody willing to just screenshot the list of files on the root directory of their hudl?

Edited by flurry
Link to comment
Share on other sites

Guest flurry

do the full backup images such as these (containing the system.img, boot.img, kernel.img etc) contain absolutely everything needed to restore the hudl or are there other files needed?

Link to comment
Share on other sites

Working on your request now - goes without saying, if you don't have a copy of the user partition or a backup of it you'll not have a completely 'restored' as was hudl.

Link to comment
Share on other sites

Guest flurry

Working on your request now - goes without saying, if you don't have a copy of the user partition or a backup of it you'll not have a completely 'restored' as was hudl.

 

so if I have the full backup image and a copy of my user data partition I have a copy of everything on the hudl?

 

Thanks, so much CaptainMidnight, that image is exactly what I was after - massively appreciated!

Link to comment
Share on other sites

While updating those Linux backup / restore scripts of a previous thread, if you included the user partition, then wiped your hudl and followed the long restore - it was like it was before the wipe.

Including the user partition in those scripts does extended the scripts run time by a big factor though.

Edited by Guest
Link to comment
Share on other sites

Guest flurry

While updating those Linux backup / restore scripts of a previous thread, if you included the user partition, then wiped your hudl and followed the long restore - it was like it was before the wipe.

Including the user partition in those scripts does extended the scripts run time by a big factor though.

 

that makes sense now, thanks! Are the parameters of the user partition known/available?

 

when writing the various images to the hudl does the rkflashtool write the contents of the img or the img itself (which then mounts to the right point?), ie, does writing the system.img to the hudl drop the contents of the img into /system, or does it drop the system.img onto the hudl's nand and then mount it to /system?

 

apologies for the many questions, but I'm not finding much on google to explain how it works!

Link to comment
Share on other sites

As far as I'm aware, rkflashtool is just a bit copier/dumper i.e. just like the Linux dd command.

The reason I say that is when you backup partitions you're just dumping data which also includes crud if the partition isn't fully used.

Link to comment
Share on other sites

Guest flurry

As far as I'm aware, rkflashtool is just a bit copier/dumper i.e. just like the Linux dd command.

The reason I say that is when you backup partitions you're just dumping data which also includes crud if the partition isn't fully used.

 

crud being the unused extra space within each img?

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.