Replies: 17 comments 15 replies
-
|
For some reason, the script detects this as your device: But when it checks for sizes for partitions it for some reason detects another mmcblk: So the reason it fails is because your root partition is most likely on You seem to have a strange setup, are you booting from one device and have root on another or something? To help you figure it out, give me the output of |
Beta Was this translation helpful? Give feedback.
-
|
Well, you don't need to give me the output, you gave me the answer. For shrink-backup to work, boot partition (if existing) MUST be on the same device as root... |
Beta Was this translation helpful? Give feedback.
-
|
It should have been. I typically umount |
Beta Was this translation helpful? Give feedback.
-
|
Not sure just unmounting is enough, I don't remember from memory how it's done. So you cant use another boot and just unmount, you need to start the system with the boot running from the same device as root (in case of armbian with uboot and no partition, it needs to run from the same device as root partition) Edit |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so are you saying that the bootloader has to be on the media that |
Beta Was this translation helpful? Give feedback.
-
|
Give me these and let's see if we can figure out what is going on here... |
Beta Was this translation helpful? Give feedback.
-
|
Booting with µSD and without umounting cat /etc/fstab lsblk -f mount --fake | grep ' / ' | awk '{print $1}' |
Beta Was this translation helpful? Give feedback.
-
|
Booting with the µSD and after cat /etc/fstab lsblk -f mount --fake | grep ' / ' | awk '{print $1}' |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so it's the second device you want so it's here it's failing: So why does it find the wrong device.. |
Beta Was this translation helpful? Give feedback.
-
|
lsblk -no mountpoint,ptuuid |
Beta Was this translation helpful? Give feedback.
-
|
Oh right, I need the device too.. xD |
Beta Was this translation helpful? Give feedback.
-
|
lsblk -no path,mountpoint,ptuuid |
Beta Was this translation helpful? Give feedback.
-
|
This might be harder to figure out than that... I'm testing shrink-backup now, booting from the µSD and it seems to be working. My guess is the only change is that this is AFTER I've run armbian-install and copied the µSD image to the eMMC. |
Beta Was this translation helpful? Give feedback.
-
|
This does not make sense, you must have booted from the other device when running shrink-backup, because that is what your commands are giving. Lines 2552 to 2564 in 59e27b2 |
Beta Was this translation helpful? Give feedback.
-
|
Since it's not happening currently, let me know what exactly you need to see, if/when I can get it to fail again. |
Beta Was this translation helpful? Give feedback.
-
|
lsblk -no ptuuid,type,path | grep 88cb8654 | grep 'disk' | awk '{print $3}' | head -1 But this is now that it's working again. |
Beta Was this translation helpful? Give feedback.
-
|
When it fails again, do the same procedure again and try to figure out why it fails Take that number and use in following line and replace ptuuid will not change, so something is def wonky here. |
Beta Was this translation helpful? Give feedback.
-
|
Again I'll ask, |
Beta Was this translation helpful? Give feedback.
-
|
I mean, I can not guarantee it will work, since the script assumes the boot information is on the same partition as root, so I can not give any guarantees the img will work after a restore, only you can know that by trying it... |
Beta Was this translation helpful? Give feedback.
-
|
No problem. I understand. Safest to run shrink-backup when booting from the eMMC and no µSD is inserted, is what it sounds like. But, out of curiousity, do you know how to figure out where the bootloader is located? |
Beta Was this translation helpful? Give feedback.
-
|
I am not very well versed with u-boot, and I don't actually have access to any armbian systems to check right now, but the first few lines of |
Beta Was this translation helpful? Give feedback.
-
|
dmesg | head -33 I assume the "unknown kernel command" that shows |
Beta Was this translation helpful? Give feedback.
-
|
Gives you a warning btw, does not necessarily mean there is anything wrong, but could probably be good to ask someone who knows more about u-boot... But you have both |
Beta Was this translation helpful? Give feedback.
-
|
I have been thinking about this, and I simply can't come up with an explanation of why this is happening. But if you manage to reproduce the error again, run the commands I gave before to try to figure out why it's detecting the wrong device, but please also try this other method of finding the "disk" device: (It's the method used when autoexpanding for example rpiOS) In other words, run these commands: If you find the second works (when shrink-backup finds the wrong device) but not the first, please let me know and I will change method in the script. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. I've used it several times since then, but it's worked properly each time. Once I'm able to reproduce the problem, I will get that info for you to see if we can solve the issue. |
Beta Was this translation helpful? Give feedback.
-
|
Same issue here: #81 If any of you guys figure out why/how/when this is occurring, maybe there is something shrink-backup can do to mitigate, or at least explain what is going wrong better than what is reported as the error at this moment. Since I can not reproduce this error myself, I have to rely on you to spoonfeed me info. xD |
Beta Was this translation helpful? Give feedback.
-
|
After searching about it (with chatGPT), I ended up on this: All my drives use MBR (msdos) partition tables.
lsblk -o NAME,PTTYPE,SIZE,TYPE,MOUNTPOINT NAME PTTYPE SIZE TYPE MOUNTPOINT |
Beta Was this translation helpful? Give feedback.
-
|
Well, it's kinda true, but
You can also read a tiny bit about it here: https://forums.raspberrypi.com/viewtopic.php?t=185166 The question is WHY does your system create the filesystem with the exact same PTUUID, the odds of that happening is astronomical, something that simply should not happen, so if it does it most likely is PROVIDED MANUALLY during the creation, find out why. Since PTUUID IS the method of identifying disks, that is the way shrink-backup is doing it. And you can not just "convert a disk from mbr to gpt" when it also acts as your boot partition, and absolutely not something a backup script should do willy-nilly. Try to figure out when/how/why your sda got the same PTUUID as your root partition, because as I said, the odds of it happening by chance is close to zero. Edit. But for me to do that change, I want you to provide following:
If you can provide this, I can change on testing branch and start testing to make sure it does not create any problems on any system. |
Beta Was this translation helpful? Give feedback.
-
|
That hurt a bit :) You are right.. We just dont have much time these days and resort to AI ... :) |
Beta Was this translation helpful? Give feedback.
-
|
I made a note about this in my "todo". I'll create a usb with the same PTUUID and see if I can mitigate this in shrink-backup somehow. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I think you've told me before why this happens, but I can't find the answer here anymore. This seems to happen randomly and after a reboot or I try something else, it works again. What is it I'm doing wrong?
Here's the last of the output from shrink-backup 1.3-beta:
The log:
Beta Was this translation helpful? Give feedback.
All reactions