official rpios bookworm issue #168
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
Since I've updated to bookworm as well, looking at potential necessary fixes. I am looking at where to put this test.
Would this be right after line 1733?
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.
It seems likely that you will not be affected by the backup media boot issue, but I would test booting a backup to be sure.
I would add the new lines after each occurance of this line:
cmdline_txt=${clone}/boot/cmdline.boot
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.
cmdline_txt=/boot/cmdline.txt
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
cmdline_txt=${clone}/boot/firmware/cmdline.txt
fi
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.
I just created a fix in my fork so rpi-clone creates a bootable clone for bookworm. I tested the fix with a lite 32 bit image only. Would be great if if somebody tests the fix for other images and reports any issues.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:
Looks like your SD card is broken.
It seems very unlikely, as it worked every day before the upgrade... I will check and maybe reformat it.
during rsync I am getting these errors:
Your SD card is broken. I suggest to use a brand new SD card.
I suspect a problem in the USB->SD adapter. The SD is quite new.
Replaced SD. It is working, thanks.
So, should I just use your fork or is there any other patch/change to apply? Should I have to add
--follow-symlinksto eachsedcommand?Just use my fork and your'e fine 😉
@framps
I am using your fork on a Raspi 3B+ 32.bit:
I had a look in the cloned fstab, and I have found a PARTUUID different than the one in the cloned cmdline.txt.
This is from cloned fstab:
and this from cloned cmdline.txt:
root=PARTUUID=b4a2e918-02The PARTUUID in cmdline.txt of the running system is:
b4a2e918-02It doesn't seem to be correct...
@framps
This is the /boot folder in the running system. There is no symlink to /boot/firmware/cmdline.txt, but the systems boots fine:
This is not a clean installation, but an upgrade from bullseye
I never upgrade my RPis and it's also not recommended by the foundation. Looks like there is some issue with the upgrade.
I cannot do a clean install as it will be a major PITA. On my Raspi there is a NodeRed installation and many additional services all configured, so it is not a matter of just make a $HOME backup. Tenths of files in /etc are involved.
I will investigate on this
By adding the symlinks in /boot:
rpi-clone has edited the "real" cmdline.txt, not the one in the clone!!
During rpi-clone execution, I see these messages:
As you can see, rpi-clone is not editing
/mnt/clone/boot/firmware/cmdline.txt, but directly the original/boot/firmware/cmdline.txt!!I just executed rpi-clone from my fork on a bookworm system which was installed with the rpi-imager and not upgraded. Everything works as expected.
It's your upgraded bookworm which causes rpi-clone to fail for some reasons.
Ok, I will give up with rpi-clone.. Thanks.
But there will be hundreds of users with this problem. Maybe finding a solution to the tool should be the best option.
Only people who upgraded to bookworm and I don't think that's done by a lot of people.
I agree. Maybe someone is willing to investigate on this. I'll apply the fix in my fork as soon as there is one available.
BTW: I wrote a script which syncs the fstab and cmdline.txt with the actual UUIDs of the SD card.
Maybe this mitigates your issue with rpi-clone. Just call this script when rpi-clone finished and it will fix the incorrect UUIDs.
Yes, I'll give it a try! Why don't you embed it in your rpi-clone fork?
Does the script takes into consideration the new /boot/firmware mount point?
Yes. See this commit I created this morning.
I have run rpi-clone with '-x' option to have max verbosity, and this is what I found:
As you can see, cmdline_txt is pointing to the active cmdline.txt ! How can that be if the code line is this:
cmdline_txt=$(realpath ${clone}/boot/cmdline.txt)Look at the lines I have highlighted
Found.
Line 1730 on rpi-clone should be:
cmdline_txt=${clone}$(realpath /boot/cmdline.txt)With that mod, it is working fine. Correct UUIDs are in the cloned system and no modification occurred in the running system. Can you apply the fix in your code (if you agree)?
(syntax of that line was wrong in any case. It was pointing at the running system folder, as the symlink is pointing there)
That's interesting:
Your upgraded system does not have the link and therefore
realpathdoesn't point to the linked file on the clone.On a non upgraded system the link already exists and therefore
realpathresolves to the linked file.I think the other suggested fix to add
--follow-symlinksin the sed commands is a better way to go now because it's easier to understand what's going on there.I'll change the code to use
--follow-symlinksand execute a test with a plain bookworm. If everything is OK I'll commit the change in my fork.I have manually added the symlink. Without it, no changes were done in the cloned cmdline.txt.
Does my proposed line work in any case also on a fresh install?
I believe this syntax is not correct:
cmdline_txt=$(realpath ${clone}/boot/cmdline.txt)as you are getting the realpath of
/mnt/clone/boot/cmdline.txt, which will find the symlink to/boot/firmware/cmdline.txtmy proposed change is getting the realpath from
/boot/cmdline.txt(which is /boot/firmware/cmdline.txt) and prepend to it/mnt/clone.As far as I understand - yes. But I will switch to
--follow-symlinksnow. See my previous reply.When cloning a few SD cards in a row I've noticed that /boot/firmware becomes unmounted and then rpi-clone doesn't update the UUID at all, so I had to make sure that it was mounted each time.. I assume rpi-clone is unmounting it ?
@bputtick , AFAIK rpi-clone is not unmounting any current partition! Just the ones it clones to.
Yeh I've not really investigated it, but it happened more than once and I was just cloning, replacing SD card and repeating and nothing else.
Just thought I'd mention it, in case someone else experienced it.
I just committed the
--follow-symlinkschange and successfully tested rpi-clone on a fresh install.I felt this was the safest fix, at least until they remove the symlink they put in for backwards compatibly
But line 1730 is still there, with wrong syntax...
...and it is still modifying original file!!!
I have re-instated my correct line 1730, and it is working back again:
👍 Good catch. I now added
--follow-symlinksin every sed call.but if you "follow symlink" on the cloned partition, it will point to
/boot/firmwareand NOT to/mnt/clone/boot/firmwarebecause of this:
lrwxrwxrwx 1 root root 26 Dec 29 13:53 cmdline.txt -> /boot/firmware/cmdline.txtIn this line cmdline_txt contains /mnt/clone/boot/cmdline.txt
sed -i --follow-symlinks "s/${src_disk_ID}/${dst_disk_ID}/" "$cmdline_txt"and when you follow that symlink, it will then point to
/boot/firmware/cmdline.txtWhy you didn't just keep your previous version and change that 1730 line?
Ok. So you're saying the
--follow-symlinkapproach does not work for you and thusrealpathis the only way to fix your issue?I unfortunately have no upgraded bookworm in order to test your scenario 😢
Looks like I should revert the
--follow-symlinksapproach ...Why, if your previous version was working?
Can you send me the output of
ls -la /booton a fresh installed bookworm?As you can see, it is NOT following to /mnt/clone/boot/firmware
In the echo command there is no realpath nor --follow-symlink used. In the corresponding sed command --follow-symlink ist used 😉
If realpath is used the echo command will echo the correct filename and use the correct filename in sed.
So both ways work correctly but for the --symlink case the echo command echos not the final target filename.
Aaaaaah! That /boot directory!
I fixed my symlinks in
/boot. Now it works, thanks!@framps Have you reverted it back to realpath??? SHould I have to test everything again?
SD cards fail in weird ways, often not all at once, either.
I think the reason @fmarzocca & @framps are seeing different things is there are a lot of underlying changes in the specific case of the Raspberry Pi OS v11.x to v12.x update that
aptdoesn't - and some that it can't - account for. I "successfully" updated a 3B+ from 11 to 12 myself, only to run intoapt updateproblems later because packages, dependencies, etc. weren't located in the filesystem where Raspberry Pi OS v12aptexpected them to be. I wound up having to clean install to resolve the issues.@fmarzocca I don't know the exact reason a clean install won't work for you, but in my case I'd avoided doing so due to an application, UniFi Controller, with dependencies that can't be fulfilled (not by default, at least) by later versions of Raspberry Pi OS. Fortunately, I found instructions online on how to do so with a clean install. You may wind up having to do something similar or - as is possible with UniFi Controller - migrate to a 1st party appliance that has already solved that problem.
I didn't say that it won't work, but that it is a major PITA. My server has a complex NodeRed installation (which can be easily backed up, but it also have several (maybe 7 or 8) additional services that have been carefully tuned up during years (i.e.: apcupsd, gammu, email, mosquitto and many others). It is not just a matter of backup the home folder. To do a complete new installation I should save all the settings and stop the server for several days (I don't have full time free) and this will completely stop the domotics. And I am sure I will forgot something. That's why I took the way of an upgrade which - I may be honest - is fully working for ten days without problems. I have fiuxed this last issue with rpi-clone.
Yes. That way the echo displays the symlinked filename.
So now the code uses realpath again with your suggested modification in line 1730 😉
@jdrch 32-bit or 64-bit?
32-bit.
All subsequent deployments have been 64-bit.
Following the link from this comment
"I think that's not dependent on the new HW but the SW required by RPi5. As far as I know RPi5 requires bookworm and rpi-clone works with bookworm if you apply the patch listed in https://github.com/billw2/rpi-clone/issues/168."
rpi-clone fails for me when trying on my RPI 5
What is the patch? It seems like this is still in flux.
@phillipredshirt use this fork, it has been patched and working.
It's still not working. During boot I get:
`Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ...done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
same line about 15 times then
done.
Gave up waiting for root file system device. Common problems .
...
ALERT! PARTUUID=20ffxxxx-02 does not exist. Dropping to a shell!
`
That's the PARTUUID of the SD card.
@fmarzocca I used the fork and it didn't change anything and then I used the -l switch on the command like this
sudo rpi-clone -l sda
and now I can't boot from the SD card either. It get the same error but points to the PARTUUID of the SSD which isn't plugged in.
So, I kept both the SD card and the SSD and it boots. I think my pi is a little mixed up now.
Edit:
Since it looked like "rpi-clone sda" was failing to update the PARTUUID information on the SSD and "rpi-clone -l sda" modified the SD to point to the PARTUUID of the SSD, I decided to run "rpi-clone sda" one more time. And it worked.
That was weird and a little scary. But my Pi 5 is now running on just my SSD.
Thank you, @fmarzocca
Thank you @framps !! It took me some digging to understand what was going wrong. Once I knew I also found this issue here and the fork which worked very well when cloning to usb. I finally could boot it, because the cmdline.txt was updated properly on the usb. Please @billw2 look into the fork or at least make a note in the readme that current bookworm systems have this problem.
Reasonably sure this repo has been abandoned.
Not working with Bookworm at all for me, even with the patch. When I do
sudo rpi-clone sda -v -fwhen it boots it ends up saying
and sits in a Busybox shell with an initramfs prompt.
Using
sudo rpi-clone sda -vafter booting it ends up like
Tried with 2 different SD cards. What am I doing wrong? This worked fine on another Pi running buster.
Pi 4. And it's the lite image.
Does Raspi Imager change the image based on the machine? I've burned a bunch of Bookworm Lite cards and told it it was for Pi 4 but they run fine in 3 and 3+s.
I'll try cloning Bookworm on a 3 and see what happens.
I think you wind up with 2 different images if you update from 11.x vs. clean install 12.x.
I may be wrong but I guess my fork of rpi-clone fails if Bookworm is not a fresh install but an upgrade from Bullseye. In #174 I helped the guy to check the UUIDs and they didn't match even rpi-clone updated /boot/cmdline.txt. But if /boot/cmdline.txt is a file and no link to /boot/firmware/cmdline.txt rpi-clone updates /boot/cmdline.txt but not /boot/firmware/cmdline.txt. But this file is not used during boot and therefore boot fails because of UUID mismatch.
Maybe somebody who runs an upgraded Bookworm can verify whether my guess is correct?
This has been my experience too.
The irony of that request is because the 11.x to 12.x upgrade path isn't officially supported, upgraded 12.x installations eventually run into breaking issues, such
aptbeing unable to satisfy dependencies.In other words, as horrible as it sounds, I don't think supporting upgraded 12.x installations is worthwhile, as it's pretty much impossible to guarantee the config/folder structure/locations the script is operating on.
That's why I install a fresh OS every time I want to upgrade my systems and I don't have a system handy which was upgraded to verify my guess.
Actually it's not a big deal to check whether /boot/cmdline.txt is a file and create a link to /boot/firmware/cmdline.txt. But I frankly don't like to fix this under the cover in rpi-clone. Maybe it's worth to check and write an error message and nobody blames rpi-clone .
Requiring clean installs for major version upgrades is pretty retrograde and anachronistic of the Raspberry Pi Foundation (I'm not blaming @framps, @billw2, or anyone else) in 2024 AD when the vast majority of major OSes, including the one Raspberry Pi OS is based on, support in-place upgrades. Indeed, Debian itself supports 11.x to 12.x upgrades. I know this because I did it just fine with my Debian server.
I appreciate the Foundation warning users of the risks of in-place upgrades, but the fact they aren't supported reflects poorly on the Foundation and the Foundation only.
Correct. This is a Raspberry Pi OS, and therefore a Raspberry Pi Foundation problem. Except they don't see it as a problem.
I'd say
rpi-cloneshould probably have an option to toggle between cloning for the following environments:As I said in a previous comment, I don't think it's fair to developers to ask them to support 11.x to higher major version in-place upgrades if the underlying OS itself doesn't support them.
I have upgraded 4 Raspi 3B+ from bullseye to bookworm, and I am happily using @framps' fork, provided to execute (after kernel update) the following:
This proves an upgraded OS misses the links which are new to Bookworm and everybody who upgraded has to execute these commands first and then rpi-clone will create a bootable clone.
Correct.
I am suprised this this works. I would have thought that a bullseye to bookworm upgrade would retain the old /boot mountpount, creating the /boot/firmware directory within the /boot filesystem. I was under the impression that vfat filesystems do not support unix symbolic links.
Keep in mind the boot partition is mounted on Bookworm now at /boot/firmware and /boot is located on the root filesystem which is formatted with ext4 and supports symlinks.
I see unofficial rpios upgrade bullseye to bookworm instructions that do not mention upgrading to the new kernel or say that is is optional. Upgrading the kernel will remount /boot to /boot/firmware like a new installation of bookworm, but likely will not add the symbolic links. I just upgraded a 32bit lite rpios using the "edit apt sources" method. While the upgrade to bookworm works, I was left with this:
pi@raspberrypi:/boot $ mount |grep mmcblk0
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
pi@raspberrypi:/boot $ df -h / /boot
Filesystem Size Used Avail Use% Mounted on
/dev/root 59G 2.1G 54G 4% /
/dev/mmcblk0p1 255M 51M 205M 20% /boot
pi@raspberrypi:/etc $ cat os-release |head -1
PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"
pi@raspberrypi:/etc $ ls -la /boot/config.txt /boot/cmdline.txt
-rwxr-xr-x 1 root root 102 Dec 4 21:57 /boot/cmdline.txt
-rwxr-xr-x 1 root root 2075 Dec 4 21:39 /boot/config.txt
In this specific case, the symbolic links not only are not present, but probably are not requred for rpi-clone to work.
Bookworm uses /boot/firmware/cmdline.txt during boot and if you modify /boot/cmdline.txt which is no link to /boot/firmware/cmdline.txt this update will be ignored.
That's the root cause for this issue because rpi-clone fails to update the UUID in /boot/firmware/cmdline.txt but instead updates /boot/cmdline.txt.
The fact that's the case tells you how broken the in-place upgrade path is.
@framps thanks for maintaining your fork / patchset! I've also pulled it into my fork, so hopefully anyone looking for a working tool can grab one of the forks (I had been maintaining my fork for the NVMe support, so since it's referred to a lot I decided to pull in your changes instead of just archiving it... would love to find a way for there to be one 'official' place for the project to reside!
Alternatively, does your rpiBackup tool potentially have room for cloning functionality built in? (Last time I looked, I think you had to do some sort of backup + restore to another drive, which was more complex than a straight clone).
NP. Glad you pulled my changes. Whoever uses rpi-clone should be able to use rpi-clone with Bookworm and future OS releases. Whether it's grabbed from your fork or mine 😃
Agree. Given the fact I maintain raspiBackup I don't volunteer to maintain rpi-clone - even I was asked to do this already.
raspiBackup was designed to create backups - not to clone any systems. Indeed you can clone a system by creating a backup and restore this backup. But that's a workaround and not convenient.
I frankly think most of the guys actually want to create a backup instead of a clone. Maybe I'm wrong ... If there is a strong requirement to get a cloning capability in raspiBackup I'll think about this new feature.
@framps heh, I want both! :D
But for me, the cloning is often useful just to test different media on the same Pi without having to re-image (though sometimes imaging fresh is faster anyway).
For most people, I think full backups are all they'd ever need, short of a better mechanism to upgrade major versions (something I still never recommend on any Linux OS!).
I see your point but that's a special use case you have 😃
Most of the folks using raspiBackup just want to have a backup in case either the SD card fails or something went wrong when they do any upgrades or manually do any config updates and which causes the system fail to boot.
Neither do I
@geerlingguy I've found the easiest way to do this is to use the SD copier utility on a separate Pi. Most of the time if you're having storage media problems on a Pi it's probably unstable anyway, which complicates using it as a clone source. Now, the latter should be possible, but it's not necessarily ideal.
@framps I appreciate
raspibackupin the context of the relative scarcity of dedicated Pi backup and restore tools. That said, if you ask me, an ideal backup tool would be a mix of recording partitions and corresponding UUIDs with something likeresticfor the actual files. That way you get incremental, rapidly restored backups. My main issue withraspibackupas a solution is it has all the inconveniences of a clone operation without restoration convenience (read: the ability to just slap the target disk into the Pi and boot right away) thereof.This is why I prefer
rpi-clone. It's not perfect or incremental, but at least the restore process is as easy as swapping out physical disks.I use the Raspi with NodeRed to control a complex Home Automation. In addition to NR there are many other modules installed and configured (i.e.: mosquitto, gammu-sms, etc...). My main target is to get a clone in order to swap the SDs in case of failure and reduce the system downtime to few minutes. This is a security issue for me. A backup won't work that way.
I'm now convinced a clone feature makes sense. I just created an issue for this in my repo.
Isn't that goal achieved with rpi-clone? That is what I'm using it for as well, but it only updates what has changed between runs.
Yes, it is. I was answering to a previous question from @framps, if you look at the quoted text.
It sounded like the cloning feature was being asked for in rpiBackup, so my comment was more geared towards "if it's already done in rpi-clone, why re-create the cloning function in rpiBackup".
Another vote of thanks for making the fork available! I had been making periodic "clones" of my new bookworm system, but didn't realize I was not protected because the clones would not actually boot. The clones created with the @framps fork will now boot. Thanks!
I think a lot of folks will detect this fact when they actually need the clone to boot. Fortunately the clone only has inconsistent UUIDs which break the boot and can be fixed manually.
I helped folks with this boot issue multiple times in the past when they cloned their system manually and didn't use rpi-clone. Finally I wrote syncUUIDs 😃
An update to package raspberrypi-sys-mods released today (2024-01-29) breaks this again.
In the install transcript,
Sure enough, /boot/cmdline.txt is no longer a symlink to firmware/cmdline.txt; instead a regular file with contents
So back to the drawing board for a new fix...
Thank you very much for the update 👍
Not a big deal but nevertheless some code change is required again. I will update my fork to update /boot/firmware/cmdline.txt and not rely on the link from /boot any more.
@framps - Can you either file that as a separate PR here or just link to your commit here and I'll make sure that's also pulled in on my fork too? Thanks!
There's so much documentation (blogs, forum posts, etc.) still pointing to
/bootfiles :OI created a fix in a new branch in my fork and executed some initial tests. Looks good so far. Would be great if this fix is reviewed and tested by other folks before I merge the fix into my main branch.
@geerlingguy
Unfortunately 😢 I frankly don't understand why they don't keep the link. That's from a backward compatibility view a no no.
The Foundation has made it pretty clear from their Bookworm release announcement that backwards compatibility isn't a priority for them.
Competing x86-64 options with higher performance and first party Debian support approaching Raspberry Pi pricing should fix that problem.
Ok. Well - I don't like this decision. But why do they added the link first and then removed this link now?
If we're lucky, they may have commented the PR/commit containing the change.
Nope. Just read the commit comment
Tested OK.
Just to keep you posted: I created an issue and asked for the rational of this update
@fmarzocca Thank you very much for your verification of my fix. In the meantime I found other ways to fix this issue - just check my latest commit.
But I think it's just fine tuning from a coding perspective. I'll merge the fix into my master branch in one week if there is no feedback any more.
@framps IMHO I prefer
if [[ -d /boot/firmware ]];, unless you are expecting them to change the boot dir many times/year!:-)
I took a look at this; couple of comments
I like the idea of extracting from /etc/fstab or mount. You might consider
awk '{ if ($2 ~ "^/boot") print substr($2, 2)}' /etc/fstabor
mount | awk '{ if ($3 ~ "^/boot") print substr($3, 2)}'which are slightly less "punctuation salad" IMO ;-)
On line 988 you have a case inconsistency (cmdLineDir vs. cmdlineDir)
@zwolfpack I like your awk proposal 👍 and updated the code accordingly.
Good catch 👍 Fixed right now.
If you are accepting suggestions, could you update the version line in rpi-clone? And maybe even the attribution comment near the top to indicate your github url?
@zwolfpack Just to make the awk call more robust: What do you think about
@ProblemChild4901 Done.
Good idea to add the exit.
If you want, you could add a check that the line isn't commented out as well
awk '$1 !~ "^#" && $2 ~ "^/boot" && $3 == "vfat" { print substr($2, 2); exit }' /etc/fstabAdded 😉
@framps Can we consider stable latest commit? Are you going to merge it in master?
I just removed the function call and use a variable now. I consider the code stable but will wait until this WE to give some additional time for any other valuable feedback.
I just merged the bookworm fix branch into master :-)
Thank you!
Maybe you need to update the latest version number in the readme file?
Good catch 👍 Done
I wish I could redirect my fork to yours — is that possible (outside of just a README change)? Don't want to try maintaining a parallel fork especially since it would be great to increase visibility on your other project.
@framps Another one: in readme the installation procedure points to:
$ git clone https://github.com/billw2/rpi-clone.gitYou should change the url, otherwise users are always downloading the old one!
Sure. But please note: I will neither start working on the issues in this repo nor merge any PRs into my fork. I started to work on my fork just to get rpi-clone to run successfully again on Bookworm. But as far as I can see that's the intention of your fork also: Just to add minor missing features (nvme support) and to keep rpi-clone up and running in current and future RaspbianOS releases.
If you want to maintain rpi-clone, work on the PRs and issues just merge my Bookworm fix into your fork and I'll change the all existing links to your fork 😉
Besides that I spent some time and estimated the effort to add clone capability to raspiBackup. It doesn't make sense because raspiBackup is designed to create backups and no clones. You can actually clone a system if you create a backup and then restore the backup to another device. But this makes sense only if you already have a backup. So folks who need clone functionality should use rpi-clone and those who need backup functionality may decide to use raspiBackup.
Good catch. I just updated the link and added an xref to Bills repo.
@framps - Thanks; I've pulled your latest commits, and also touched up the top part of the README a little.
If you'd like, I can hold the 'semi-official' fork, I use it enough that I'd at least merge simple PRs to keep things working, and I might optimize the docs a little more too.
@geerlingguy Do you want new PRs and issues to be created in your repo or should still everything be created in Bills repo? I think it makes sense to use your repo from now on.
@framps - Yeah, that might be good to do, I've turned on notifications. And like I've mentioned, the maintenance would be mostly simple things—so if anyone needs attention on something that breaks or the like, please feel free to mention me in a PR!
I have just remembered I created a helper script a long time ago called raspiBackupRestore2Image which creates a dd backup image file from the just created backup and stores the backup in the backup directory. You even optionally can reduce the dd backup size with pishrink. It's not a big deal to modify the script to restore the backup on another backup device instead of a dd file.
As of now every helper script of raspiBackup is unsupported - but I know raspiBackupRestore2Image is used a lot of time and works perfectly.
I can imagine a feature request for raspiBackup where the restore capability of a just created backup into a dd file in the backup partition or on a device. Latter will actually be a clone onto another device combined with the creation of a new backup version. That way the primary feature of rpi-clone - clone a system for backup purposes - will be added to raspiBackup.
This feature then will be supported.
Any thoughts on this?
I spent the last week to create a prototype based on current raspiBackup release which now supports cloning. Details how to install the prototype and how to provide feedback are available here.
@framps
OK - I'm confused. I was under the impression that this repo (the original
rpi-clone) had been (or would be) archived as it was not being maintained. Geerling advertised his fork as a "friendly fork", and I assumed that was accurate.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
usb-boottool? Likerpi-cloneit's able to copy a "live" image from an RPi to an NVME card - or other media. Just curious if you were aware - or compared - the two.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 :-(