dolorosus / RaspiBackup

Backup your raspi
GNU General Public License v3.0
13 stars 4 forks source link

Device name determination is wrong for anything not mmcblk0 #3

Closed ephestione closed 5 years ago

ephestione commented 5 years ago

Ok now you'll be blocking me for flooding :smiling_imp:

This:

lsblk: /dev/sdbp1: not a block device
Could not find PARTUUID of /dev/sdbp1
Changeing PARTUUID from  to b198590c-01 in /tmp/fstab
lsblk: /dev/sdbp2: not a block device
Could not find PARTUUID of /dev/sdbp2
Changeing PARTUUID from  to b198590c-02 in /tmp/fstab
fstab cannot be changed automatically.
correct fstab on destination manually.

I don't think this changes anything about the backup condition, but rather you would need to factor in the device path to form the partition path, like the issue I opened in lzkelley's repo. So "p1" and "p2" for /dev/mmcblk0, "1" and "2" for /dev/sdX, and "-part1" and "-part2" for the, conceptually preferable, /dev/disk/by-id/blahblah

ephestione commented 5 years ago

like here: https://github.com/lzkelley/bkup_rpimage/issues/14#issuecomment-513486840

use if / else on ${SDCARD}:

so partitions can be addressed as "${SDCARD}${SUFFIX}${p}, and you can correctly determine partition path whatever is the source device.

dolorosus commented 5 years ago

Jepp, this is a kown caveat.

Remember the description: "Script to backup a Raspberry Pi SDCARD ..."

Because of your description I will add the SUFFIX soon, but not today since it's now really time to go to bed :-)

dolorosus commented 5 years ago

BTW: Why should I block someone who's finding my errors? Also feel free to open a pull request. Everyone who is willing to help is welcome.

ephestione commented 5 years ago

Today? Who talked about today! You've been extremely fast in correcting those other two other things, I don't expect anything in the short time, I did my own very ugly fix and I'll be fine for a while :smile:

I never did a pull request because I am a total newbie on github, but I'll go check how to do that right now

dolorosus commented 5 years ago

never did a pull request because I am a total newbie on github...

That's something we both have in common.

dolorosus commented 5 years ago

Because I've no such enviroment I'm not able to test this. First try for dynamic loopback names, maybe you can test?

ephestione commented 5 years ago

Tested from the dynamic names branch. First I did the usual backup with /dev/sdb as source name, and the determination of partuuid to change in fstab worked fine.

Then I tried running the backup using the switch -i with /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0\:0

and it correctly did the backup (or rather, updated the backup I had just done), but in the end:

lsblk: /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0:01: not a block device
Could not find PARTUUID of /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0:01
Changeing PARTUUID from  to b4c1fc51-01 in /tmp/fstab
lsblk: /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0:02: not a block device
Could not find PARTUUID of /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0:02
Changeing PARTUUID from  to b4c1fc51-02 in /tmp/fstab
fstab cannot be changed automatically.
correct fstab on destination manually.
ephestione commented 5 years ago

Found it, row 126 and 127, you missed an instance of ${SUFFIX} instead of "p" aaannnd wait, there's something amiss on my side too, I'm working on several projects at the same time and I need to recheck something on your script :/

dolorosus commented 5 years ago

both instances corrected

ephestione commented 5 years ago

yeah, but what's weird is that I corrected them already on my side, and I still get a wrong resolution of the partition device name, with "p" instead of "-part"

ephestione commented 5 years ago

that is, the backup works and everything, but in the end, when lsblk is invoked, ${SUFFIX} is evaluated to "p" and not "-part"

ephestione commented 5 years ago

Also at the beginning of the text output it says rsync /boot/ /mnt/raspi3-2019-09-30.img//boot/ which I think is just a typo that has nothing to do with the actual command

dolorosus commented 5 years ago

line 126 and 127 refer to ${SDCARD} not to ${LOOPBACK}

ephestione commented 5 years ago

yeah but lines 132 and 132 which refer to loopback are still correct... so ${SUFFIX} should be evaluated to "-part" by giving /dev/disk/by-id/* as source... running a backup from scratch right now to check if anything changes

ephestione commented 5 years ago

Yup I still get this:

lsblk: /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0:0p1: not a block device
Could not find PARTUUID of /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0:0p1
Changeing PARTUUID from  to 3ba67387-01 in /tmp/fstab
lsblk: /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0:0p2: not a block device
Could not find PARTUUID of /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0:0p2
Changeing PARTUUID from  to 3ba67387-02 in /tmp/fstab

on a new backup ran with start -ci /dev/disk/by-id/usb-Kingston_DataTraveler_3.0_08606E6B6446F351B726546E-0\:0

Yet the backup is done and I can corectly mount it, but the lsblk still fails because of the wrong resolution... I wonder why this happens?

ephestione commented 5 years ago

Ok, I made a royal mess. My intention was to push my changes into your branch, and instead I basically rolled back my own master branch to a non-working state because I pulled your branch into my master. Soooo I'll refrain from playing again with pull requests, my "current working" version is my master branch, you can check what it was that prevented source partition naming and loopback partition naming from working properly

dolorosus commented 5 years ago

Don't panic! As far as I can see both master branches have only one difference. This diff was created by me removing the hardcoded definition of SDCARD on top of the script.

Everything fine, and the script is better than before. I will close this topic and remove the working branch

ephestione commented 5 years ago

Yeah I noticed that the both of us kind of went on a pull/merge/whatever extravaganza in the last 20 minutes. I still am not sure I grasp the differences between all those procedures yet. Anyway now the network graph of the forks looks like a maze but in the end there are less lines :smile: