Re: blocklistd: Key size mismatch 296 != 288

[Christos Zoulas <christos%zoulas.com@localhost>]

I propose to do just:

Index: state.c
===================================================================
RCS file: /cvsroot/src/external/bsd/blocklist/bin/state.c,v
retrieving revision 1.3
diff -u -u -b -r1.3 state.c
--- state.c     25 Oct 2025 18:43:51 -0000      1.3
+++ state.c     22 Oct 2026 20:51:32 -0000
@@ -43,6 +43,7 @@
 #include <string.h>
 #include <errno.h>
 #include <fcntl.h>
+#include <unistd.h>
 #include <syslog.h>
 #include <netinet/in.h>
 
@@ -88,6 +89,16 @@
                        return NULL;
                (*lfun)(LOG_ERR, "%s: can't open `%s' (%m)", __func__, dbname);
        }
+       if (!(flags & O_CREAT)) {
+               /* check size */
+               struct conf c;
+               struct dbi d;
+               if (state_iterate(db, &c, &d, 1) == -1) {
+                       state_close(db);
+                       unlink(dbname);
+                       return NULL;
+               }
+       }
        return db;
 }
 
@@ -96,8 +107,9 @@
 {
        if (sizeof(struct conf) == t->size)
                return 0;
-       (*lfun)(LOG_ERR, "Key size mismatch %zu != %zu", sizeof(struct conf),
-           t->size);
+       if (debug)
+               (*lfun)(LOG_ERR, "Key size mismatch %zu != %zu",
+                   sizeof(struct conf), t->size);
        return -1;
 }


> On Oct 19, 2026, at 12:52 PM, Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
> 
>> Date: Mon, 19 Oct 2026 16:00:56 +0200
>> From: Thomas Klausner <wiz%netbsd.org@localhost>
>> 
>> After rebooting after an upgrade from 10.1 to 11.0 I see this message
>> on the console, a lot:
>> 
>> blocklistd: key size mismatch 296 != 288
>> 
>> I guess the new blocklistd has a slightly different struct somewhere,
>> but reads files from the old one. How do I correct this?
> 
> This is:
> 
> PR bin/60543: apparent blocklistd format mismatch
> https://gnats.NetBSD.org/60543
> 
> Christos, can you please fix this by either (a) making blocklistd
> accept the format change gracefully, or (b) documenting and adding an
> upgrade path in postinstall to handle it?