|
Franco, regarding dd I assume You mean: dd skip=1 seek=1 with default bs=512 which preserves first SD sector containig partition table?
|
That would work too - I hadn't thought of it.
?
What I did instead was to add a few lines to S01create_data script and use 'blkid' to see if there is a preexisting 'DATA' partition; if there's one I just mount it ().
This way I can just run something like:
?
dd if=sdcard.img of=/dev/sdX bs=8M
and even if it overrides the MBR, S01create_data is still able to find the data partition.
?
This is why I hope this approach would also work for those using other applications writing to the SD card, as long as they don't overwrite the content of the data partition.
?
Franco
|
What if you copied files in Data partition, wrote image, then pasted the original data back into the Data partition on newly flashed SD card?
That would work too - I hadn't thought of it.
?
What I did instead was to add a few lines to S01create_data script and use 'blkid' to see if there is a preexisting 'DATA' partition; if there's one I just mount it ().
This way I can just run something like:
?
dd if=sdcard.img of=/dev/sdX bs=8M
and even if it overrides the MBR, S01create_data is still able to find the data partition.
?
This is why I hope this approach would also work for those using other applications writing to the SD card, as long as they don't overwrite the content of the data partition.
?
Franco
|
There's really no need to copy data around if the SD card was previously already used for R1CBU, since the data is already in the third partition; it is just not mounted because the master boot record (MBR) doesn't have the entry for the third partition (yet), but this 'parted' command takes already care of it:
?
On the other hand, if you are talking about a brand new SD card (i.e. the first time you install R1CBU on it), and you already have a previous SD card with R1CBU, and you want to copy the configuration over, then you would flash the new SD card, put it in the radio once, let the GUI come up, power it off without making any changes, pull the SD card out, and then copy from your computer all the files in the DATA partition of the old card to the DATA partition of the new card (making sure you copy them in the right direction!), and then you should be good.
?
73,
Franco K4VZ
|
Looking lately at your x6100-buildroot changes on github Franco. Found in restore_backup_configs lines preserving ssh server keys - great idea, no more problems with outdated known_hosts entries. But, as i`m using ssh keys, my mind asked: why not preserving user keys too? So, what do you think about including /root/.ssh/* to the $backups list?
|
I don't see why not.
I also just noticed that buildroot 2024.11.1 is out now, so when I have some time (we just moved), I'll create a new SD card image based on the new buildroot version and with the user ssh keys and known_hosts added to the backup list.
In the meanwhile you should be able to easily add that line to that init script in your SD card.
?
Franco
|
No problem Franco doing things by hand, i did it previously creating 'msg' and 'rec' dirs on DATA partition (aka /mnt) - necessary for recording, now i`m thinking about auto-create for this dirs?
|
The file you need to change manually is in the root partition, and it is called '/etc/init.d/S02restore_backup_configs'.
After line 10, you could add another line like this:
?
/root/.ssh/* root_ssh.zip
do make sure you use one or more tabs (not spaces) between the files path and the name of the zip archive.
?
Franco
|
Today I created a new release ('20250120') based on buildroot 2024.11.1 (the buildroot changes are listed here: ).
As you suggested, I added '/root/.ssh/*' to the list configuration backups.
One? thing I noticed is that 'unzip' creates new directories (like '/root/.ssh', which does not exist on a new firmware image) with permissions 755, while 'sshd' might require permissions 700 on the '/root/.ssh' (not really sure though).
?
Anyway you can download the SD card image for the new release from here:
?
If you give it a try, let me know how it goes,
Franco
|
I just thought - perhaps, it will be possible to use one more ext4 partitions - for storing actual linux configurations (/root, /etc/NetworkManager/system-connections/, etc) and handle it like the DATA partition.
With bind mount it's possible to mount some directories from this partition to target directories.
/etc/fstab might looks like:
...
# mount backup partition
/dev/mmcblk1p2 /config_backup ext4 ? ?defaults ? ?0 ? ?0
# bind mount
/config_backup/root /root none defaults,bind 0 0
/config_backup/nm /etc/NetworkManager/system-connections none defaults,bind 0 0
...
Overlayfs also might be used instead of bind.
--
Georgy // R2RFE
|
On Tue, Jan 21, 2025 at 12:28 PM, Georgy Dyuldin wrote:
Overlayfs also might be used instead of bind
This is a good idea. This is common practice.
73!
|
Franco, Thank You, all gone OK smoothly, no need to do anything after writing new image to SD. Ssh key authentication works despite .ssh drwxr-xr-x permitions.
|
Hi, guys
I created a first version of overlays for storing changed linux configurations, which should survive after flashing new version of FW.
Idea is create or recover another ext4 partition (thanks Franco Venturi for the idea and implementation), with some directories, which will be mounted as an overlays to some points of the root.
?
?
Did I miss something? Perhaps, something might be done in a better way?
Will be appreciated for any comments.
--
Georgy // R2RFE
|
Georgy,
thanks for those scripts and for all your work with the X6100 firmware!
?
When I thought about having a way to backup (and restore) Linux configuration settings, like NetworkManager connection settings and ssh keys, I decided to use zip files in the data partition instead of an overlay ext4 partition because I think the majority of the X6100 users runs and is very familiar with Windows based on the posts in this group.
I thought that using the existing data partition (which is VFAT) and a very common file archiving format like zip files would make their life easier because it would allow anyone (running Windows, Mac, or Linux) to say copy those backup files from one SD card to disk or to another SD card, or to see what's inside, or even to modify the zip file contents if someone so wishes (personally I am all for letting the user try new things).
?
With the overlay partition it is definitely possible to do the same, but I am afraid it is not as simple as using zip files.
?
Franco K4VZ
|
Huge thanks to everybody who had a hand in this! New x6100 owner here. I just built v0.29.2 with Franco's buildroot. I switched the colors around a bit for the s-meter and spectrum to be more vibrant to my eyes. That all went well. However in my tweaking i had made a new boot logo.png as a test, but i don't like it. For the life of me i can't find what package to delete so that the original logo.png can be found and rebuilt back in to the boot loader. I know the file i changed was /x6100-buildroot/board/X6100/linux/logo.png but i'm lost as to what to remove from /buildroot-2024.11.2/output/build/ so that it can be rebuilt with the stock logo.png. Any help would be appreciated.
?
Here's the new colors. S-meter goes from green to yellow to red. Spectrum is a light blue. If i can fix my logo.png boo boo, i will gladly upload my sdcard.img.
?
|
... could You also change the color of the frequency marker – specially for
CW - to maybe bright red or orange color ?
?
73 ,Jens
?
toggle quoted message
Show quoted text
From: wicknix via groups.io
Sent: Wednesday, March 19, 2025 3:54 AM
Subject: Re: [xiegu-x6100] Buildroot 2024.11 for R1CBU/R2RFE
firmware
?
Huge thanks to everybody who had a hand in this! New x6100 owner here. I
just built v0.29.2 with Franco's buildroot. I switched the colors around a bit
for the s-meter and spectrum to be more vibrant to my eyes. That all went well.
However in my tweaking i had made a new boot logo.png as a test, but i don't
like it. For the life of me i can't find what package to delete so that the
original logo.png can be found and rebuilt back in to the boot loader. I know
the file i changed was /x6100-buildroot/board/X6100/linux/logo.png but i'm lost
as to what to remove from /buildroot-2024.11.2/output/build/ so that it can be
rebuilt with the stock logo.png. Any help would be appreciated.
?
Here's the new colors. S-meter goes from green to yellow to red. Spectrum
is a light blue. If i can fix my logo.png boo boo, i will gladly upload my
sdcard.img.
?
|
I could be wrong, and i probably am, but from what i've noticed in my brief experimenting is that you can change the marker color that's in the bottom waterfall. However the marker in the top spectrum stays whatever color you change the spectrum to. If it is possible specifically for CW and somebody points me in the right direction i will make the change.
|
On Wed, Mar 19, 2025 at 07:39 AM, Jens/HB9JOI wrote:
could You also change the color of the frequency marker – specially for CW - to maybe bright red or orange color ?
The frequency marker color changes to red when you turn on broadcast recording.
?
By the way, in the firmware for TRX Brass I moved the creation of GUI elements to Python scripts and now anyone can easily change the location and colors of the elements to their taste.
?
73!
|
I think you have to rebuild the Linux kernel (output/build/linux-6.11.11) in order to change the boot logo, since it looks like that logo is embedded in the kernel:
?
As a side node I just noticed that buildroot came out with release 2025.02, so in the next day or two I'll give it a try rebuilding Oleg/Georgy's firmware using this latest version, and then I'll update my repo with that new build.
?
Franco
|
Franco, thanks for getting me looking in the right direction. After some trial and error it came down to rebuilding the kernel, uboot, and x6100_gui. Now the boot logo is fixed.
?
If anyone wants to try it, i uploaded my color changes and sdcard.img
|
wicknix
Jens/HB9JOI