On Fedora 40:
For years I've nightly updated copies of three home directories using rsync.
In yesterday's update, rsync updated to 3.4.0-1 and the nightly run failed on all three directories with the following error message:
sending incremental file list Internal hashtable error: illegal key supplied! rsync error: errors with program diagnostics (code 13) at \ hashtable.c(88) [generator=3.4.0]
Reboot (not done after update) did not change things. I downgraded rsync to 3.2.7-7 and the copy program ran normally.
Anyone else seeing problems with rsync 3.4.0-1?
On Wed, Jan 22, 2025 at 12:23 PM Jon LaBadie jonfu@jgcomp.com wrote:
On Fedora 40:
For years I've nightly updated copies of three home directories using rsync.
In yesterday's update, rsync updated to 3.4.0-1 and the nightly run failed on all three directories with the following error message:
sending incremental file list Internal hashtable error: illegal key supplied! rsync error: errors with program diagnostics (code 13) at \ hashtable.c(88) [generator=3.4.0]
Reboot (not done after update) did not change things. I downgraded rsync to 3.2.7-7 and the copy program ran normally.
Anyone else seeing problems with rsync 3.4.0-1?
Possibly related, I believe glibc and gnulib recently merged changes to CRC code,[0] and it appears there's a problem in some code paths.[1]
I do not know if rsync uses glibc or gnulib code. I do not know if rsync even uses crc codes. It may be unrelated.
[0] https://lists.gnu.org/archive/html/bug-gnulib/2024-11/msg00202.html [1] https://lists.gnu.org/archive/html/bug-gnulib/2025-01/msg00164.html
Jeff
On Wed, Jan 22, 2025 at 02:06:29PM -0500, Jeffrey Walton wrote:
On Wed, Jan 22, 2025 at 12:23 PM Jon LaBadie jonfu@jgcomp.com wrote:
On Fedora 40:
For years I've nightly updated copies of three home directories using rsync.
In yesterday's update, rsync updated to 3.4.0-1 and the nightly run failed on all three directories with the following error message:
sending incremental file list Internal hashtable error: illegal key supplied! rsync error: errors with program diagnostics (code 13) at \ hashtable.c(88) [generator=3.4.0]
Reboot (not done after update) did not change things. I downgraded rsync to 3.2.7-7 and the copy program ran normally.
Anyone else seeing problems with rsync 3.4.0-1?
Possibly related, I believe glibc and gnulib recently merged changes to CRC code,[0] and it appears there's a problem in some code paths.[1]
I do not know if rsync uses glibc or gnulib code. I do not know if rsync even uses crc codes. It may be unrelated.
[0] https://lists.gnu.org/archive/html/bug-gnulib/2024-11/msg00202.html [1] https://lists.gnu.org/archive/html/bug-gnulib/2025-01/msg00164.html
I think this is https://github.com/RsyncProject/rsync/issues/697
and if so, it should be fixed in 3.4.1... which was pushed to f41 6 days ago, but if you are on f40, it's still in testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2025-b28759cb95
So, a 'dnf --enablerepo updates-testing update rsync' should update you on f40.
kevin
I just bought a new SSD, installed Fedora 41 on it to occupy the whole disk, and it wouldn't boot. I tried Debian 12 and again it wouldn't boot. I then tried Debian 11 and all was well. Afterwards I checked and the Fedora 41 and Debian 12 installers are not setting the boot flag in the MBR. Is there a good reason why these newer installers are doing this, or is it a bug? Since there seems to be no warning to check this flag after the install is complete it certainly feels like a bug.
Regards,
Steve
On Wed, Jan 22, 2025 at 2:23 PM Steve Underwood coppice12@gmail.com wrote:
I just bought a new SSD, installed Fedora 41 on it to occupy the whole disk, and it wouldn't boot. I tried Debian 12 and again it wouldn't boot. I then tried Debian 11 and all was well. Afterwards I checked and the Fedora 41 and Debian 12 installers are not setting the boot flag in the MBR. Is there a good reason why these newer installers are doing this, or is it a bug? Since there seems to be no warning to check this flag after the install is complete it certainly feels like a bug.
Switch to GPT. MBR is so 1990's. GPT does not need an active, bootable partition. It happens automatically with ESP. And GPT is not limited to four partitions.
Then, reload the operating system.
Jeff
On Wed, 2025-01-22 at 19:22 +0000, Steve Underwood wrote:
[...]
Please don't hijack threads. You posted your question as a reply to a different topic and then changed the Subject line. That doesn't work properly on mailing lists (and MUAs) that pay attention to the In- Reply-To header. You need to compose and post a *new* message.
poc
On Wed, Jan 22, 2025 at 5:01 PM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Wed, 2025-01-22 at 19:22 +0000, Steve Underwood wrote:
[...]
Please don't hijack threads. You posted your question as a reply to a different topic and then changed the Subject line. That doesn't work properly on mailing lists (and MUAs) that pay attention to the In- Reply-To header. You need to compose and post a *new* message.
According to the message headers, the MUA used was "User-Agent: Mozilla Thunderbird."
Maybe there's an option in Thunderbird to start a new thread when the subject: changes?
Jeff
On Wed, 2025-01-22 at 17:06 -0500, Jeffrey Walton wrote:
On Wed, Jan 22, 2025 at 5:01 PM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Wed, 2025-01-22 at 19:22 +0000, Steve Underwood wrote:
[...]
Please don't hijack threads. You posted your question as a reply to a different topic and then changed the Subject line. That doesn't work properly on mailing lists (and MUAs) that pay attention to the In- Reply-To header. You need to compose and post a *new* message.
According to the message headers, the MUA used was "User-Agent: Mozilla Thunderbird."
Maybe there's an option in Thunderbird to start a new thread when the subject: changes?
I seriously doubt if any MUA would try to second guess the user's intentions. The problem derives from using Reply instead of New Message (or whatever the equivalent is in TB).
poc
On Wed, 2025-01-22 at 17:06 -0500, Jeffrey Walton wrote:
Maybe there's an option in Thunderbird to start a new thread when the subject: changes?
That kind of thing causes its own problems. Any significant change to a subject line (to it, but not to you) branches off a new thread (or branches a sub-thread still buried in the middle of a thread).
You get a list that add's a list's name (especially when you get re:[list]re: re: [list] re re:), or someone added a SOLVED to the subject line, etc., and it's disconnected.
Reply when it's a reply, never reply when it isn't. It's that simple.
And it's highly likely that most mail clients will let you click on an address in the message (including headers) and let you create a new email to that address. That's probably the simplest (no effort) way to start a new thread.