Replies: 23 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.
-
|
Reboots weren't fixing the issue, so I dug in. This fix worked for me, you'll maybe want to check it to see if it breaks things on other systems? in the You can see, 8th link down in the log that it wants to grab the wrong partition. Log: Also, should the It shows an error when running: |
Beta Was this translation helpful? Give feedback.
-
|
First of all, now we are getting somewhere. I can say immediately that it will break on btrfs and arch based systems.
wdym? is mmcblk0 NOT the correct, device? It's not the partition, it's the device, or, disk as you call it. Can you explain what you changed and why so I understand what is being changed. it is very hard to just "know what is changed" without a diff/pr or smthn. If it's just the way of finding the device, ie using PKNAME, I have notes about really making sure it works on all systems before implementing it, because there is a reason it is done in that convoluted way, and I would really like to know WHY it suddenly does not work on your system, what changes. Edit There is something really fishy going on. |
Beta Was this translation helpful? Give feedback.
-
|
As you noticed before, on my system and @ppanag's, the PTUUID is sometimes the same on both drives. I get that it shouldn't be, but it is what it is. So, because of this, if you're using the PTUUID to determine the drive to shrink, it will occasionally pick the wrong one, simply depending on on which one is listed first, since both drives have the same value. The logged item I quoted from your code is using What I changed is instead of getting the PTUUID, I just find the mount that has the root. i.e. I'm not sure why you're using PTUUID, but my guess is that you need to for these other file systems like btrfs and arch (I don't even know what they are, but I'll look them up)? What does my code return on those systems? |
Beta Was this translation helpful? Give feedback.
-
No, absolutely not. SOMETHING IS DOING THAT ON YOUR SYSTEM!!!!!!!!!!!! The odds of you getting hit by lightning 5 times in a row is probably bigger than randomly getting the same PTUUID. You catching a cold "is what it is", this is NOT random.
I have explained it before, but lets do it again:
I even posted links explaining this earlier in this thread after chat-gpt was used as an information source with complete nonsense. Looking at the other post you made where the system has the same ptuuid (I confirmed this by reading your logs), there IS NO MMCBLK0, ONLY MMCBLK1. So where did that device come from?!? Are you honestly trying to tell me that the linux kernel created multiple of the same PTUUID:s when asked for UNIQUE IDENTIFIERS by the application when you created a new device (what application did that? parted? fdisk)?!? If you want to help, provide information HOW YOU SUDDENLY HAVE TWO OF THE SAME UNIQUE IDS FOR THE DISKS and maybe I would be able to mitigate it, but changing names of variables already in the script, claiming "it is what it is" is you saying shrink-backup is involved in your system doing this, providing a "solution" with code on the repo for shrink-backup. This is something that is close to impossible to happen, THE ODDS ARE ASTRONOMICAL, like 1 in 5,000,000,000,000,000,000,000,000,000,000,000,00. Not impossible, but EXTREEEEEEEEMELY unlikely.
Probably "application not found" on arch based (unless the user has installed the application explicitly), not even Edit The area involved in this discussion IS something I keep an eye on if I can find a better solution so I am open for discussion, but it has to be relevant to HOW and WHY it should be changed. So lets provide some documentation so you have an easier way interpreting the script to be able to provide constructive feedback/information: The device path (disk) is identified before the partitions in the script to minimize repeating of code. This is done outside any function and starts at line 2623 currently on the testing branch: Lines 2623 to 2636 in 6d9eed4 Commented out lines (that are not actually comments) in the script are usually there as a reminder using that method does not work on one or more operating systems/configurations. This can sometimes change over time when operating systems change, so they are there not only as reminders but also for me to easily test in the future in case of changes. The device partition paths are collected in the functions dev_variables & img_variables (and btrfs_variables), how, what and when depends on if it's a new backup or an update. You can easily search for VARIABLE= in the script, they are usually only set once or twice and should not require rocket science to figure out. xD I hope this provides some clarity of how to modify the script "correctly" and maybe a way for you to provide some useful information to me about this "issue" you are having. Edit 2 Edit 3 |
Beta Was this translation helpful? Give feedback.
-
|
My apologies if I offended in any way. It was certainly not my intention - only to find a solution for a problem that I seem to run into from time to time. It sounds like you may have a solution coming, I'm looking forward to trying it. |
Beta Was this translation helpful? Give feedback.
-
So there we have it. If you clone something, it is obviously going to become a clone, ie every single byte of the devices are the same, which also means UUID's of all sorts are exactly the same. I am working on a solution, but it brought me down a rabbit hole for btrfs, so it might take a little while. |
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