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

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 2/25/25 2:42 PM, Steve Underwood wrote:

I thought I'd post a follow up about this, after doing more installs.

I agree that the time of the MBR should have passed for any hardware that is not ancient. I thought that Fedora 41 and Debian 12 were putting an MBR on the disc, because they had decided the old machines I was using could not handle a GPT disc, and UEFI boot. However, it appears both these installers will put an MBR on any disc of 2TB or less, even on the most modern machines, unless you force them not to with command line parameters as you boot the installer. Without forcing they use an MBR, but they don't set the boot flag. Maybe the testers use larger discs, and have not noticed this, although I would have expected a lot of testing to be done with SSDs these days, and anything over 2TB is still quite pricey. An interesting problem for two independent installation systems to have.

There was a change back in F37 to use GPT for all x86_64 installs regardless of whether it was UEFI or legacy (CSM) boot. Maybe your hard drive already had an MBR partition table and you didn't tell the installer to reformat. https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault

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 1/22/25 15:12, Patrick O'Callaghan wrote:

The problem derives from using Reply instead of New Message (or whatever the equivalent is in TB).

Thunderbird reply options:

Reply ctrl-R

Reply All ctrl-shift-R

Reply List ctrl-shift-L

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.