odroid-c2 - dd Backup fails #53
Assignees
Labels
enhancement
Enhancement request
Comments
Every Raspberry has the /boot partition as a dedicated partition. There is a check in raspiBackup which requires this. Actually it doesn't make sense for a dd or ddz backup. I can create a hotfix and remove this test for a dd and ddz backup if you are willing to test it and provide feedback. |
framps
added
bug
|
Just a question: You mentioned dd works. But I guess it's a system without am eMMC - right ? |
|
No, it is an odroid with eMMC only, no sdcard. And this dd works for me:
And I would be happy to test it. akidburn |
|
Ok. I will build a fix in a branch on the current master and let you. |
|
@akidburn I just commited in the development banch code which should allow you to create a dd backup. |
framps
added
to be verified
|
Alright. While it didnt work immediately, with a few adjustments i was able to make it work. Havent tried the restore yet, but the backup works. I had to remove the ! at the pv test, or it wouldnt work. |
|
Thank you very much for testing and feedback 👍 Your changes in 3866 and 3868 fixed the logic error on the raspiBackup /boot and /root detection. This has to be fixed in a different way but your change helped me to understand what I have to change. Unfortunately the previous log does not contain the output of Line 4120 should be OK. It's testing whether you request a progress indicator with dd. Then you have to have pv installed. If you don't request a progress indicator pv is not required. Looks like you requested a progress indicator with option Crossing fingers the restore will work ... |
|
There is a beta available which includes a fix for this issue. Feel free to grab the beta and verify the fix. |
|
@akidburn Next version of raspiBackup is available as beta and includes a fix for your issue. Please verify the fix. |
|
@framps Got a similar Problem: changed the search for the /boot mountpoint to /boot/firmware -> works ~: ls /dev/mmc* sudo mount | grep mmc my suggestion is to scan for mountpoints used by the partitions instead of searching the mountpoints of hardcoded pathes? Greetings |
Not sure I get your point. Would you please elaborate on your suggestion and give an example? |
|
Hi @framps, Greetings |
|
Thank you very much @Nexxxy for your reply. That's a restriction of raspiBackup because it's target OS was Raspbian. I see your point and I already have plans to change the boot/root partition detection logic to support other OS which either don't have boot and root partition separated or use a different path. Unfortunately this is critical code which has to be tested carefully and I need some bigger time slot for this. I will create a dedicated code branch for this and update this issue when it's ready. |
framps
removed
fixed
|
I rewrote the boot device discovery and the Raspbian regression tests finished successfully. I now need your help on testing the new discovery which should handle your use case also. Please grab the code branched from the current beta branch and test whether it works for you now 😄 |
framps
added
the
to be verified
|
@Nexxxy Would you please verify the fix 😃 ? |
|
@framps Hi, yep i will. Currently Im in vacation, will test it on monday or tuesday. Greetings |
|
@framps no, it still doesn't work. I have a odroidXU42. It has the same Here the logs: If you need more infos, let me know. Thanks for your really great support and contribution and have fun :-) |
|
@framps I have to thank you!, no issue. I tried with the f223b2c, but I get this error: I tested the backup with the changes of @akidburn and it worked!: but the restore only worked with the "dd" option. I think that it is related to the odroid blobs which are NOT copied with "tar" and "rsysnc". Framp, take your time, the issue is not urgent... |
|
@jobenvil Thank you very much for testing. Your log helped me to understand what's going wrong. I updated raspiBackup in this branch again. It should now work with you odroid.
Yes, you are right. That's something which is not saved when tar or rsync is used. That's something which may be done when using the wrapper script. But you also have to write a wrapper script for the restore. raspiBackup is designed for Raspberry 😢 but I try to support other SOCs with raspiBackup if it's possible with acceptable effort and get help testing the support because I don't own other HW.
I see, but I don't have an odroid and if there is somebody willing to test raspiBackup on odroid as you do I take the time 😄 . |
|
yes @framps testing without odroid ist not easy! don't worry. I got the following error: |
looks pretty good. The discovery of boot and root succeeded and logged. But the result was not returned from Fixed now 😃 |
|
awesome, it works! it looks like really good... 👍 |
|
Thank you very much for your tests 👍 Note: Even this version is called V0.6.4-beta this code will not make it into v0.6.4 which will be published end of this month. This discovery change has to be tested thoroughly and I'm waiting for others to test the discovery also. But this change will most probably make it into v0.6.5. If you want to keep this new discovery you shouldn't upgrade to v0.6.4 end of this month. |
|
Thanks again @framps , I will consider this. The "dd" backup script worked perfectly. The "dd" option restore process as well. I tested the restore image with a brand new Samsung Evo plus microSD card in order to be totally sure that the odroid blobs were successfully copied. Maybe you should advise or warn them, the Odroid users, that the only possible back/restore method is the "dd". One note remark. After the system comes up with new restored image, it is necessary to fix the journal. You see that at the end of dmesg logfile. It is only necessary to shutdown the system with the friendly option "-r" in order to be checked the file system at the next start up. Because I have "fsck.repair=yes" on the start command line, the posible journal errors will be fixed. After the new restart, the journal it is fixed. |
|
Thank you very much to point out the fsck issue. Frankly the regression tests are executed on a stretch image which includes
raspiBackup target and supported platform is Raspberry but it's working on other SOCs and I know it's also successfully used by users. I frankly have no complete picture which SOCs work with raspiBackup and thus don't have any table of SOCs capable to run raspiBackup. I will take your idea and create a table of |
|
The development branch for next release includes the new boot discovery code. Please use this code for verification now. |
|
Just tested raspiBackup on a Odroid HC1 running armbian debian stretch from the development branch for next release. But it's failing because of deviceInfo: Searched for deviceInfo using apt-find ( even on a raspian rpi3 ) but without success. What am I missing? |
|
@tpm8 Thank you very much for testing. Unfortunately i missed to copy a function called deviceInfo in the dev branch code 😢 . I just fixed it. Please try again 😄 |
|
Thanks for fixing @framps I'm glad to help testing for armbian based devices. Unfortunately we're not quite there - now the dd backup fails with error RBK0016E: |
|
@tpm8 Thank you again for testing. I just uploaded a fix into the dev branch. Please try again 😄 |
|
@framps Thanks - now the backup seems to work perfectly. Still have to do a restore test, but restoring a dd image won't be a problem. |
|
@tpm8 Great the discovery works now. Frankly you don't need to execute a restore test with dd. That will work - for sure. I want to enable also tar and rsync backups when boot and root are located on the same device. I didn't find any spare time to implement this until now. Do you volunteer to execute a backup and restore test when this feature is available (ETA approx in 2 months) 😆 |
|
Yes - for sure I'm keen to test rsync / tar backup functions, when they are available. Currently I'm using rsnapshot for file based, versioned backups. But I'd rather consolidate all the backups ( dd and file based ) into just one tool. Just drop me a line then... |
|
@tpm See https://github.com/framps/raspiBackup/tree/shared_backup_restore for a version of raspiBackup which should backup/restore images where the root and boot directory are on one partition. Please grab the code an verify with tar and/or rsync with your system. |
|
@framps - tested with above code on two armbian based systems with root and boot directory on one partition. Backup tests ( dd, rsync, tar ) all worked without errror. dd - Image: I've noticed that during image (dd) backup, a log file -raspiBackup.log is written to /root. This could be a problem, as write accesses to the partition should be avoided during backup. Isn't there the risk of filesystem corruption after a restore? rsync / tar: Hadn't had the time to do a restore test so far. |
|
@tpm8 Thank you very much for your test. You don't need to execute a restore because I noticed there are some backup files missing for tar and rsync. I have to fix this. Will keep you posted. Re you comment about log file in /root. There is no risk of file corruption but tar or rsync may complain about changing files during backup. I have to fix this also (Actually I worked on this issue already-but it looks like I missed some code path 😢 ). |
framps
removed
fixed
|
Just noticed the issue actually is closed: dd backup. But there is an issue with tar and rsync backup. therefore I created new issue #73 and set this issue to fixed and closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
i have an odroid-c2 running Ubuntu 16.04 LTS using a 3.16 Kernel.
The System is using an eMMC and I am not sure if thats the issue, because just dd works, but I really dont want to code another script for one machine.
akidburn
The text was updated successfully, but these errors were encountered: