-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
official rpios bookworm issue #168
Comments
Since I've updated to bookworm as well, looking at potential necessary fixes. I am looking at where to put this test. Looking at my pi that I updated to bookworm by changing the source.list and apt update / apt upgrade, I found no folder /boot/firmware, my cmdline.txt is in (old) location /boot Did you do a fresh install? |
I did a fresh install of bookworm 64bit. Lines 1733 1741 With these changes in place, backups of older versions of rpios will not be affected. Some attention should be given to the area around ((convert_to_partuuid)). I have not tested this but the same three lines could be added after 974. |
Thanks, I'll look into this in my setup. For now it does not seem to be needed in my install. But it may be worthwhile for a future fresh install... A pity that rpi-clone does not seem to be maintained for quite some time anymore, and we have to rely on individual changes and updates such as the one pointed out by you. |
I'll create a fix in my fork when I'm back home next week. |
Rebuilt a Raspberry 4-System from scratch yesterday. After work I was surprised to find out that the backups I used to do with rpi-clone would not boot. So I found your issues-discussion here and changed rpi-clone by only adding: if [ -h $cmdline_txt ] ; then after line 1733. To use it again in line 1741 will probably not work because you just changed cmdline_txt to point to a file (rather than a link) after line 1733 and check again whether it points to a link (which will always fail?). Line 1741 deals with cmdline.boot and not cmdline.txt? And from my poor understanding of what the code is doing here I think further changes are not needed here. Don't know about other parts of the code where /boot/cmdline.txt is used. Bottom line: I cloned with just three lines added, it booted fine. Hope that helps. |
EDIT: @zwolfpack s fix below is much better than mine. But realpath is not required for fstab. I created a PR and added the fix in my fork. |
The changes around line 1733 are sufficient to make a normal backup bootable. One of the other two changes are in an area to change fstab and cmdline.txt from device names to PARTUUID: line 974. The other change seems to be when someone has a boot (or now firmware) partition on the SD card while the root partition is on a USB drive.: line 1741. |
The issue arises when cmdline.txt is edited via 'sed -i'. That command ends up replacing the symlink /boot/cmdline.txt with the edited content, but the link target in /boot/firmware/cmdline.txt, which is the place that needs changing, isn't changed. To fix, realpath(1) can be used to resolve the filename to the actual target. Following patch applies this for all instances where 'sed -i' is used.
|
I realize that realpath is not required for fstab ... currently. However, a similar problem would arise if /etc/fstab was symlinked. So I though it prudent to fix that as well. |
I see your point. But I don't expect /etc/fstab to become symlinked. It's a file as long as Linux exists. That's why I decided to remove realpath for /etc/fstab in my PR. |
I fixed this by adding --follow-symlinks to the sed command |
FWIW it doesn't look like the fork works either with official clean install Bookworm on the Pi 3B+. I tried it just now and the Pi wouldn't get past power on. |
😢 Unfortunately rpi-clone misses an important feature to help if there are any issues - a debug log 😢 Would be great to have a debug log of your restore in order to help you. Maybe somebody adds the missing debug feature in rpi-clone 😉 |
No worries. I have an Pi 4B on hand so I'm using the SD card copier utility instead. Still not as handy for backups, but it'll work well enough to migrate from one microSD card to another. Here's hoping that doesn't fail. |
I use raspiBackup to backup my Raspberries. Just give it a try 😉 |
I'll look into that, thanks! |
raspiBackup has a debug log 😄 - just in case you have any issues |
Hi, I tried everything in this post but my cloned card doesn't boot. I run rpi-clone on a pi4 (waiting for pi5 arrival) with Pi OS "bookworm" 64 bit. Nothing to do, I have to give-up. The clone with GUI official script works, as usual. |
as others pointed out it did do the correct edit but just didn't store it at the right target folder. It stored it in /mnt/clone/boot/cmdline.txt instead of /mnt/clone/boot/firmware/cmdline.txt . I was able to manually put in the USB drive and set the right partition value in the firmware folder and it works. |
@framps thanks, your version works without issue! |
In verband met de feestdagen ben ik tot en met vrijdag 29 december 2023 afwezig en zal mijn email beperkt kunnen lezen en beantwoorden.
Ik wens u het allerbeste voor 2024 en fijne feestdagen!
Met vriendelijke groet,
FSE Turnstiles b.v.
Jos de Vries
PS: Neem voor urgente storingen contact met ons op door een email te sturen naar ***@***.***
|
On which Raspberry Pi OS version? |
Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 with Kernel: pi5 6.1.0-rpi7-rpi-2712 |
which is the final patch to apply to rpi-clone on a Rasp 3B+ (32bit) bookworm? I am getting confused... |
|
I have used @framps fork on my bookworm, and this is the results I am getting on boot partition:
|
OK - I'm confused. I was under the impression that this repo (the original So, could I ask, "What is the plan?"... will this (original) repo continue on, or are we all supposed to be on board with the geerling repo? |
Jeff fortunately volunteered to take over maintenance of this abandoned repository. Would be great if @billw2 updates this repo and points to Jeffs fork. Not sure whether he still follows his repo.
If you want to get any updates/fixes on rpi-clone - yes 😉 I was inspired by rpi-clone and added clone support in my prototype of raspiBackup. It's a different backup tool and it's primary purpose is to create backups. I think the clone feature is a very useful additional feature which is missing in raspiBackup and that's why I created the prototype 😉 |
Yeah, basically @framps has a great backup tool, with some added cloning functionality. And it has more active development. I'm maintaining a copy of rpi-clone minimally, just to make sure basic cloning functionality continues working on newer Pi OS releases. It is meant only for cloning. |
OK - thanks for the input! BTW, have either of you taken a look at/evaluated the |
Given there is no feedback on the clone feature in raspiBackup I added in a prototype this feature will not make it into next release. It was a nice experience to add this feature but it's unfortunately orthogonal to the design of raspiBackup and therefore the prototype is just a hack and will not make it :-( |
Can someone clarify for the slower amongst us - I've been on hols for 3 weeks and so only now noticed the issue with the latest 64 bit OS on rPI 5 (it was working maybe 5 weeks ago). Can create ssd (on usb adaptors) clones but they will not boot. Should I be using the @framps version and it so which link? |
Right I went to your page as you suggested - and as user pi I got rid of any traces of other rpi-clones and used the link and the GOOD news is - it was a daft power message - didn't see it until I connected a monitor - in config.txt - the message tells you what one-line change to make in config.txt Rebooted - SSD works - used that to create a new SD. Here for anyone interested I've always used this in /etc/bash.bashrc to make life easwy - still works with your version of RPI-CLONE - WHEEE. `` alias stop='sudo shutdown now' #optional hostnames in 4 functions below cclone () { cloneb () { clonem () { ccloneb () { cclonem () { cclonec () { clonec () { |
Has anyone tried this: https://github.com/seamusdemora/RonR-RPi-image-utils? |
Yes. It's a nice tool to create a clone also. But in contrast to rpi-clone the clone is stored in a dd image and you have to restore the dd image first before you can use it. With rpi-clone you have a cold standy because the clone is already stored on an SD card or USB disk and can be used immediately. In addition don't use the code from this repo ! The code is outdated and it's not the repo of Ron, the author of the code. He doesn't maintain his code on github. If you want to use his code grab the latest code directly from his thread in https://forums.raspberrypi.com/ |
Huh!?!? That is poppycock... every word of it is BS.
This must be Slag Seamus Day in your world! Everything you've said in this post is provably and objectively UNTRUE. No idea what you've got a hard-on about, but please find someone else to |
Proof that every word is BS 😉 |
Hey folks I didn't mean to start an argument. I came across the script I asked about in an XDA post and was curious since I'd never heard of it before. Currently only @framps' tool is actively developed by the original developer, so there's that. |
How do you figure that? What has possessed you to start this mud-slinging? Do I know you... have I wronged you somehow that I'm unaware of? What makes people just go running off at the mouth (keyboard), and just make stuff up? |
Either proove my statements in #168 (comment) are wrong or shut up. |
No - that's utter nonsense... you can do a loop mount on the .img file to copy or edit any file you want. There's even a utility in
Wrong again... If you'll actually bother to "look", you will see that the files from the GitHub repo are exactly the same as the latest posted version from RonR on the RPi forum page. You don't need to take my word for this... you can download the zip file from the forum & clone the GitHub repo - and then do a So - are you now going to "shut up", and retract your ignorance? ... I suspect not, but we shall see. |
@seamusdemora scroll up, it's linked to in the thread. |
@jdrch : Do you mean a fork he created of this repo (rpi-clone)?? |
Great you now started to explain in detail what's wrong for you in my statements above instead of just grumbling 👍 Please note: I'm not saying image-backup is a bad tool. It's used by a lot of folks. It's a nice tool similar to rpi-clone which is also used by a lot of folks. image-backup has another design and because of this has other users.
Sure. You don't have to restore the whole backup if you just need some files to restore.
Sure. That's a difference to rpi-clone where you can only have a device as a target instead of a directory. There is a PR out there for rpi-clone to support loop devices. Then rpi-clone also will be able to store a clone in any directory.
Sure. rsync is used to populate an image mounted with losetup - not dd. Please read my statement from above again carefully 😉
(a) I didn't talk about partial restore of some data. I talked about a full restore of the whole clone. If you want to do this with image-backup you have to restore the backup on Linux with dd first (I didn't write anything about creation of the backup with dd). In contrast rpi-clone has the backup already available and no restore is required. That's one of the major difference for me between rpi-clone and image-backup. (b) I didn't write this cannot be done with image-backup. I wrote rpi-clone creates the clone on a device like a SD card or SSD which then can be used immediately to boot the system. That's something image-backup cannot do. (c) I didn't write dd is used to create the backup. I wrote you have to use dd to restore the backup. And keep in mind: The result of image-backup is an dd image which can be accessed with Please read my statement from above again carefully 😉
Your repo was updated 3 months ago. In the mean time Ron added multiple new versions of his code in the forum. So your repo is outdated. And I've seen multiple times folks grabbed Rons code from some github repos (not sure whether it was yours or others) and reported an issue in the forum thread and Ron just answered it's already fixed: Just grab my latest code from my first post in this thread. |
The updated RPI-clone vis backing up directories..... RPI-clone is so fast, who cares about all the detail about which directories need backing up – it does the lot – just changes – typically. Using my aliases - a typical clone to SD involves the word CLONE and that;'s it - can do a clone blind drunk - often in a minute - no thought - no effort.... when I refer to rpi-clone, today on RPI and Bookworm of course, I'm referring to this. curl https://raw.githubusercontent.com/geerlingguy/rpi-clone/master/install | sudo bash |
image-backup is also very fast because it uses rsync to backup only changes. I don't want to have a flame war rpi-clone against image-backup here 😳 . Both are nice and heavily used tools. I just want to make sure everybody understands the major differences between them and then can decide which tool is the best one for his Raspberries. |
Agreed. The more options we have, the better. |
Is this what you call a "graceful retreat"? LOL |
No. It's just a statement to make sure we're on the same page 😉 |
Ah - so is that an admission that you were mistaken? But after your BS rant - NO... We are not now, nor will we ever be "on the same page". You have issues, my friend - you should get some help. |
|
Oh-h-h!... look everyone - he's so clever. :) |
Is there anyone who can help me on this issue? |
The official rpios bookworm release has changed the mount point /boot to /boot/firmware. The current rpi-clone can back up, but the backup media is not bootable because the cmdline.txt file is not updated with the new PARTUUID.
/boot/cmdline.txt -> /boot/firmware/cmdline.txt
Consider adding lines like this after these variable assignments "cmdline_txt=${clone}/boot/cmdline.txt"
if [ -h $cmdline_txt ] ; then
cmdline_txt=${clone}/boot/firmware/cmdline.txt
fi
This tests if the /boot/cmdline.txt is a link and changes it to the actual file.
The text was updated successfully, but these errors were encountered: