Bug#295449: Patch to get CAserial and CAcreateserial working again
The included patch fixes the problem where CAserial no longer works.
Note that you now have to give either CAserial or CAcreateserial (or
both) in order to use a serial number file.
The first hunk of the patch fixes the actual bug report. The second hunk
fixes a bug where there is more than one dot in the CAfile path/filename
or the dot is not in the filename but is in a directory name.
Patched against openssl-0.9.7e (sarge)
Tim.
--- x509.c.orig 2005-05-23 23:53:14.0 +0100
+++ x509.c 2005-05-24 00:50:52.0 +0100
@@ -593,15 +593,17 @@
if ((x=X509_new()) == NULL) goto end;
ci=x->cert_info;
- if (sno == NULL)
+ if (sno == NULL && CAserial==NULL && !CA_createserial)
{
sno = ASN1_INTEGER_new();
if (!sno || !rand_serial(NULL, sno))
goto end;
}
- if (!X509_set_serialNumber(x, sno))
- goto end;
+ if (sno != NULL)
+ if (!X509_set_serialNumber(x, sno))
+goto end;
+
if (!X509_set_issuer_name(x,req->req_info->subject)) goto end;
if (!X509_set_subject_name(x,req->req_info->subject)) goto end;
@@ -1061,12 +1063,16 @@
if (serialfile == NULL)
{
BUF_strlcpy(buf,CAfile,len);
- for (p=buf; *p; p++)
+ for (p=buf+strlen(buf)-1; p>buf; p--)
+ {
+ if (*p == '/')
+ break;
if (*p == '.')
{
*p='\0';
break;
}
+ }
BUF_strlcat(buf,POSTFIX,len);
}
else
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#656899: mdadm: sending ioctl 1261 to a partition warnings
I'm also seeing this problem. I can trigger these errors trivially by doing: /sbin/lvcreate -A n -L500M -s -nvar-backup /dev/vg0/var and /sbin/lvremove -A n -f /dev/vg0/var-backup Seeing lots of these two errors: Mar 24 10:53:25 feynman kernel: [4198946.403294] mdadm: sending ioctl 1261 to a partition! Mar 24 10:53:25 feynman kernel: [4198946.403510] mdadm: sending ioctl 800c0910 to a partition! uname -a Linux feynman.home.woodall.me.uk 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 GNU/Linux Additionally, the lvremove doesn't actually work first time if the previous snapshot that was made was not of the same partition. I have no idea if that is related but I wouldn't be surprised if it is. I first saw the lvremove problem on Feb 1st. mdadm and linux-image were updated on 29th Jan but I didn't reboot until 4th Feb From kern.log backed up on morning of 5th Feb: Reboot here: Feb 4 19:54:43 feynman kernel: Kernel logging (proc) stopped. Feb 4 19:54:43 feynman kernel: Kernel log daemon terminating. First instance of this ioctl issue here: Feb 4 19:55:58 feynman kernel: [3.622444] md: raid1 personality registered for level 1 Feb 4 19:55:58 feynman kernel: [3.670803] mdadm: sending ioctl 800c0910 to a partition! Feb 4 19:55:58 feynman kernel: [3.670877] mdadm: sending ioctl 800c0910 to a partition! Feb 4 19:55:58 feynman kernel: [3.670939] mdadm: sending ioctl 1261 to a partition! Feb 4 19:55:58 feynman kernel: [3.670993] mdadm: sending ioctl 1261 to a partition! Feb 4 19:55:58 feynman kernel: [3.671312] mdadm: sending ioctl 1261 to a partition! Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://www.woodall.me.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#820145: Sendmail-bin moves /etc/mail/ssl to /etc/mail/tls even when both directories exist
Package: sendmail-base Version: 8.14.4-4+deb7u1 Severity: minor I have /etc/mail/tls and also /etc/mail/ssl which contains dhparam.pem. On upgrading sendmail-base the pre-inst script does: # Move files to new home if [ -d /etc/mail/ssl ]; then mv -f /etc/mail/ssl /etc/mail/tls; fi; ;; This, then promptly breaks TLS email as sendmail.mc refers tot he dhparam.pem in the old directory which no longer exists. This script ought to check if both directories exist and, if so, not move /etc/mail/ssl/ to /etc/mail/tls/ssl/
Bug#1022043: apt-cacher-ng sometimes fails with several concurrent
On Fri, 23 Feb 2024, Andreas B. Mundt wrote: Hi Tim, thanks for the provided patch! We see the same issue here, so I included it in a locally built package to give it a try on our infrastructure. So far it looks quite promising, no errors up to now . That's great! I've been running it for a few weeks now and also seen no errors since I started using it. I believe it's possibly fixed a second "buggette" too although I never confirmed that this really existed and I haven't confirmed that it's definitely gone away either. If you simultaneously install a big package on multiple machines at the same time (e.g. a kernel upgrade) then I believe that apt-cacher-ng used to download it from upstream multiple times. Only once it had a copy did it serve that up. This was noticable to me in the past because I was on a relatively slow download (c 2MB/s) so kernels would take a noticable amount of time to download and 10 in parallel could take a lot longer than a single download should have taken. I used to work around this by triggering the download on a single machine and then only triggering the rest once that one had completed downloading. Since applying this fix I've done another mass kernel upgrade. I'm on a much faster connection now so I didn't really think about triggering the download in advance but it only downloaded the kernel once. zgrep linux-image-5.10.0-28 * access.log.2.gz:1708183270.671 17321 TCP_MISS/200 55667185 GET http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-5.10.0-28-amd64_5.10.209-2_amd64.deb - HIER_DIRECT/2a04:4e42:4b::644 application/vnd.debian.binary-package Next time I'll try and take more care to watch what really happens here (although with my much faster connection a kernel downloads in a few seconds anyway) Tim.
Bug#944780: Many more cases where this fails - proposed patch included
This same problem happens for SUBSHELL_PAREN, SUBSHELL_COMSUB,
SUBSHELL_PIPE and SUBSHELL_COPROC as well as SUBSHELL_ASYNC
Test case (This must be sourced to see SHLVL == 1 which causes
/etc/bash.bashrc to be sourced in a shell started by ssh)
$ cat test.sh
test1="bash -c 'echo \$SHLVL'"
test2="{ bash -c 'echo \$SHLVL' ; }"
do_test()
{
echo "** Testing $1 $2"
eval $2
wait
echo "* DONE *"
echo
}
do_coproctest()
{
echo "** Testing COPROC $1"
eval coproc $1
IFS= read -ru ${COPROC[0]} x; printf '%s\n' "$x"
wait
echo "* DONE *"
echo
}
do_test BASIC "$test1"
do_test BASIC "$test2"
#ASYNC
do_test ASYNC "$test1 &"
do_test ASYNC "$test2 &"
#PAREN
do_test PAREN "( $test1 )"
do_test PAREN "( $test2 )"
#COMSUB
do_test COMSUB "echo \$( $test1 )"
do_test COMSUB "echo \$( $test2 )"
#PIPE
do_test PIPE "$test1 | cat"
do_test PIPE "$test2 | cat"
#PROCSUB
do_test PROCSUB "cat <( $test1 )"
do_test PROCSUB "cat <( $test2 )"
#COPROC
do_coproctest "$test1"
do_coproctest "$test2"
##
Proposed patch:
diff -urN bash-5.1.orig/execute_cmd.c bash-5.1/execute_cmd.c
--- bash-5.1.orig/execute_cmd.c 2020-10-12 14:16:13.0 +
+++ bash-5.1/execute_cmd.c 2020-10-12 14:16:13.0 +
@@ -5487,7 +5487,12 @@
#if 0 /* TAG: bash-5.2 psmith 10/11/2020 */
if (nofork && pipe_in == NO_PIPE && pipe_out == NO_PIPE &&
(subshell_environment & SUBSHELL_PIPE) == 0)
#else
- if (nofork && pipe_in == NO_PIPE && pipe_out == NO_PIPE)
+ if (nofork && pipe_in == NO_PIPE && pipe_out == NO_PIPE &&
+ (subshell_environment & SUBSHELL_ASYNC) == 0 &&
+ (subshell_environment & SUBSHELL_PAREN) == 0 &&
+ (subshell_environment & SUBSHELL_COMSUB) == 0 &&
+ (subshell_environment & SUBSHELL_PIPE) == 0 &&
+ (subshell_environment & SUBSHELL_COPROC) == 0)
#endif
adjust_shell_level (-1);
#
It seems absurd that:
bash -c 'echo $SHLVL'
{ bash -c 'echo $SHLVL' ; }
should both have SHLVL == 2 but if they are executed async then the
first one runs with SHLVL == 1 but not the second.
The proposed patch causes them all to run at SHLVL == 2 which then
avoids the issue of SHLVL == 1 causing /etc/bash.bashrc to be sourced
when running under ssh.
It also fixes issues with make running in interactive shells
unexpectedly.
Without the fix:
$ cat Makefile.test
all:
echo $$SHLVL
$ make -f Makefile.test
echo $SHLVL
1
$ make -f Makefile.test | cat
echo $SHLVL
0
$
This does not change the behaviour reported in #702559
#
N.B. The sourcing of /etc/bash.bashrc is most easily seen by:
$ ( bash -uc : )
/etc/bash.bashrc: line 8: PS1: unbound variable
$
This issue of unbound variables in bash.bashrc was reported in #941248
###
Results of running test.sh in bullseye:
(If it is sourced the results are, as expected, one lower)
# ./test.sh
** Testing BASIC bash -c 'echo $SHLVL'
3
* DONE *
** Testing BASIC { bash -c 'echo $SHLVL' ; }
3
* DONE *
** Testing ASYNC bash -c 'echo $SHLVL' &
2
* DONE *
** Testing ASYNC { bash -c 'echo $SHLVL' ; } &
3
* DONE *
** Testing PAREN ( bash -c 'echo $SHLVL' )
2
* DONE *
** Testing PAREN ( { bash -c 'echo $SHLVL' ; } )
3
* DONE *
** Testing COMSUB echo $( bash -c 'echo $SHLVL' )
2
* DONE *
** Testing COMSUB echo $( { bash -c 'echo $SHLVL' ; } )
3
* DONE *
** Testing PIPE bash -c 'echo $SHLVL' | cat
2
* DONE *
** Testing PIPE { bash -c 'echo $SHLVL' ; } | cat
3
* DONE *
** Testing PROCSUB cat <( bash -c 'echo $SHLVL' )
3
* DONE *
** Testing PROCSUB cat <( { bash -c 'echo $SHLVL' ; } )
3
* DONE *
** Testing COPROC bash -c 'echo $SHLVL'
2
* DONE *
** Testing COPROC { bash -c 'echo $SHLVL' ; }
3
* DONE *
##
with the proposed patch applied:
** Testing BASIC bash -c 'echo $SHLVL'
3
* DONE *
** Testing BASIC { bash -c 'echo $SHLVL' ; }
3
* DONE *
** Testing ASYNC bash -c 'echo $SHLVL' &
3
* DONE *
** Testing ASYNC { bash -c 'echo $SHLVL' ; } &
3
* DONE *
** Testing PAREN ( bash -c 'echo $SHLVL' )
3
* DONE *
** Testing PAREN ( { bash -c 'echo $SHLVL' ; } )
3
* DONE *
** Testing COMSUB echo $( bash -c 'echo $SHLVL' )
3
* DONE *
** Testing COMSUB echo $( { bash -c 'echo $SHLVL' ; } )
3
* DONE *
** Testing PIPE bash -c 'echo $SHLVL' | cat
3
* DONE *
** Testing PIPE { bash -c 'echo $SHLVL' ; } | cat
3
* DONE *
** Testing PROCSUB cat <( bash -c 'echo $SHLVL' )
3
* DONE *
** Testing PROCSUB cat <( { bash -c 'echo $SHLVL' ; } )
3
* DONE *
** Testing COPROC bash -c 'echo $SHLVL'
3
* DONE *
** Testing COPROC { bash -c 'echo $SHLVL' ; }
3
* DONE *
Bug#941248: Amended patch proposed.
I'd like to propose a slightly modified patch:
diff -urN bash-5.1.orig/debian/etc.bash.bashrc bash-5.1/debian/etc.bash.bashrc
--- bash-5.1.orig/debian/etc.bash.bashrc2022-03-27 18:36:06.0
+
+++ bash-5.1/debian/etc.bash.bashrc 2022-03-27 18:36:06.0 +
@@ -4,7 +4,7 @@
# this file has to be sourced in /etc/profile.
# If not running interactively, don't do anything
-[ -z "$PS1" ] && return
+[[ $- = *i* ]] || return
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
@@ -17,7 +17,7 @@
# set a fancy prompt (non-color, overwrite the one in /etc/profile)
# but only if not SUDOing and have SUDO_PS1 set; then assume smart user.
-if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
+if ! [ -n "${SUDO_USER:-}" -a -n "${SUDO_PS1:-}" ]; then
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
which avoids the assumption that an interactive shell always has PS1 set
(unlikely to be false but not impossible)
Bug#1019500: apt-cacher-ng should depend on xz-utils
Package: apt-cacher-ng Version: 3.7.4-1 Severity: minor Dear Maintainer, The /etc/cron.daily/apt-cacher-ng installed by apt-cacher-ng uses /usr/bin/xz from xz-utils but apt-cacher-ng does not depend on that package. Please consider adding this dependency otherwise you can get emails from cron like the following: /etc/cron.daily/apt-cacher-ng: xargs: xz: No such file or directory Thanks.
Bug#1017944: Doesn't affect buster
Guess we're finding out where everyone's update windows are. Some though may report before resolving the issue or somewhat after. Or people may not have noticed yet if they haven't rebooted or attempted to start a new guest. It doesn't affect buster hosts. bullseye is impacted.
Bug#944780: Info received (Many more cases where this fails - proposed patch included)
This bug is still present in bookworm. Attached updated patch. diff -urN bash-5.2.15.orig/execute_cmd.c bash-5.2.15/execute_cmd.c --- bash-5.2.15.orig/execute_cmd.c 2022-12-13 17:09:02.0 + +++ bash-5.2.15/execute_cmd.c 2022-12-13 17:09:02.0 + @@ -5633,7 +5633,12 @@ /* If we're optimizing out the fork (implicit `exec'), decrement the shell level like `exec' would do. Don't do this if we are already in a pipeline environment, assuming it's already been done. */ - if (nofork && pipe_in == NO_PIPE && pipe_out == NO_PIPE && (subshell_environment & SUBSHELL_PIPE) == 0) + if (nofork && pipe_in == NO_PIPE && pipe_out == NO_PIPE && + (subshell_environment & SUBSHELL_ASYNC) == 0 && + (subshell_environment & SUBSHELL_PAREN) == 0 && + (subshell_environment & SUBSHELL_COMSUB) == 0 && + (subshell_environment & SUBSHELL_PIPE) == 0 && + (subshell_environment & SUBSHELL_COPROC) == 0) adjust_shell_level (-1); maybe_make_export_env ();
Bug#944780: Info received (Bug#944780: Info received (Many more cases where this fails - proposed patch included))
Unfortunately, I've found that my patch has some serious issues on bookworm and isn't any good.
Bug#1075339: Patch for FTBFS
--- opendkim.orig/librbl/rbl.c 2018-11-15 00:47:38.0 +
+++ opendkim/librbl/rbl.c 2024-08-25 09:37:34.860816615 +
@@ -329,7 +329,7 @@
rbl_res_close(void *srv)
{
#ifdef HAVE_RES_NINIT
- struct state *res;
+ struct __res_state *res;
res = srv;
This is the only change required. c.f. dkim_res_close in
libopendkim/dkim-dns.c. This appears to be a long standing typo.
Attached patch includes fix for the usrmerge migration but #1073606 for
lib/opendkim/opendkim.service.generate (Changelog says this file is
deprecated and perhaps the right option is to drop it but I've moved it
to /usr/lib/opendkim/opendkim.service.generate.
root@dirac:/build# dpkg --fsys-tarfile opendkim_2.11.0~beta2-9_amd64.deb | tar
tvf - | awk '{print $6}' | cut -d/ -f 1-2 | sort -u
./
./etc
./usrdiff -ur opendkim.orig/debian/opendkim.default opendkim/debian/opendkim.default
--- opendkim.orig/debian/opendkim.default 2023-06-16 19:52:26.0 +
+++ opendkim/debian/opendkim.default 2024-08-25 14:31:08.938597424 +
@@ -3,8 +3,8 @@
# /etc/opendkim.conf instead.
#
# Previously, one would edit the default settings here, and then execute
-# /lib/opendkim/opendkim.service.generate to generate systemd override files at
-# /etc/systemd/system/opendkim.service.d/override.conf and
+# /usr/lib/opendkim/opendkim.service.generate to generate systemd override
+# files at /etc/systemd/system/opendkim.service.d/override.conf and
# /etc/tmpfiles.d/opendkim.conf. While this is still possible, it is now
# recommended to adjust the settings directly in /etc/opendkim.conf.
#
diff -ur opendkim.orig/debian/opendkim.install opendkim/debian/opendkim.install
--- opendkim.orig/debian/opendkim.install 2023-06-16 19:52:26.0 +
+++ opendkim/debian/opendkim.install 2024-08-25 14:24:50.877217867 +
@@ -1,5 +1,5 @@
debian/README.PrivateKeys etc/dkimkeys
debian/opendkim.conf etc
debian/opendkim.m4 etc/mail/m4
-debian/opendkim.service-generate lib/opendkim
+debian/opendkim.service-generate usr/lib/opendkim
usr/sbin/opendkim
diff -ur opendkim.orig/debian/rules opendkim/debian/rules
--- opendkim.orig/debian/rules 2024-08-25 12:03:57.239204374 +
+++ opendkim/debian/rules 2024-08-25 14:33:53.964910239 +
@@ -53,8 +53,8 @@
override_dh_install:
dh_install
- mv $(CURDIR)/debian/opendkim/lib/opendkim/opendkim.service-generate \
- $(CURDIR)/debian/opendkim/lib/opendkim/opendkim.service.generate
+ mv $(CURDIR)/debian/opendkim/usr/lib/opendkim/opendkim.service-generate \
+ $(CURDIR)/debian/opendkim/usr/lib/opendkim/opendkim.service.generate
override_dh_installchangelogs:
dh_installchangelogs RELEASE_NOTES
diff -ur opendkim.orig/librbl/rbl.c opendkim/librbl/rbl.c
--- opendkim.orig/librbl/rbl.c 2018-11-15 00:47:38.0 +
+++ opendkim/librbl/rbl.c 2024-08-25 12:05:44.169015382 +
@@ -329,7 +329,7 @@
rbl_res_close(void *srv)
{
#ifdef HAVE_RES_NINIT
- struct state *res;
+ struct __res_state *res;
res = srv;
Bug#1075196: Patch to get libopendbx building on sid.
This patch fixes the FTBFS for libopendbx.
The root cause is that the "generic" items in odbx_t and odbx_lo_t are
really FB_API_HANDLE and this is a void* on 32 bit and int on 64 bit.
This code is not strictly portable as it relies on the bitwise
representation of the nullptr being all bits zero. But the added casting
in the patch to fix the FTBFS does not affect the portability concerns.
Other drivers, e.g. mssql, use similar casting of this value.
Additionally, there's a minor change to Makefile.am. I was regularly
hitting a race condition where doxygen was being run multiple times in
parallel due to the multiple targets and sometimes two runs were trying
to create the same directory. If the directory already exists it
succeeded, if it created the directory it succeeded, but if it thought
it needed to create the directory but then the other process created it,
it would fail with an error tht it couldn't create the directory.
The fix avoids doxygen being run multiple times when a single run
generates all the targets.diff -ur libopendbx.orig/backends/firebird/firebird_basic.c libopendbx/backends/firebird/firebird_basic.c
--- libopendbx.orig/backends/firebird/firebird_basic.c 2010-08-01 02:08:39.0 +
+++ libopendbx/backends/firebird/firebird_basic.c 2024-08-25 15:38:10.794478511 +
@@ -134,7 +134,7 @@
fbc->tr[0] = 0;
fbc->trlevel = 0;
- fbc->stmt = NULL;
+ fbc->stmt = 0;
fbc->numstmt = 0;
param[0] = isc_dpb_version1;
@@ -181,7 +181,7 @@
memcpy( fbc->path + fbc->srvlen, database, len2 + 1 );
- if( isc_attach_database( fbc->status, (short) fbc->srvlen + len2, fbc->path, &(handle->generic), (short) len, param ) != 0 )
+ if( isc_attach_database( fbc->status, (short) fbc->srvlen + len2, fbc->path, (isc_db_handle*)&(handle->generic), (short) len, param ) != 0 )
{
return -ODBX_ERR_BACKEND;
}
@@ -213,7 +213,7 @@
return -ODBX_ERR_BACKEND;
}
- if( isc_detach_database( fbc->status, &(handle->generic) ) != 0 )
+ if( isc_detach_database( fbc->status, (isc_db_handle*)&(handle->generic) ) != 0 )
{
return -ODBX_ERR_BACKEND;
}
@@ -344,8 +344,8 @@
fbc->qda->sqld = 0;
- fbc->stmt = NULL;
- if( isc_dsql_allocate_statement( fbc->status, &(handle->generic), &(fbc->stmt) ) != 0 )
+ fbc->stmt = 0;
+ if( isc_dsql_allocate_statement( fbc->status, (isc_db_handle*)&(handle->generic), &(fbc->stmt) ) != 0 )
{
return -ODBX_ERR_BACKEND;
}
@@ -483,7 +483,7 @@
return -ODBX_ERR_BACKEND;
}
- if( isc_start_transaction( fbc->status, fbc->tr + fbc->trlevel, 1, &(result->handle->generic), sizeof( tbuf ), tbuf ) != 0 )
+ if( isc_start_transaction( fbc->status, fbc->tr + fbc->trlevel, 1, (isc_db_handle*)&(result->handle->generic), sizeof( tbuf ), tbuf ) != 0 )
{
return -ODBX_ERR_BACKEND;
}
@@ -786,7 +786,7 @@
fbc->trlevel++;
fbc->tr[fbc->trlevel] = 0;
- if( isc_start_transaction( fbc->status, fbc->tr + fbc->trlevel, 1, &(handle->generic), sizeof( tbuf ), tbuf ) != 0 )
+ if( isc_start_transaction( fbc->status, fbc->tr + fbc->trlevel, 1, (isc_db_handle*)&(handle->generic), sizeof( tbuf ), tbuf ) != 0 )
{
return -ODBX_ERR_BACKEND;
}
diff -ur libopendbx.orig/backends/firebird/firebird_lo.c libopendbx/backends/firebird/firebird_lo.c
--- libopendbx.orig/backends/firebird/firebird_lo.c 2010-08-01 02:08:39.0 +
+++ libopendbx/backends/firebird/firebird_lo.c 2024-08-25 15:29:51.726699041 +
@@ -47,7 +47,7 @@
(*lo)->generic = NULL;
(*lo)->result = result;
- if( isc_open_blob2( fbc->status, &(result->handle->generic), fbc->tr + fbc->trlevel, &((*lo)->generic), (ISC_QUAD*) value, 0, NULL ) != 0 )
+ if( isc_open_blob2( fbc->status, (isc_db_handle*)&(result->handle->generic), fbc->tr + fbc->trlevel, (isc_blob_handle*)&((*lo)->generic), (ISC_QUAD*) value, 0, NULL ) != 0 )
{
free( *lo );
*lo = NULL;
@@ -62,7 +62,7 @@
static int firebird_odbx_lo_close( odbx_lo_t* lo )
{
- if( isc_close_blob( ((struct fbconn*) lo->result->handle->aux)->status, &(lo->generic) ) != 0 )
+ if( isc_close_blob( ((struct fbconn*) lo->result->handle->aux)->status, (isc_blob_handle*)&(lo->generic) ) != 0 )
{
return -ODBX_ERR_BACKEND;
}
@@ -104,7 +104,7 @@
if( buflen > 0x ) { len = 0x; }
else { len = buflen; }
- err = isc_get_segment( fbc->status, &(lo->generic), &bytes, len, (char*) buffer );
+ err = isc_get_segment( fbc->status, (isc_blob_handle*)&(lo->generic), &bytes, len, (char*) buffer );
if( fbc->status[1] == isc_segstr_eof ) { return 0; }
if( err != 0 ) { return -ODBX_ERR_BACKEND; }
@@ -122,7 +122,7 @@
if( buflen > 0x ) { len = 0x; }
else { len = (unsigned short) buflen; }
- if( isc_put_segment( fbc->status, &(lo->generic), len, (char*) buffer ) != 0 )
+ if( isc_put_segment( fbc->status, (isc_blob_handle*)&(lo->generic), len, (char*) buffer ) != 0 )
{
return -ODBX_ERR_BACKEND;
}
diff -ur libopendbx.orig/doc/Makefile.am libopendbx/doc/Makefile.am
--- libopendbx.orig/doc/Makefile.am
Bug#1073606: Patch included in fix for #1075339
Attached is the patch also included on 1075339diff -ur opendkim.orig/debian/opendkim.default opendkim/debian/opendkim.default
--- opendkim.orig/debian/opendkim.default 2023-06-16 19:52:26.0 +
+++ opendkim/debian/opendkim.default 2024-08-25 14:31:08.938597424 +
@@ -3,8 +3,8 @@
# /etc/opendkim.conf instead.
#
# Previously, one would edit the default settings here, and then execute
-# /lib/opendkim/opendkim.service.generate to generate systemd override files at
-# /etc/systemd/system/opendkim.service.d/override.conf and
+# /usr/lib/opendkim/opendkim.service.generate to generate systemd override
+# files at /etc/systemd/system/opendkim.service.d/override.conf and
# /etc/tmpfiles.d/opendkim.conf. While this is still possible, it is now
# recommended to adjust the settings directly in /etc/opendkim.conf.
#
diff -ur opendkim.orig/debian/opendkim.install opendkim/debian/opendkim.install
--- opendkim.orig/debian/opendkim.install 2023-06-16 19:52:26.0 +
+++ opendkim/debian/opendkim.install 2024-08-25 14:24:50.877217867 +
@@ -1,5 +1,5 @@
debian/README.PrivateKeys etc/dkimkeys
debian/opendkim.conf etc
debian/opendkim.m4 etc/mail/m4
-debian/opendkim.service-generate lib/opendkim
+debian/opendkim.service-generate usr/lib/opendkim
usr/sbin/opendkim
diff -ur opendkim.orig/debian/rules opendkim/debian/rules
--- opendkim.orig/debian/rules 2024-08-25 12:03:57.239204374 +
+++ opendkim/debian/rules 2024-08-25 14:33:53.964910239 +
@@ -53,8 +53,8 @@
override_dh_install:
dh_install
- mv $(CURDIR)/debian/opendkim/lib/opendkim/opendkim.service-generate \
- $(CURDIR)/debian/opendkim/lib/opendkim/opendkim.service.generate
+ mv $(CURDIR)/debian/opendkim/usr/lib/opendkim/opendkim.service-generate \
+ $(CURDIR)/debian/opendkim/usr/lib/opendkim/opendkim.service.generate
override_dh_installchangelogs:
dh_installchangelogs RELEASE_NOTES
diff -ur opendkim.orig/librbl/rbl.c opendkim/librbl/rbl.c
--- opendkim.orig/librbl/rbl.c 2018-11-15 00:47:38.0 +
+++ opendkim/librbl/rbl.c 2024-08-25 12:05:44.169015382 +
@@ -329,7 +329,7 @@
rbl_res_close(void *srv)
{
#ifdef HAVE_RES_NINIT
- struct state *res;
+ struct __res_state *res;
res = srv;
Bug#1081008: dump: Dump fails if the filesystem has more than 2^32 blocks
Package: dump
Version: 0.4b47-4+~tjw12r5
Severity: normal
Dear Maintainer,
Dump cannot handle more than 2^32 blocks. This was reported upstream
some years ago along with a patch that I am including here.
I'm reporting this as I have another ext4 patch that I've built on top
of this one.
I've also attached a testcase that doesn't require >12TB of data to
reproduce (it needs about 3GB of available disk space)
It's crafted to my setup and will require modification for anybody else
to use.
-- System Information:
Debian Release: 12.7
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-25-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dump depends on:
ii libblkid1 2.38.1-5+deb12u1
ii libbz2-1.01.0.8-5+b1
ii libc6 2.36-9+deb12u8
ii libcom-err2 1.47.0-2
ii libext2fs21.47.0-2
ii liblzo2-2 2.10-2
ii libreadline8 8.2-1.3
ii libselinux1 3.4-1+b6
ii tar 1.34+dfsg-1.2+deb12u1
ii zlib1g1:1.2.13.dfsg-1
dump recommends no packages.
dump suggests no packages.
-- no debconf information
diff -urN dump-0.4b47.orig/dump/dump.h dump-0.4b47/dump/dump.h
--- dump-0.4b47.orig/dump/dump.h2022-05-03 10:02:27.0 +
+++ dump-0.4b47/dump/dump.h 2022-05-03 10:02:27.0 +
@@ -140,8 +140,8 @@
intmapdirs (dump_ino_t maxino, long long *tapesize);
/* file dumping routines */
-void blksout (blk_t *blkp, int frags, dump_ino_t ino);
-void bread (ext2_loff_t blkno, char *buf, int size);
+void blksout (blk64_t *blkp, int frags, dump_ino_t ino);
+void bread (ext2_loff_t blkno, char *buf, size_t size);
void dumpino (struct dinode *dp, dump_ino_t ino, int metaonly);
#ifdef __linux__
void dumpdirino (struct dinode *dp, dump_ino_t ino);
@@ -153,7 +153,7 @@
/* tape writing routines */
intalloctape (void);
void close_rewind (void);
-void dumpblock (blk_t blkno, int size);
+void dumpblock (blk64_t blkno, int size);
void startnewtape (int top);
time_t trewind (void);
void writerec (const void *dp, int isspcl);
diff -urN dump-0.4b47.orig/dump/tape.c dump-0.4b47/dump/tape.c
--- dump-0.4b47.orig/dump/tape.c2022-05-03 10:02:27.0 +
+++ dump-0.4b47/dump/tape.c 2022-05-03 10:02:27.0 +
@@ -254,7 +254,7 @@
}
void
-dumpblock(blk_t blkno, int size)
+dumpblock(blk64_t blkno, int size)
{
int avail, tpblks;
ext2_loff_t dblkno;
diff -urN dump-0.4b47.orig/dump/traverse.c dump-0.4b47/dump/traverse.c
--- dump-0.4b47.orig/dump/traverse.c2021-01-01 16:28:57.0 +
+++ dump-0.4b47/dump/traverse.c 2021-01-01 16:28:57.0 +
@@ -748,7 +748,7 @@
struct block_context {
ext2_ino_t ino;
- blk_t *buf;
+ blk64_t *buf;
int cnt;
int max;
int next_block;
@@ -758,8 +758,8 @@
* Dump a block to the tape
*/
static int
-dumponeblock(UNUSED(ext2_filsys fs), blk_t *blocknr, e2_blkcnt_t blockcnt,
-UNUSED(blk_t ref_block), UNUSED(int ref_offset), void * private)
+dumponeblock(UNUSED(ext2_filsys fs), blk64_t *blocknr, e2_blkcnt_t blockcnt,
+UNUSED(blk64_t ref_block), UNUSED(int ref_offset), void * private)
{
struct block_context *p;
e2_blkcnt_t i;
@@ -840,7 +840,7 @@
spcl.c_dinode.di_size = sblock->fs_bsize;
spcl.c_flags |= DR_EXTATTRIBUTES;
spcl.c_extattributes = EXT_XATTR;
- blksout(&dp->di_file_acl, EXT2_FRAGS_PER_BLOCK(fs->super), ino);
+ blksout((blk64_t *)&dp->di_file_acl,
EXT2_FRAGS_PER_BLOCK(fs->super), ino);
spcl.c_flags &= ~DR_EXTATTRIBUTES;
spcl.c_extattributes = 0;
}
@@ -978,12 +978,12 @@
}
#ifdef __linux__
bc.max = NINDIR(sblock) * EXT2_FRAGS_PER_BLOCK(fs->super);
- bc.buf = malloc (bc.max * sizeof (int));
+ bc.buf = malloc (bc.max * sizeof (blk64_t));
bc.cnt = 0;
bc.ino = ino;
bc.next_block = 0;
- ext2fs_block_iterate2(fs, (ext2_ino_t)ino, BLOCK_FLAG_DATA_ONLY, NULL,
dumponeblock, (void *)&bc);
+ ext2fs_block_iterate3(fs, (ext2_ino_t)ino, BLOCK_FLAG_DATA_ONLY, NULL,
dumponeblock, (void *)&bc);
/* deal with holes at the end of the inode */
if (i_size > ((uint64_t)bc.next_block) * sblock->fs_fsize) {
remaining = i_size - ((uint64_t)bc.next_block) *
sblock->fs_fsize;
@@ -1261,9 +1261,9 @@
* Collect up the data into tape record sized buffers and output them.
*/
void
-blksout(blk_t *blkp, int frags, dump_ino_t ino)
+blksout(blk64_t *blkp, int frags, dump_ino_t ino)
{
- blk_t *bp;
+ blk64_t *bp;
int i, j, count, blks, tbperdb;
blks = howmany(frag
Bug#1081010: dump: Dump fails verifying long symlinks with ext4 extents
Package: dump
Version: 0.4b47-4+~tjw12r5
Severity: normal
Dear Maintainer,
When using restore -C lgetflags returns 0 for symlinks as flags are not
vaild/settable on a symlink.
However, if EXT4_EXTENTS_FL is set then the verification fails saying
that the flags have changed.
./long_symlink: flags changed from 0x0008 to 0x.
-- System Information:
Debian Release: 12.7
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-25-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dump depends on:
ii libblkid1 2.38.1-5+deb12u1
ii libbz2-1.01.0.8-5+b1
ii libc6 2.36-9+deb12u8
ii libcom-err2 1.47.0-2
ii libext2fs21.47.0-2
ii liblzo2-2 2.10-2
ii libreadline8 8.2-1.3
ii libselinux1 3.4-1+b6
ii tar 1.34+dfsg-1.2+deb12u1
ii zlib1g1:1.2.13.dfsg-1
dump recommends no packages.
dump suggests no packages.
-- no debconf information
diff -urN dump-0.4b47.orig/restore/dirs.c dump-0.4b47/restore/dirs.c
--- dump-0.4b47.orig/restore/dirs.c 2022-05-03 10:02:27.0 +
+++ dump-0.4b47/restore/dirs.c 2022-05-03 10:02:27.0 +
@@ -791,7 +791,7 @@
do_compare_error;
}
#ifdef __linux__
- if (lgetflags(cp, &newflags) < 0) {
+ if (lgetflags(cp, &newflags, 0) < 0) {
if (node.flags != 0) {
warn("%s: lgetflags failed", cp);
do_compare_error;
diff -urN dump-0.4b47.orig/restore/extern.h dump-0.4b47/restore/extern.h
--- dump-0.4b47.orig/restore/extern.h 2022-05-03 10:02:27.0 +
+++ dump-0.4b47/restore/extern.h2022-05-03 10:02:27.0 +
@@ -127,7 +127,7 @@
int setflags (int, unsigned long);
int lsetflags (const char *, unsigned long);
-int lgetflags (const char *, unsigned long *);
+int lgetflags (const char *, unsigned long *, unsigned long);
#ifdef USE_QFA
intInode2Tapepos (dump_ino_t, long *, long long *, int);
diff -urN dump-0.4b47.orig/restore/tape.c dump-0.4b47/restore/tape.c
--- dump-0.4b47.orig/restore/tape.c 2022-05-03 10:02:27.0 +
+++ dump-0.4b47/restore/tape.c 2022-05-03 10:02:27.0 +
@@ -1805,7 +1805,7 @@
do_compare_error;
}
#ifdef __linux__
- if (lgetflags(name, &newflags) < 0) {
+ if (lgetflags(name, &newflags, flags) < 0) {
if (flags != 0) {
warn("%s: lgetflags failed", name);
do_compare_error;
diff -urN dump-0.4b47.orig/restore/utilities.c dump-0.4b47/restore/utilities.c
--- dump-0.4b47.orig/restore/utilities.c2022-05-03 10:02:27.0
+
+++ dump-0.4b47/restore/utilities.c 2022-05-03 10:02:27.0 +
@@ -263,7 +263,7 @@
*/
#ifdef sunos
#else
- if (lgetflags (existing, &s) != -1 &&
+ if (lgetflags (existing, &s, 0) != -1 &&
lsetflags (existing, 0) != -1) {
ret = link(existing, new);
lsetflags(existing, s);
@@ -731,7 +731,7 @@
#endif /* DUMP_MACOSX */
int
-lgetflags(const char *path, unsigned long *flags)
+lgetflags(const char *path, unsigned long *flags, unsigned long inode_flags)
{
int err;
struct stat sb;
@@ -742,7 +742,7 @@
if (S_ISLNK(sb.st_mode) || S_ISFIFO(sb.st_mode)) {
// no way to get/set flags on a symlink
- *flags = 0;
+ *flags = inode_flags & EXT4_EXTENTS_FL;
return 0;
}
else
Bug#1081009: dump: Dump reads uninitialized blocks from ext4 filesystems.
Package: dump
Version: 0.4b47-4+~tjw12r5
Severity: important
Dear Maintainer,
Dump includes data read from EXT2_EXTENT_FLAGS_UNINIT extents in the
dump instead of writing zeros (or nothing) to the tape.
This means that restores are corrupted.
The attached patch is a quick fix for this. Better would be to not write
the blocks to the tape at all and to try to reserve the blocks without writing
on restore. (I think this will depend on blocksize on the restore FS and
whether this is supported at all)
I do intend to rework this so that the empty blocks aren't written to
the tape but I recently switched to ext4 from ext3 and was getting
corrupted backups that I needed to fix quickly.
-- System Information:
Debian Release: 12.7
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-25-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dump depends on:
ii libblkid1 2.38.1-5+deb12u1
ii libbz2-1.01.0.8-5+b1
ii libc6 2.36-9+deb12u8
ii libcom-err2 1.47.0-2
ii libext2fs21.47.0-2
ii liblzo2-2 2.10-2
ii libreadline8 8.2-1.3
ii libselinux1 3.4-1+b6
ii tar 1.34+dfsg-1.2+deb12u1
ii zlib1g1:1.2.13.dfsg-1
dump recommends no packages.
dump suggests no packages.
-- no debconf information
diff -urN dump-0.4b47.orig/common/slave.h dump-0.4b47/common/slave.h
--- dump-0.4b47.orig/common/slave.h 2021-01-01 15:05:15.0 +
+++ dump-0.4b47/common/slave.h 2021-01-01 15:05:15.0 +
@@ -17,6 +17,7 @@
struct req {
ext2_loff_t dblk;
int count;
+ int uninit;
};
#define SLAVES 3 /* 1 slave writing, 1 reading, 1 for slack */
diff -urN dump-0.4b47.orig/dump/dump.h dump-0.4b47/dump/dump.h
--- dump-0.4b47.orig/dump/dump.h2022-05-03 10:02:27.0 +
+++ dump-0.4b47/dump/dump.h 2022-05-03 10:02:27.0 +
@@ -140,7 +140,7 @@
intmapdirs (dump_ino_t maxino, long long *tapesize);
/* file dumping routines */
-void blksout (blk64_t *blkp, int frags, dump_ino_t ino);
+void blksout (blk64_t *blkp, int frags, dump_ino_t ino, int uninit);
void bread (ext2_loff_t blkno, char *buf, size_t size);
void dumpino (struct dinode *dp, dump_ino_t ino, int metaonly);
#ifdef __linux__
@@ -153,7 +153,7 @@
/* tape writing routines */
intalloctape (void);
void close_rewind (void);
-void dumpblock (blk64_t blkno, int size);
+void dumpblock (blk64_t blkno, int size, int uninit);
void startnewtape (int top);
time_t trewind (void);
void writerec (const void *dp, int isspcl);
diff -urN dump-0.4b47.orig/dump/tape.c dump-0.4b47/dump/tape.c
--- dump-0.4b47.orig/dump/tape.c2022-05-03 10:02:27.0 +
+++ dump-0.4b47/dump/tape.c 2022-05-03 10:02:27.0 +
@@ -238,6 +238,7 @@
{
slp->req[trecno].dblk = (ext2_loff_t)0;
slp->req[trecno].count = 1;
+ slp->req[trecno].uninit = 0;
/* XXX post increment triggers an egcs-1.1.2-12 bug on alpha/sparc */
*(union u_spcl *)(*(nextblock)) = *(union u_spcl *)dp;
@@ -254,7 +255,7 @@
}
void
-dumpblock(blk64_t blkno, int size)
+dumpblock(blk64_t blkno, int size, int uninit)
{
int avail, tpblks;
ext2_loff_t dblkno;
@@ -264,6 +265,7 @@
while ((avail = MIN(tpblks, ntrec - trecno)) > 0) {
slp->req[trecno].dblk = dblkno;
slp->req[trecno].count = avail;
+ slp->req[trecno].uninit = uninit;
trecno += avail;
spcl.c_tapea += avail;
if (trecno >= ntrec)
@@ -1220,8 +1222,12 @@
trecno += p->count, p += p->count) {
if (p->dblk) { /* read a disk block */
- bread(p->dblk, slp->tblock[trecno],
- p->count * TP_BSIZE);
+ if(p->uninit) {
+ memset(slp->tblock[trecno], 0, p->count
* TP_BSIZE);
+ } else {
+ bread(p->dblk, slp->tblock[trecno],
+ p->count * TP_BSIZE);
+ }
} else {/* read record from pipe */
if (p->count != 1 || dump_atomic_read( cmd,
(char *)slp->tblock[trecno],
diff -urN dump-0.4b47.orig/dump/traverse.c dump-0.4b47/dump/traverse.c
--- dump-0.4b47.orig/dump/traverse.c2021-01-01 16:28:57.0 +
+++ dump-0.4b47/dump/traverse.c 2021-01-01 16:28:57.0 +
@@ -752,6 +752,7 @@
int cnt;
int max;
int next_block;
+ int uninit;
Bug#1081011: dump: Restore of directory attributes fails if they're split across two blocks.
Package: dump
Version: 0.4b47-4+~tjw12r5
Severity: important
Dear Maintainer,
Many years ago I reported a bug with verifying attributes on files where
the count was sometimes wrong. You fixed this (Thanks!)
However, it turns out the same bug is present for directories too.
Unfortunately, the fix for files meant that directories *verified*
correctly but did not restore correctly.
The attached patch *replaces* the xattr_verify patch currently in the
package and includes fix for the directory attributes which now both
restore and verify successfully.
(I haven't actually tested failure cases for the verify yet - i.e.
adding, removing or modifying an attribute between backup and verify)
-- System Information:
Debian Release: 12.7
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-25-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dump depends on:
ii libblkid1 2.38.1-5+deb12u1
ii libbz2-1.01.0.8-5+b1
ii libc6 2.36-9+deb12u8
ii libcom-err2 1.47.0-2
ii libext2fs21.47.0-2
ii liblzo2-2 2.10-2
ii libreadline8 8.2-1.3
ii libselinux1 3.4-1+b6
ii tar 1.34+dfsg-1.2+deb12u1
ii zlib1g1:1.2.13.dfsg-1
dump recommends no packages.
dump suggests no packages.
-- no debconf information
diff -urN dump-0.4b47.orig/restore/dirs.c dump-0.4b47/restore/dirs.c
--- dump-0.4b47.orig/restore/dirs.c 2022-05-03 10:02:27.0 +
+++ dump-0.4b47/restore/dirs.c 2022-05-03 10:02:27.0 +
@@ -181,7 +181,7 @@
struct inotab *itp;
struct direct nulldir;
int fd;
- char xattr[XATTR_MAXSIZE];
+ char xattr[XATTR_MAXSIZE*2] = {0};
int xattr_found = 0;
_Bool is_tmp = command != 'r' && command != 'R';
dump_ino_t ino;
@@ -248,7 +248,7 @@
skipfile();
break;
case EXT_XATTR:
- if (readxattr(xattr) == GOOD)
+ if (readxattr(xattr+xattr_found*XATTR_MAXSIZE)
== GOOD)
xattr_found = 1;
break;
}
@@ -667,14 +667,14 @@
}
clearerr(mf);
for (;;) {
- char xattr[XATTR_MAXSIZE];
+ char xattr[XATTR_MAXSIZE*2];
if (fread((char *)&node, sizeof(struct modeinfo), 1, mf) != 1) {
if (feof(mf))
break;
err(1, "fread");
}
if (node.xattr) {
- if (fread(xattr, XATTR_MAXSIZE, 1, mf) != 1) {
+ if (fread(xattr, XATTR_MAXSIZE*2, 1, mf) != 1) {
if (feof(mf))
break;
err(1, "fread");
@@ -701,8 +701,13 @@
warn("chown");
(void) chmod(cp, node.mode);
utimes(cp, node.timep);
- if (node.xattr)
+ if (node.xattr) {
xattr_extract(cp, xattr);
+ char* xattr2 = xattr + XATTR_MAXSIZE;
+ if (*(uint32_t*)xattr2 != 0) {
+ xattr_extract(cp, xattr2);
+ }
+ }
ep->e_flags &= ~NEW;
if (node.flags)
#ifdef __linux__
@@ -746,14 +751,14 @@
}
clearerr(mf);
for (;;) {
- char xattr[XATTR_MAXSIZE];
+ char xattr[XATTR_MAXSIZE*2];
if (fread((char *)&node, sizeof(struct modeinfo), 1, mf) != 1) {
if (feof(mf))
break;
err(1, "fread");
}
if (node.xattr) {
- if (fread(xattr, XATTR_MAXSIZE, 1, mf) != 1) {
+ if (fread(xattr, XATTR_MAXSIZE*2, 1, mf) != 1) {
if (feof(mf))
break;
err(1, "fread");
@@ -805,14 +810,32 @@
}
}
#endif
+ int xattr_count_all = 0;
if (node.xattr) {
+ int xattr_count_thisblock;
if (xattr_compare(cp, xattr) == FAIL)
do_compare_error;
+ xattr_count(xattr, &xattr_count_thisblock);
+ xattr_count_all
Bug#1081008: Multi-tape backups have a separate issue.
There is a separate issue which I think only applies if the backup itself has over 2^32 blocks written to tape so that the next tape starting block has wrapped. I haven't tried to reproduce this issue as I do not have any systems with anything like that amount of data to test with plus I suspect it will take a very long time to reproduce. This doesn't affect this bug which, as per testcase.sh, can be reproduced with only 10MB of data being dumped. I'm not reporting this other issue unless/until I can reproduce it somehow - particularly as I believe it will require a format change to the tape header and I backup via a pipe to a file rather than a tape device so I would never hit this even with 12T of data to backup. 12TB sparse files might make this reproduceable - I haven't tried, nor have I looked in detail yet how sparse files are represented on tape.
Bug#1081008: Info received (Multi-tape backups have a separate issue.)
I should have been clearer originally - this particular patch isn't my work, it was suggested upstream in https://sourceforge.net/p/dump/bugs/174/ I picked it up while trying to fix the uninitialized read bug #1081009. That patch changes the same lines of code in one place so it was slightly easier for me to keep this patch rather than rework the other one which is why I've now reported it here now. My only contribution is a small testcase that doesn't require 12TB of data to reproduce.
Bug#1081008: Info received (Bug#1081008: Info received (Multi-tape backups have a separate issue.))
I've found a bug in the original patches where it wasn't correctly
dumping an EA block >2^32. The original patch also relied on a cast to a
64 bit value which only worked on little endian and only if the next
four bytes were zero (which they appear to always be)
This patch now addresses both those problems.
I changed compat/include/bsdcompat.h. I can't find where this file is
originally from and so whether there's an official version that could be
imported that has the relevant updates.
This change isn't strictly necessary, di_pad1 could be used in place of
osd2.linux2.l_i_file_acl_high but I thought this was preferable.
testcase.sh
Description: Bourne shell script
diff -urN dump-0.4b47.orig/compat/include/bsdcompat.h dump-0.4b47/compat/include/bsdcompat.h
--- dump-0.4b47.orig/compat/include/bsdcompat.h 2021-01-01 16:28:57.0 +
+++ dump-0.4b47/compat/include/bsdcompat.h 2021-01-01 16:28:57.0 +
@@ -115,32 +115,58 @@
#endif /* sunos */
struct dinode {
- __u16 di_mode;
+/*00*/ __u16 di_mode;
__u16 di_uid;
__u32 di_size;
__u32 di_atime;
__u32 di_ctime;
- __u32 di_mtime;
+/*10*/ __u32 di_mtime;
__u32 di_dtime;
__u16 di_gid;
__u16 di_nlink;
__u32 di_blocks;
- __u32 di_flags;
- __u32 di_reserved1;
- __u32 di_db[NDADDR];
+/*20*/ __u32 di_flags;
+ union {
+ struct {
+ __u32 l_di_version; /* linux was di_reserved1 */
+ } linux1;
+ struct {
+ __u32 h_di_translator; /* hurd */
+ } hurd1;
+ } osd1; /* was di_reserved1 */
+/*28*/ __u32 di_db[NDADDR];
__u32 di_ib[NIADDR];
- __u32 di_gen;
+/*64*/ __u32 di_gen;
__u32 di_file_acl;
__u32 di_dir_acl;
- __u32 di_faddr;
- __u8 di_frag;
- __u8 di_fsize;
- __u16 di_pad1;
- __u16 di_uidhigh;
- __u16 di_gidhigh;
- __u32 di_spare;
- __u16 di_extraisize;
- __u16 di_pad2;
+/*70*/ __u32 di_faddr;
+ union {
+ struct {
+ __u16 l_i_blocks_hi;
+ __u16 l_i_file_acl_high;
+ __u16 l_i_uid_high;
+ __u16 l_i_gid_high;
+ __u16 l_i_checksum_lo;
+ __u16 l_i_reserved;
+ } linux2;
+ struct {
+ __u8 di_frag;
+ __u8 di_fsize;
+ __u16 di_mode_high; /* was di_pad1 */
+ __u16 di_uidhigh;
+ __u16 di_gidhigh;
+ __u32 di_spare;
+ } hurd2;
+ } osd2;
+/*80*/ __u16 di_extraisize;
+ __u16 i_checksum_hi; /* crc32c(uuid+inum+inode) */ /* was di_pad2 */
+ __u32 i_ctime_extra; /* extra Change time (nsec << 2 | epoch) */
+ __u32 i_mtime_extra; /* extra Modification time (nsec << 2 | epoch) */
+ __u32 i_atime_extra; /* extra Access time (nsec << 2 | epoch) */
+/*90*/ __u32 i_crtime; /* File creation time */
+ __u32 i_crtime_extra; /* extra File creation time (nsec << 2 | epoch)*/
+ __u32 i_version_hi; /* high 32 bits for 64-bit version */
+/*9c*/ __u32 i_projid; /* Project ID */
};
#define di_rdev di_db[0]
diff -urN dump-0.4b47.orig/dump/dump.h dump-0.4b47/dump/dump.h
--- dump-0.4b47.orig/dump/dump.h 2022-05-03 10:02:27.0 +
+++ dump-0.4b47/dump/dump.h 2022-05-03 10:02:27.0 +
@@ -140,8 +140,8 @@
int mapdirs (dump_ino_t maxino, long long *tapesize);
/* file dumping routines */
-void blksout (blk_t *blkp, int frags, dump_ino_t ino);
-void bread (ext2_loff_t blkno, char *buf, int size);
+void blksout (blk64_t *blkp, int frags, dump_ino_t ino);
+void bread (ext2_loff_t blkno, char *buf, size_t size);
void dumpino (struct dinode *dp, dump_ino_t ino, int metaonly);
#ifdef __linux__
void dumpdirino (struct dinode *dp, dump_ino_t ino);
@@ -153,7 +153,7 @@
/* tape writing routines */
int alloctape (void);
void close_rewind (void);
-void dumpblock (blk_t blkno, int size);
+void dumpblock (blk64_t blkno, int size);
void startnewtape (int top);
time_t trewind (void);
void writerec (const void *dp, int isspcl);
diff -urN dump-0.4b47.orig/dump/tape.c dump-0.4b47/dump/tape.c
--- dump-0.4b47.orig/dump/tape.c 2022-05-03 10:02:27.0 +
+++ dump-0.4b47/dump/tape.c 2022-05-03 10:02:27.0 +
@@ -254,7 +254,7 @@
}
void
-dumpblock(blk_t blkno, int size)
+dumpblock(blk64_t blkno, int size)
{
int avail, tpblks;
ext2_loff_t dblkno;
diff -urN dump-0.4b47.orig/dump/traverse.c dump-0.4b47/dump/traverse.c
--- dump-0.4b47.orig/dump/traverse.c 2021-01-01 16:28:57.0 +
+++ dump-0.4b47/dump/traverse.c 2021-01-01 16:28:57.0 +
@@ -748,7 +748,7 @@
struct block_context {
ext2_ino_t ino;
- blk_t *buf;
+ blk64_t *buf;
int cnt;
int max;
int next_block;
@@ -758,8 +758,8 @@
* Dump a block to the tape
*/
static int
-dumponeblock(UNUSED(ext2_filsys fs), blk_t *blocknr, e2_blkcnt_t blockcnt,
- UNUSED(blk_t ref_block), UNUSED(int ref_offset), void * private)
+dumponeblock(UNUSED(ext2_filsys fs), blk64_t *blocknr, e2_blkcnt_t blockcnt,
+ UNUSED(blk64_t ref_block), UNUSED(int ref_offset), void * private)
{
struct block_context *p;
e2_blkcnt_t i;
@@ -831,7 +831,7 @@
#endif
}
- if (dp->di_file_acl) {
+ if (dp->di_file_acl || dp->osd2.linux2.l_i_file_acl_high) {
if (vflag)
msg("dumping EA (block) in inode #%ld\n", (long)ino);
@@ -840,7
Bug#510679: sendmail-bin: sendmail init scripts need /bin/ps but sendmail does not depend on procps
Package: sendmail-bin Version: 8.14.3-5 Severity: minor It's possible to install sendmail without having the procps package installed. However /etc/init.d/sendmail uses ps to determine if sendmail is running. Tim. -- Package-specific info: Ouput of /usr/share/bug/sendmail-bin/script: Versions of packages sendmail-bin depends on: ii libc62.7-16 GNU C Library: Shared libraries ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [ ii libldap-2.4-22.4.11-1OpenLDAP libraries ii liblockfile1 1.08-3 NFS-safe locking library, includes ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra ii libssl0.9.8 0.9.8g-14 SSL shared libraries ii libwrap0 7.6.q-16Wietse Venema's TCP wrappers libra ii sendmail-base8.14.3-5powerful, efficient, and scalable ii sendmail-cf 8.14.3-5powerful, efficient, and scalable sendmail-bin recommends no packages. Versions of packages sendmail-bin suggests: ii libsasl2-modules 2.1.22.dfsg1-23 Cyrus SASL - pluggable authenticat ii openssl 0.9.8g-14 Secure Socket Layer (SSL) binary a ii sasl2-bin2.1.22.dfsg1-23 Cyrus SASL - administration progra ii sendmail-doc 8.14.3-5powerful, efficient, and scalable Versions of packages sensible-mda depends on: ii libc6 2.7-16 GNU C Library: Shared libraries ii procmail 3.22-16Versatile e-mail processor Versions of packages rmail depends on: ii libc6 2.7-16 GNU C Library: Shared libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#409243: Happens for me too
I've had exactly the same problem. Upgraded to etch with 2.4 kernel - everything working fine. Upgraded to 2.6 kernel - won't boot. In the rescue shell, vgchange -ay vg0 gives "no volumes group found". Everything is at the latest version in etch. partition table is /dev/hda1 for /boot /dev/hda2 for lvm2 I had another identical machine that I'd also upgraded to etch with no problem. The difference is that the other machine was set up with the two partitions on raid1. (Only one harddisk, the second disk is missing, I set it up like this so that I could eventually have the machine on raid1 once I get a bigger case) So I picked the initrd from the working machine and tried it on the failing machine. I got an error about cannot run fsck on /dev/hda1 but the machine eventually booted up fine. I rebuilt /boot on raid1 and hacked /dev/hda2 to be /dev/md1 without actually rebuilding which seems to have worked. So now the machine boots fine in both 2.4 and 2.6 kernels. [EMAIL PROTECTED]:~$ cat /proc/mdstat Personalities : [raid1] md1 : active raid1 hda2[1] 78011520 blocks [2/1] [_U] md0 : active raid1 hda1[1] 136448 blocks [2/1] [_U] unused devices: feynman:~# pvdisplay --- Physical volume --- PV Name /dev/md1 VG Name vg0 PV Size 74.39 GB / not usable 0 Allocatable yes PE Size (KByte) 4096 Total PE 19045 Free PE 4045 Allocated PE 15000 PV UUID F06AQv-OVlE-iWtJ-31S6-uHKM-yyN7-wFQTZv feynman:~# vgdisplay --- Volume group --- VG Name vg0 System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 1384 VG Access read/write VG Status resizable MAX LV0 Cur LV7 Open LV 7 Max PV0 Cur PV1 Act PV1 VG Size 74.39 GB PE Size 4.00 MB Total PE 19045 Alloc PE / Size 15000 / 58.59 GB Free PE / Size 4045 / 15.80 GB VG UUID qmBCTP-vIh6-h5AU-jT8a-o31r-48HB-heEAio feynman:~# mdadm -D /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Sat Apr 28 19:06:01 2007 Raid Level : raid1 Array Size : 136448 (133.27 MiB 139.72 MB) Device Size : 136448 (133.27 MiB 139.72 MB) Raid Devices : 2 Total Devices : 1 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Sun Apr 29 08:21:25 2007 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 UUID : 08972485:1bf5fbf2:efc3b31c:59f53a25 (local to host feynman.home.woodall.me.uk) Events : 0.52 Number Major Minor RaidDevice State 0 000 removed 1 311 active sync /dev/hda1 feynman:~# mdadm -D /dev/md1 /dev/md1: Version : 00.90.03 Creation Time : Mon Jan 1 21:52:19 2007 Raid Level : raid1 Array Size : 78011520 (74.40 GiB 79.88 GB) Device Size : 78011520 (74.40 GiB 79.88 GB) Raid Devices : 2 Total Devices : 1 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Sun Apr 29 15:40:42 2007 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 UUID : 98098d82:05ea0a3f:656f116f:b86d5f02 Events : 0.12638 Number Major Minor RaidDevice State 0 000 removed 1 321 active sync /dev/hda2 Tim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409243: Info received (Happens for me too)
I've just found this comment attached to bug#381351: "I just did a bit of investigation into a slimilar issue - it seems that the image created by initramfs-tools doesn't work with LVM if mdadm is not installed." I suspect that this was my problem as I didn't have mdadm installed. It may be the original reporters problem as well. Tim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484823: multipath-tools: /etc/udev/rules.d/multipath.rules breaks LVM snapshots
Package: multipath-tools Version: 0.4.7-1.1etch1 Severity: normal The /etc/udev/rules.d/multipath.rules exposes a race that causes LVM snapshots to fail to be created intermittently. This caused my backups to suddenly start failing when I installed this package to get kpartx. /sbin/lvcreate -A n -L500M -s -nroot-backup /dev/vg0/root LV vg0/root-backup in use: not deactivating Couldn't deactivate new snapshot. This seems closely related to bug 343671. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484823: multipath-tools: /etc/udev/rules.d/multipath.rules breaks LVM snapshots
On Sat, 7 Jun 2008, Guido Günther wrote: On Fri, Jun 06, 2008 at 10:33:36PM +0100, Tim Woodall wrote: The /etc/udev/rules.d/multipath.rules exposes a race that causes LVM snapshots to fail to be created intermittently. You mean: # take care of devmap partitioning ACTION=="add", SUBSYSTEM=="block", KERNEL=="dm-*", \ PROGRAM="/sbin/dmsetup -j %M -m %m --noopencount --noheadings -c -o name info", \ RUN+="/sbin/kpartx -a /dev/mapper/%c" Does changing ACTION="add" into ACTION="change" do any good? Yes. That seems to fix my LVM problem. I'm using the following simple test script: feynman:~# cat testlvm #!/bin/bash for i in $( seq 1 10 ); do /sbin/lvcreate -A n -L500M -s -nroot-backup /dev/vg0/root sleep 2 /sbin/lvremove -A n -f /dev/vg0/root-backup sleep 2 done exit 0 With the ACTION=="add" a typical run looks like this: (note that the machine has to be idle. If there's lots of disk access then the LVM snapshot seems to work regardless) feynman:~# ./testlvm Logical volume "root-backup" created Logical volume "root-backup" successfully removed Logical volume "root-backup" created Logical volume "root-backup" successfully removed Logical volume "root-backup" created Logical volume "root-backup" successfully removed Logical volume "root-backup" created Logical volume "root-backup" successfully removed LV vg0/root-backup in use: not deactivating Couldn't deactivate new snapshot. Logical volume "root-backup" successfully removed Logical volume "root-backup" created Logical volume "root-backup" successfully removed LV vg0/root-backup in use: not deactivating Couldn't deactivate new snapshot. Logical volume "root-backup" successfully removed LV vg0/root-backup in use: not deactivating Couldn't deactivate new snapshot. Logical volume "root-backup" successfully removed LV vg0/root-backup in use: not deactivating Couldn't deactivate new snapshot. Logical volume "root-backup" successfully removed Logical volume "root-backup" created Logical volume "root-backup" successfully removed I've never had fewer than 2 failures (20%) running this script with the multipath.rules script when the machine is idle. With the add replaced with change, or the udev rule removed completely I've never seen a failure. Do you have a chance to try the packages from lenny? Kpartx is split out into a separate package there and the udev rules are much more robust. There are packports of this versions available here: http://debian.bzed.de/etch-backports/devmapper_1.02.24-4~bpo40+1.dsc http://debian.bzed.de/etch-backports/multipath-tools_0.4.8-7~bpo40+1.dsc Not easily on this machine. But I can probably test on another machine if it would help you. Note that I've not tested if that add->change breaks anything else. I'm not even sure how to test this udev rule. Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://www.woodall.me.uk/http://www.locofungus.btinternet.co.uk/
Bug#484823: multipath-tools: /etc/udev/rules.d/multipath.rules breaks LVM snapshots
On Sat, 7 Jun 2008, Guido Günther wrote: On Sat, Jun 07, 2008 at 04:07:49PM +0100, Tim Woodall wrote: With the add replaced with change, or the udev rule removed completely I've never seen a failure. O.k. find. A mark the bug as fixed in lenny then. Do you have a chance to try the packages from lenny? Kpartx is split out into a separate package there and the udev rules are much more robust. There are packports of this versions available here: http://debian.bzed.de/etch-backports/devmapper_1.02.24-4~bpo40+1.dsc http://debian.bzed.de/etch-backports/multipath-tools_0.4.8-7~bpo40+1.dsc Not easily on this machine. But I can probably test on another machine if it would help you. Yes, this would help indeed. So we can be really sure that this is fixed in lenny. Ok. I've not been able to reliably reproduce the problem on any other machine. So I've done the following - hope this is sufficient for you: Taken the multipath-tools*.tar.gz and extracted it on another etch machine. Built it with fakeroot ./debian/rules binary Copied the kpartx deb and multipath-tools deb to feynman and installed them. Then rerun my test which seems to work correctly. I've not seen any failures. I haven't done anything with devmapper. Not sure if that matters or not for you but I don't really want to start replacing existing packages on this machine even temporarily and I assume that will replace libdevmapper. Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://www.woodall.me.uk/http://www.locofungus.btinternet.co.uk/
Bug#312844: console-tools: Same problem attempting to build the keyboard map for psion-5mx kernel
Package: console-tools Version: 1:0.2.3dbs-56 Followup-For: Bug #312844 I'm having exactly the same problem while attempting to build a kernel for the psion 5mx (http://linux-7110.sourceforge.net/) This contains a number of special keycodes for controlling things like backlight, contrast, power off etc. The codes are thing like: altgr keycode 61 = 0xf03 # Backlight loadkeys --mktable keymap_psion_us.map >keymap_psion_us.c For console-tools_0.2.3-23.3 this build the map file correctly. For console-tools_0.2.3dbs-56 this replaces all the 0xff0? values with 0xf020 - 0xf200, 0xf117, 0xf114, 0xf200, 0xf118, 0xff03, 0xf10d, 0xfc00, + 0xf200, 0xf117, 0xf114, 0xf200, 0xf118, 0xf020, 0xf10d, 0xfc00, And console-tools_0.2.3dbs-60 has the same problem except that it additionally requires you to run this as root otherwise you get: $ ./console-tools_0.2.3dbs-60/bin/loadkeys --mktable keymap_psion_us.map Couldnt get a file descriptor referring to the console KDGKBMODE: Bad file descriptor loadkeys: error reading keyboard mode $ The following patch to the function add_number fixes this issue (but may cause other problems) --- ksyms.c.orig2006-04-01 09:32:27.0 +0100 +++ ksyms.c 2006-04-01 10:02:15.0 +0100 @@ -1826,7 +1826,7 @@ } if (kbd_mode != K_UNICODE && KTYP(code) < syms_size) return code; - return ksymtocode(codetoksym(code)); + return code; } int The cause here is that the 0xf03 in the map file is being converted into a symbol and then back into the code. And it therefore rejected if there is no mapping for this character. I also don't understand why there are all the: ioctl(fd, KDGKBMODE, &kbd_mode); when we are running with --mktable. AFAICT we shouldn't even be touching the console (nor require running as root). I think this is probably the underlying cause although I'm not completely clear how this should be fixed. I think that if we are running with --mktable we should not be looking at the console at all but maybe need to consider whether -u was on the commandline? (When I'm building the psion-5mx kernel I'm doing a cross compile. So not only is loadkeys looking at the console on the wrong machine, it's the wrong architecture and hardware as well) Tim. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-3-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages console-tools depends on: ii console-common 0.7.49Basic infrastructure for text cons ii debconf1.4.30.13 Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libconsole 1:0.2.3dbs-56 Shared libraries for Linux console ii sysvinit 2.86.ds1-1System-V like init -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312844: console-tools: Same problem attempting to build the keyboard map for psion-5mx kernel
I've now constructed a patch that fixes this problem for me. (I don't
think this will fix the original problem as that was running loadkeys
without --mktable)
I now do:
LD_PRELOAD=./libconsole.so ./loadkeys -u --mktable keymap_psion_us.map
>keymap_psion_us.patch.c
and the mapfile is created correctly and there is no attempt to access
the console.
(This patch is against sarge. If you want it against unstable then let
me know and I'll do that)
Tim.
diff -aur console-tools-0.2.3.orig/include/lct/ksyms.h
console-tools-0.2.3/include/lct/ksyms.h
--- console-tools-0.2.3.orig/include/lct/ksyms.h2006-04-01
10:44:24.0 +0100
+++ console-tools-0.2.3/include/lct/ksyms.h 2006-04-01 10:46:07.0
+0100
@@ -21,8 +21,8 @@
extern const int charsets_size;
extern int set_charset(const char *name);
-extern int add_number(int code);
-extern int add_capslock(int code);
+extern int add_number(int code, const int *kbd_mode);
+extern int add_capslock(int code, const int *kbd_mode);
extern const char *codetoksym(int code);
extern void list_charsets(FILE *f);
diff -aur console-tools-0.2.3.orig/kbdtools/analyze.l
console-tools-0.2.3/kbdtools/analyze.l
--- console-tools-0.2.3.orig/kbdtools/analyze.l 2006-04-01 10:42:22.0
+0100
+++ console-tools-0.2.3/kbdtools/analyze.l 2006-04-01 10:59:26.0
+0100
@@ -6,10 +6,11 @@
#include
#include "loadkeys.h"
-extern int ksymtocode(char *s);
+extern int ksymtocode(char *s, const int *kbd_mode);
extern int line_nr;
extern int verbose; /* loadkeys.y */
+extern const int *p_kbd_mode;/* loadkeys.y */
extern char pathname[]; /* idem */
intyylval;
intrvalct;
@@ -88,7 +89,7 @@
\+ {return(PLUS);}
{Unicode} {yylval=strtol(yytext+1,NULL,16) ^
0xf000;return(UNUMBER);}
{Decimal}|{Octal}|{Hex}{yylval=strtol(yytext,NULL,0);return(NUMBER);}
-{Literal}
{return((yylval=ksymtocode(yytext))==-1?ERROR:LITERAL);}
+{Literal}{return((yylval=ksymtocode(yytext,
p_kbd_mode))==-1?ERROR:LITERAL);}
{Charset} {return(CHARSET);}
{Keymaps} {return(KEYMAPS);}
{Keycode} {return(KEYCODE);}
diff -aur console-tools-0.2.3.orig/kbdtools/loadkeys.y
console-tools-0.2.3/kbdtools/loadkeys.y
--- console-tools-0.2.3.orig/kbdtools/loadkeys.y2006-04-01
10:46:55.0 +0100
+++ console-tools-0.2.3/kbdtools/loadkeys.y 2006-04-01 11:09:36.0
+0100
@@ -85,6 +85,9 @@
int lk_pop(void);/* idem */
extern int infile_stack_ptr; /* idem */
+static int kbd_mode = K_RAW; /* Default kbd mode if
running with -m */
+const int *p_kbd_mode;
+
#ifndef KT_LETTER
#define KT_LETTER KT_LATIN
#endif
@@ -285,17 +288,17 @@
}
;
rvalue : NUMBER
- {$$=add_number($1);}
+ {$$=add_number($1, p_kbd_mode);}
| LITERAL
- {$$=add_number($1);}
+ {$$=add_number($1, p_kbd_mode);}
| UNUMBER
- {$$=add_number($1);}
+ {$$=add_number($1, p_kbd_mode);}
| PLUS NUMBER
-{$$=add_capslock($2);}
+{$$=add_capslock($2, p_kbd_mode);}
| PLUS UNUMBER
- {$$=add_capslock($2);}
+ {$$=add_capslock($2, p_kbd_mode);}
| PLUS LITERAL
-{$$=add_capslock($2);}
+{$$=add_capslock($2, p_kbd_mode);}
;
%%
@@ -380,6 +383,7 @@
case 'm':
optm = 1;
quiet = 1;
+ p_kbd_mode = &kbd_mode;
break;
case 's':
opts = 1;
@@ -389,6 +393,7 @@
break;
case 'u':
set_charset("unicode");
+ kbd_mode = K_UNICODE;
break;
case 'v':
verbose++;
diff -aur console-tools-0.2.3.orig/lib/ksyms.c console-tools-0.2.3/lib/ksyms.c
--- console-tools-0.2.3.orig/lib/ksyms.c2006-04-01 09:32:27.0
+0100
+++ console-tools-0.2.3/lib/ksyms.c 2006-04-01 10:49:16.0 +0100
@@ -1711,12 +1711,12 @@
/* Functions for loadkeys. */
int
-ksymtocode(const char *s) {
+ksymtocode(const char *s, const int *kbd_mode) {
int i;
int j;
int keycode;
static int fd = -1;
- int kbd_mode;
+ int lcl_kbd_mode;
int syms_start = 0;
sym *p;
@@ -1725,21 +1725,25 @@
return -1;
}
- if (fd < 0)
- fd = get_console_fd(NULL);
- ioctl(fd, KDGKBMODE, &kbd_mode);
+ if(kbd_mode)
+ lcl_kbd_mode = *kbd_mode;
+ else {
+ if (fd < 0)
+ fd = get_console_fd(NULL);
+ io
Bug#312844: loadkeys -m -u for building psion kernel already fixed in Sid.
I've discovered that the version of loadkeys in Sid already fixes the problem building the keyboard map for the psion if you supply the -u option. Still have the problem that you must be root (patch in bug #341956 that fixes this) Has the original poster tried using loadkeys with the -u flag? Or the version from Sid with the -u flag? This might also fix their problem. Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341956: Also resolves issues in bug #312844
The version in Sid, together with this patch, also fixes the problems I've reported in Bug #312844 Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341956: Same problem in package kbd.
Identical problem, fixed by same patch, in package kbd. (Patch is same change, but the above patch will not apply to the source in kbd - the indenting is different) Can this bug also be attached to package kbd? Or does a new bug need opening? Tim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345362: Data is stale - problems with belkin driver.
Bother - what I meant to say in that last message and forgot is the following that is extremely annoying: Apr 3 22:54:49 pauli upsd[981]: Data for UPS [belkin] is stale - check driver Apr 3 22:54:50 pauli upsmon[985]: Poll UPS [EMAIL PROTECTED] failed - Data stale Apr 3 22:54:50 pauli upsmon[985]: Communications with UPS [EMAIL PROTECTED] lost Apr 3 22:54:51 pauli upsd[981]: UPS [belkin] data is no longer stale Apr 3 22:54:55 pauli upsmon[985]: Communications with UPS [EMAIL PROTECTED] established Apr 3 22:54:55 pauli upsmon[985]: UPS [EMAIL PROTECTED] on battery Apr 3 22:54:55 pauli upsmon[985]: UPS [EMAIL PROTECTED] battery is low Apr 3 22:54:55 pauli upsd[981]: Client [EMAIL PROTECTED] set FSD on UPS [belkin] Apr 3 22:54:55 pauli upsmon[985]: Executing automatic power-fail shutdown This has happened to me twice. And on neither occasion was the ups on battery even for a moment. Nor was the battery low. I suspect that this was reading bad data from the ups when it reestablished the connection. Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345362: Seen similar problem with belkin driver
I'm seeing a similar problem with the belkin driver attached to the serial port. Nut Version: 2.0.1-4 pauli:/etc/nut# uname -a Linux pauli.home.woodall.me.uk 2.4.27-3-k6 #1 Wed Feb 8 12:52:54 UTC 2006 i586 GNU/Linux In my case this seems to be caused by using the scanner which is attached by an old ISA scsi port (g_NCR5380). I've tried renice -20 on all the ups drivers and monitor but even that didn't help. What's a bit strange is that ssh etc still seems responsive while the scan is in progress. It just appears that it's the belkin driver that can't talk to the serial port while the scanner is running. (Note: I get the same problem if I attempt to run a ppp link over the serial link while using the scanner) I'm not too worried, this problem doesn't happen when I use an adaptec 2940 card - only reason I'm using the g_NCR5380 card is because it's an old machine with only 3 pci slots which are already filled - anyone know where I can get an old ISA bus video card from? ;-) Hope this might be of some use tracking down the problem. Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#520633: xscreensaver: screen does not lock if switched to virtual terminal
On Fri, 25 Sep 2009, Jose Luis Rivas wrote: Hi Tim, What Jamie says is easy to check, just see the log of xscreensaver and check if this is the case. If that's true then this bug should be reassigned. I'm still not able to find any logs for xscreensaver at all. But I now think that I'm not running xscreensaver at all - I think I must be running a screensaver built into KDE. (I've uninstalled xscreensaver* but my screensaver is still running) I think this needs to be assigned to kscreensaver instead. Sorry for the confusion. Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://www.woodall.me.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520633: xscreensaver: screen does not lock if switched to virtual terminal
This is still happening. I've not found a way to fix it. There was an earlier comment about checking xscreensaver logs but I don't know where these logs are. Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614068: Dump fails to dump some files with leading zeros correctly
Package: dump
Version: 0.4b43-1
Severity: important
Tags: upstream patch
einstein:~# /sbin/dump -0 -f- /var/spool/news/overview/ | restore -oax -f-
DUMP: Date of this level 0 dump: Sat Feb 19 13:27:45 2011
DUMP: Dumping /dev/mapper/vg0-var (/var (dir /spool/news/overview)) to
standard output
DUMP: Label: none
DUMP: Writing 10 Kilobyte records
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 23168 blocks.
DUMP: Volume 1 started with block 1 at: Sat Feb 19 13:27:46 2011
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
Missing blocks at the end of ./spool/news/overview/f/l/k/fa.linux.kernel.IDX,
assuming hole
Missing blocks at the end of ./spool/news/overview/u/t/uk.test.IDX, assuming
hole
...
Missing blocks at the end of ./spool/news/overview/c/t/t/comp.text.tex.IDX,
assuming hole
DUMP: Volume 1 completed at: Sat Feb 19 13:27:49 2011
DUMP: Volume 1 23040 blocks (22.50MB)
DUMP: Volume 1 took 0:00:03
DUMP: Volume 1 transfer rate: 7680 kB/s
DUMP: 23040 blocks (22.50MB)
DUMP: finished in 3 seconds, throughput 7680 kBytes/sec
DUMP: Date of this level 0 dump: Sat Feb 19 13:27:45 2011
DUMP: Date this dump completed: Sat Feb 19 13:27:49 2011
DUMP: Average transfer rate: 7680 kB/s
DUMP: DUMP IS DONE
einstein:~#
Problem is in version 1.67 of dump/traverse.c in the upstream code.
Backing out this one change fixes the problem.
diff -u -w -r1.67 -r1.66
--- traverse.c 18 Jun 2009 10:00:38 - 1.67
+++ traverse.c 2 May 2005 15:10:46 - 1.66
@@ -777,6 +777,8 @@
struct block_context *p;
e2_blkcnt_t i;
+ if (blockcnt < NDADDR)
+ return 0;
p = (struct block_context *)private;
for (i = p->next_block; i < blockcnt; i++) {
p->buf[p->cnt++] = 0;
@@ -984,6 +986,19 @@
msg("Warning: undefined file type 0%o\n", dp->di_mode & IFMT);
return;
}
+ if (i_size > (u_quad_t)NDADDR * sblock->fs_bsize)
+#ifdef __linux__
+ cnt = NDADDR * EXT2_FRAGS_PER_BLOCK(fs->super);
+#else
+ cnt = NDADDR * sblock->fs_frag;
+#endif
+ else
+ cnt = howmany(i_size, sblock->fs_fsize);
+ blksout(&dp->di_db[0], cnt, ino);
+ if ((quad_t) (size = i_size - NDADDR * sblock->fs_bsize) <= 0) {
+ dump_xattr(ino, dp);
+ return;
+ }
#ifdef __linux__
bc.max = NINDIR(sblock) * EXT2_FRAGS_PER_BLOCK(fs->super);
bc.buf = (int *)malloc (bc.max * sizeof (int));
@@ -991,7 +1006,7 @@
bc.ino = ino;
bc.next_block = NDADDR;
- ext2fs_block_iterate2(fs, (ext2_ino_t)ino, BLOCK_FLAG_DATA_ONLY, NULL,
dumponeblock, (void *)&bc);
+ ext2fs_block_iterate2(fs, (ext2_ino_t)ino, 0, NULL, dumponeblock, (void
*)&bc);
/* deal with holes at the end of the inode */
if (i_size > ((u_quad_t)bc.next_block) * sblock->fs_fsize) {
remaining = i_size - ((u_quad_t)bc.next_block) *
sblock->fs_fsize;
@@ -1009,15 +1024,6 @@
free(bc.buf);
dump_xattr(ino, dp);
#else
- if (i_size > (u_quad_t)NDADDR * sblock->fs_bsize)
- cnt = NDADDR * sblock->fs_frag;
- else
- cnt = howmany(i_size, sblock->fs_fsize);
- blksout(&dp->di_db[0], cnt, ino);
- if ((quad_t) (size = i_size - NDADDR * sblock->fs_bsize) <= 0) {
- dump_xattr(ino, dp);
- return;
- }
for (ind_level = 0; ind_level < NIADDR; ind_level++) {
dmpindir(ino, dp->di_ib[ind_level], ind_level, &size);
if (size <= 0)
Bug has already been reported upstream:
http://sourceforge.net/tracker/?func=detail&aid=3133762&group_id=1306&atid=101306
-- System Information:
Debian Release: 6.0
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages dump depends on:
ii e2fslibs 1.41.12-2 ext2/ext3/ext4 file system librari
ii libblkid1 2.17.2-9 block device id library
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libcomerr21.41.12-2 common error description library
ii libncurses5 5.7+20100313-5 shared libraries for terminal hand
ii libreadline6 6.1-3 GNU readline and history libraries
ii libselinux1 2.0.96-1 SELinux runtime shared libraries
ii libuuid1 2.17.2-9 Universally Unique ID library
ii tar 1.23-3 GNU version of the tar archiving u
dump recommends no packages.
dump suggests no packages.
-- debconf information:
dump/dumpdates_is_a_symlink:
dump/moving_from_etc_to_var:
--
To UNSUBSCRIBE, email to debian-bugs-dist-r
Bug#614068: Acknowledgement (Dump fails to dump some files with leading zeros correctly)
Upstream now has a fix for this. version 1.72 of traverse.c Index: traverse.c === RCS file: /cvsroot/dump/dump/dump/traverse.c,v retrieving revision 1.71 retrieving revision 1.72 diff -u -w -r1.71 -r1.72 --- traverse.c 10 Jun 2010 12:17:35 - 1.71 +++ traverse.c 21 Feb 2011 10:36:47 - 1.72 @@ -992,7 +992,7 @@ bc.buf = (int *)malloc (bc.max * sizeof (int)); bc.cnt = 0; bc.ino = ino; - bc.next_block = NDADDR; + bc.next_block = 0; ext2fs_block_iterate2(fs, (ext2_ino_t)ino, BLOCK_FLAG_DATA_ONLY, NULL, dumponeblock, (void *)&bc); /* deal with holes at the end of the inode */ -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://www.woodall.me.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#450762: Similar problem using root=UUID=.....
I've been having a similar problem trying to get lvm on raid booting
with root=UUID=...
I've managed to get it working as follows:
1. Copy /sbin/dmsetup to sbin in the initramfs.
2. Add lvm=vg0 to the kernel commandline
3. Apply the following:
diff -ur y/init x/init
--- y/init 2009-02-22 14:36:11.0 +
+++ x/init 2009-02-22 14:13:51.0 +
@@ -44,6 +44,7 @@
export panic=
export blacklist=
export resume_offset=
+export lvm=
# Bring in the main config
. /conf/initramfs.conf
@@ -98,6 +99,9 @@
resume=*)
RESUME="${x#resume=}"
;;
+ lvm=*)
+ lvm=${x#lvm=}
+ ;;
resume_offset=*)
resume_offset="${x#resume_offset=}"
;;
diff -ur y/scripts/local-top/lvm2 x/scripts/local-top/lvm2
--- y/scripts/local-top/lvm22009-02-22 14:36:11.0 +
+++ x/scripts/local-top/lvm22009-02-22 14:21:15.0 +
@@ -66,5 +66,6 @@
activate_vg "$ROOT"
activate_vg "$resume"
+[ "$lvm" != "" ] && lvm vgchange -aly --ignorelockingfailure ${lvm}
exit 0
A possible enhancement would be to change that last line to: (untested)
while [ "$lvm" != "" ]; do
lvm vgchange -aly --ignorelockingfailure ${lvm%%,*}
if [ "${lvm#*,}" = "${lvm}" ]; then
lvm=
else
lvm=${lvm#*,}
fi
done
which would allow multiple volume groups to be started (is this ever
required?)
I suspect that this will fix the root=LABEL=... issues but I don't use
LABELS and haven't tested
Note that if you use lvm= to start the volume groups (and don't use the
activate_vg) then there is no need for busybox as this merely provides
sed and tr which are no longer used.
Tim.
--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.
http://www.woodall.me.uk/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520633: xscreensaver: screen does not lock if switched to virtual terminal
Package: xscreensaver Version: 5.05-3 Severity: important If you are switched to a virtual terminal e.g. ctrl-alt-f1 then the X session does not lock. The old behaviour in etch: when you switched back to the X session ctrl-alt-f7 the screen would momentarily display the old screen before the screensaver appeared and the password dialog popped up. (assuming you had been switched away for long enough) In lenny there is no locking at all, you can switch to ctrl-alt-f1 for arbitrary lengths of time and when you switch back ctrl-alt-f7 the screen is not locked. (IMO, even the old behaviour with etch was a minor problem, if you were quick with a camera you could grab a snapshot of what was on the screen. But the current behaviour is a serious bug.) I've reproduced this problem on two different systems: EPIA-EN12000E Section "Device" Identifier "via" Driver "openchrome" VideoRam65536 BusID "PCI:1:0:0" EndSection eeepc 700 4G Section "Device" Identifier "Device1" Driver "intel" VendorName "Intel Corporation" BoardName "Mobile 915GM/GMS/910GML Express Graphics Controller" BusID "PCI:0:2:0" Option "monitor-VGA" "Monitor2" Option "monitor-LVDS" "Monitor1" Option "ModeDebug" "true" EndSection -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages xscreensaver depends on: ii libatk1.0-0 1.22.0-1The ATK accessibility toolkit ii libc62.7-18 GNU C Library: Shared libraries ii libcairo21.6.4-7 The Cairo 2D vector graphics libra ii libglade2-0 1:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.6-1+lenny1 The GLib library of C routines ii libgtk2.0-0 2.12.11-4 The GTK+ graphical user interface ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libpam0g 1.0.1-5 Pluggable Authentication Modules l ii libpango1.0-01.20.5-3Layout and rendering of internatio ii libsm6 2:1.0.3-2 X11 Session Management library ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxml2 2.6.32.dfsg-5 GNOME XML library ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library ii libxpm4 1:3.5.7-1 X11 pixmap library ii libxrandr2 2:1.2.3-1 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii libxxf86misc11:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l ii xscreensaver-data5.05-3 data files to be shared among scre Versions of packages xscreensaver recommends: ii libjpeg-progs 6b-14 Programs for manipulating JPEG fil ii perl [perl5] 5.10.0-19 Larry Wall's Practical Extraction ii wamerican [wordlist] 6-2.3 American English dictionary words pn xli | xloadimage (no description available) Versions of packages xscreensaver suggests: pn fortune(no description available) ii iceweasel [www-browser] 3.0.6-1 lightweight web browser based on M ii konqueror [www-browser] 4:3.5.9.dfsg.1-6 KDE's advanced file manager, web b ii lynx-cur [www-browser] 2.8.7dev9-2.1Text-mode WWW Browser with NLS sup pn qcam | streamer(no description available) pn xdaliclock (no description available) pn xfishtank (no description available) ii xscreensaver-gl 5.05-3 GL(Mesa) screen hacks for xscreens -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520633: xscreensaver: screen does not lock if switched to virtual terminal
Sorry, only just seen this reply. (My spamfilter thinks anything not sent via BTS is spam) Where is the xscreensaver log? I cannot see anything in Xorg.log but I'm not sure what I'm looking for. Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://www.woodall.me.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 8 Sep 2021, Helmut Grohne wrote: I do see the advantages of using https. I do not see how to not make it happen without breaking relevant use cases. Same with the /usr-merge. I do see the advantages. I've stopped counting the things that broke. Most recent one is the uucp FTBFS. Change has a cost. I do not want to pay the cost for either of these changes. This is a bit tongue in cheek, but how about these sites where the .debs are downloaded from publish their *private* key? They openly accept that anyone can MITM them. That way people who want to see "https" can see it. And people who want the benefits of http can, with a bit of work, simulate that. It also nicely addresses my concern which is that the next demand will be to drop http (because when you visit the site with a webbrowser users start getting a warning that the site is also available over http or something like that because the google/firefox dream seems to be that you cannot use http even where https doesn't add anything.)
Bug#855234: fakechroot: debootstrap --variant=fakechroot fails if systemd is not installed
Hi,
I'm seeing a similar issue trying to install build-deps.
Steps to reproduce:
Minimal system with build-essential installed running on a system that
does not have systemd installed
fakeroot fakechroot chroot ${buildchroot}
apt-get -y --only-source build-dep openssh=1:7.9p1-10+deb10u2
...
Setting up systemd (241-7~deb10u6) ...
Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service ->
/lib/systemd/system/getty@.service.
Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target ->
/lib/systemd/system/remote-fs.target.
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service ->
/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
-> /lib/systemd/system/systemd-timesyncd.service.
systemd-machine-id-setup: error while loading shared libraries:
libsystemd-shared-241.so: cannot open shared object file: No such file or
directory
dpkg: error processing package systemd (--configure):
installed systemd package post-installation script subprocess returned error
exit status 127
It can be resolved from _inside_ the chroot like this:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${buildchroot}/lib/systemd apt-get -y
--only-source build-dep openssh=1:7.9p1-10+deb10u2
Which, effectively, seems to be the same solution as was posted as a
proposed patch back in 2017. I've confirmed that the proposed patch also
fixes my issue.
This bug is tagged as fixed-upstream but I'm using 2.19-3.3 and the issue
is still present for me at least.
Bug#983115: make -t doesn't correctly touch grouped targets that are built by a recursive make
Package: make Version: 4.3-4 Severity: normal Dear Maintainer, (N.B. I've backported make 4.3-4 to buster as I need grouped targets but I have made no changes other than to depend on guile-2.2-dev instead of guile-3.0-dev) In some cases you need to run make -t multiple times to touch all the targets of a grouped target that should all be built by a single invocation of a recipe. Example makefile to build debs from a dsc: $ cat Makefile chroot=/tmp/chroot TARGETS=libfoo.deb foo.deb all : $(TARGETS) $(TARGETS) &: foo.dsc #fakeroot fakechroot chroot $(chroot) $(MAKE) -C /build chroot-foo $(MAKE) chroot-foo cp $(chroot)/build/libfoo.deb libfoo.deb cp $(chroot)/build/foo.deb foo.deb .PHONY: chroot-foo chroot-foo: apt-get -y build-dep foo cd foo-1.1 && dpkg-buildpackage -b --no-sign Now consider the following: $ touch foo.dsc $ make -t make chroot-foo make[1]: Entering directory '/tmp/x' make[1]: Nothing to be done for 'chroot-foo'. make[1]: Leaving directory '/tmp/x' touch libfoo.deb touch libfoo.deb $ $ make -t make chroot-foo make[1]: Entering directory '/tmp/x' make[1]: Nothing to be done for 'chroot-foo'. make[1]: Leaving directory '/tmp/x' touch foo.deb touch foo.deb I have to run make -t twice to touch both the targets. I'm not sure why they get touched twice but that might be expected, see below, but I only expect to have to run make -t once to touch all the targets. Change the &: to a simple : rule and we get: $ make -t make chroot-foo make[1]: Entering directory '/tmp/x' make[1]: Nothing to be done for 'chroot-foo'. make[1]: Leaving directory '/tmp/x' touch libfoo.deb touch libfoo.deb make chroot-foo make[1]: Entering directory '/tmp/x' make[1]: Nothing to be done for 'chroot-foo'. make[1]: Leaving directory '/tmp/x' touch foo.deb touch foo.deb As expected the rule gets executed twice, once for each target. Each file is still touched twice. -- System Information: Debian Release: 10.8 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages make depends on: ii libc6 2.28-10 make recommends no packages. Versions of packages make suggests: pn make-doc -- no debconf information
Bug#983115: Acknowledgement (make -t doesn't correctly touch grouped targets that are built by a recursive make)
Might not be related, but a trivial makefile: foo bar &: echo make -t only touches foo, not bar. Rerunning says 'foo is up to date'
Bug#983251: passwd is missing dependencies
Package: passwd
Version: 1:4.5-1.1
Severity: minor
Dear Maintainer,
passwd has a dependency on grep and base-passwd but does not explicitly
state those dependency.
When attempting to configure without base-passwd configured you get:
Setting up passwd (1:4.5-1.1) ...
pwck: cannot open /etc/passwd
Segmentation fault
chown: invalid user: 'root:root'
chmod: cannot access '/etc/passwd': No such file or directory
chown: invalid user: 'root:shadow'
chmod: cannot access '/etc/shadow': No such file or directory
Please correct the error and rerun `/sbin/shadowconfig on'
dpkg: error processing package passwd (--configure):
Adding that dependency and trying again you get:
Setting up passwd (1:4.5-1.1r1) ...
/var/lib/dpkg/info/passwd.postinst: 21: /var/lib/dpkg/info/passwd.postinst:
grep: not found
groupadd: group 'shadow' already exists
Group ID 42 has been allocated for the shadow group. You have either
used 42 yourself or created a shadow group with a different ID.
Please correct this problem and reconfigure with dpkg --configure passwd''.
Note that both user and group IDs in the range 0-99 are globally
allocated by the Debian project and must be the same on every Debian
system.
dpkg: error processing package passwd (--configure):
(Note that the report is spurious, grep being missing is treated as the
grep failing to find the expected line)
I am unsure how debootstrap avoids the first problem - It could just be
down to luck that debootstrap configures base-passwd before passwd. grep
is Priority: required and Essential: yes so it could be argued that it
should be unpacked before attempting to configure passwd and so this
dependency is not required.
The following patch resolves the two issues I've seen:
diff -ur shadow-4.5.orig/debian/control shadow-4.5/debian/control
--- shadow-4.5.orig/debian/control2018-07-26 15:41:12.0 +
+++ shadow-4.5/debian/control 2021-02-21 12:29:20.620702125 +
@@ -30,7 +30,9 @@
Multi-Arch: foreign
Depends: ${shlibs:Depends},
${misc:Depends},
- libpam-modules
+ libpam-modules,
+ base-passwd,
+ grep
Replaces: manpages-tr (<< 1.0.5),
manpages-zh (<< 1.5.1-1)
Description: change and administer password and group data
(This patch also applies successfully to 4.8.1 but with an offset)
=
FWIW, I think the problem line in passwd.postinst is actually incorrect:
if ! getent group shadow | grep -q '^shadow:[^:]*:42'
This will match if a shadow group has an id that starts 42, rather than
one that is exactly 42. I think an extra colon is required at the end of
the RE. That will mean that the message incorrectly printed above when
grep is missing about "Please correct this problem" will not be printed
if someone has created a group shadow with id 4200.
=
To reproduce this I am effectively doing:
1. download and unpack, but not configure, only the packages that apt
requires to run in a fakechroot. (around 15 packages)
2. fakeroot fakechroot chroot image apt-get install apt
and let apt-get resolve all the dependencies.
There are a few minor wrinkles to this process that I can supply if
anyone actually wants to reproduce what I did. My script is around 100
lines.
-- System Information:
Debian Release: 10.8
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages passwd depends on:
ii libaudit1 1:2.8.4-3
ii libc6 2.28-10
ii libpam-modules 1.3.1-5
ii libpam0g1.3.1-5
ii libselinux1 2.8-1+b1
ii libsemanage12.8-2
passwd recommends no packages.
passwd suggests no packages.
-- no debconf information
Bug#983251: passwd is missing dependencies
On Sun, 21 Feb 2021, Chris Hofstaedtler wrote: * Tim Woodall [210221 15:28]: I am unsure how debootstrap avoids the first problem - It could just be down to luck that debootstrap configures base-passwd before passwd. grep is Priority: required and Essential: yes so it could be argued that it should be unpacked before attempting to configure passwd and so this dependency is not required. That is exactly the case. Both grep and base-passwd are Essential: yes, so they _must_ function already (even when not configured yet). Adding them to Depends: could be argued to be a bug. The fundamental problem is actually that base-passwd is marked as Essential but passwd required it to have run its postinst script. Therefore the issue seems to be that base-passwd shouldn't be essential at all.
Bug#983251: passwd is missing dependencies
On Sun, 21 Feb 2021, Chris Hofstaedtler wrote: * Tim Woodall [210221 15:28]: I am unsure how debootstrap avoids the first problem - It could just be down to luck that debootstrap configures base-passwd before passwd. grep is Priority: required and Essential: yes so it could be argued that it should be unpacked before attempting to configure passwd and so this dependency is not required. That is exactly the case. Both grep and base-passwd are Essential: yes, so they _must_ function already (even when not configured yet). Adding them to Depends: could be argued to be a bug. Hi Chris, As per my other message I think there is a bug, but it's not in this package. However if there is a bug it's possibly in the wording of the debian policy on essential packages which is somewhat vague about bootstraping a virgin system. I've now inspected debootstrap and it handles this case by having an explicit ordering on how it configures the first seven packages independent of any explicit or implicit dependencies. So go ahead and close this bug rather than reassign it to base-passwd. I've taken the discussion to debian-devel. Regards, Tim.
Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked
Hi, A. /etc/passwd is part of base-passwd's interface and base-files is right in relying on it working at all times. Then base-passwd is rc buggy for violating a policy must. Fixing this violation is technically impossible. I seem to have hit this same issue independently. Could you explain why "Fixing this violation is technically impossible" As far as I can see, making base-passwd not essential, only required, and then making passwd and base-files pre-depend on base-passwd the system seems to bootstrap /etc/passed and /etc/group OK. That also seems to conform to the debian policy. The oddity is that base-files and passwd only actually need to depend on base-passwd, not pre-depend on it as they only use /etc/passwd and /etc/group in the postinst scripts but the debian policy doesn't seem to consider this case. (There are also issues with mawk preventing bootstrap but again I think this is due to some missing pre-depends (or depends) as explicitly configuring mawk first before anything else, even base-passwd resolves this. But I haven't analysed exactly what is going wrong yet in that case) Regards, Tim.
Bug#983251: passwd is missing dependencies
On Mon, 22 Feb 2021, Tim Woodall wrote: On Sun, 21 Feb 2021, Chris Hofstaedtler wrote: * Tim Woodall [210221 15:28]: I am unsure how debootstrap avoids the first problem - It could just be down to luck that debootstrap configures base-passwd before passwd. grep is Priority: required and Essential: yes so it could be argued that it should be unpacked before attempting to configure passwd and so this dependency is not required. That is exactly the case. Both grep and base-passwd are Essential: yes, so they _must_ function already (even when not configured yet). Adding them to Depends: could be argued to be a bug. Hi Chris, As per my other message I think there is a bug, but it's not in this package. However if there is a bug it's possibly in the wording of the debian policy on essential packages which is somewhat vague about bootstraping a virgin system. I've now inspected debootstrap and it handles this case by having an explicit ordering on how it configures the first seven packages independent of any explicit or implicit dependencies. So go ahead and close this bug rather than reassign it to base-passwd. I've taken the discussion to debian-devel. Actually it should be consolidated into 924401 as that's exactly the same bug. Regards, Tim.
Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked
On Mon, 22 Feb 2021, Colin Watson wrote: On Mon, Feb 22, 2021 at 07:33:10AM +, Tim Woodall wrote: As far as I can see, making base-passwd not essential, only required, and then making passwd and base-files pre-depend on base-passwd the system seems to bootstrap /etc/passed and /etc/group OK. That also seems to conform to the debian policy. The oddity is that base-files and passwd only actually need to depend on base-passwd, not pre-depend on it as they only use /etc/passwd and /etc/group in the postinst scripts but the debian policy doesn't seem to consider this case. base-passwd is independently essential to the functioning of the system as it currently stands, not just because base-files and passwd need it. As such I do not consider it correct to remove the Essential flag from base-passwd and won't be doing so. My view on this is that policy's definition of Essential should, for the time being, be refined to indicate that it only applies after the package has been configured at least once. Independently, I agree with other comments on this bug to the effect that it would be useful to extend dpkg such that initial copies of the essential files provided by base-passwd could be written without having to run base-passwd's maintainer scripts (something like the ability to provide an initial version of a configuration file without making it a full conffile), which would then allow simplifying the process, but I see no reason to block policy refinements on that; the policy manual is a living document and we can always update it again later once it's possible to simplify the bootstrapping process further. This can work. but I think there's a separate piece of metadata that is missing. Essential: yes actually encodes two pieces of information: 1. That the package is available and usable even when it's not configured. 2. That you can rely on the existence of the package and so do not need to include an explicit dependency to it. Making base-passwd not essential would mean that every package that depends on it should include at least a transitive dependency to it. That seems ludicrous - so I agree with Colin that base-passwd should be Essential. But that then leaves the problem that essential also encodes 1. I think there should be another piece of metadata "ConfigureOptional: yes" (or something that encompasses packages that do not need configuring to work) That way, two, completely isolated packages A and B could be marked "ConfigureOptional: yes" and use each other in their postinst scripts (and declare themselves as dependent on each other) Apt would then need to understand that circular dependencies can be broken by unpacking, but not configuring ConfigureOptional packages. There are a number of ways of solving the bootstrap tools problem of automatically determining the correct order to configure the packages without having to remove base-passwd from Essential. 1. make passwd and base-files depend on base-passwd without removing the Essential: yes flag from base-passwd (Possibly by updating to policy manual to state that Essential: yes packages CAN (Should?) state a dependency on other Essential: yes packages. This would go in tandem with Colin's suggestion to update the policy to state that Essential: yes merely requires that the package guarantees to be available if it's been configured at least once - and anybody outside of the essential set itself can assume that) 2. update dpkg to explicitly create these files if they don't exist, possibly by way of a type of "create only" conffile. This would have general use as quite a lot of packages use a postinst script to install configuration for the first time. The first example I found was for python3: [ -f /etc/python3/debian_config ] || new_config_file base-passwd would then use this facility and would strictly conform to the current Essential: yes policy. FWIW, it is possible to bootstrap a "system" that only includes 14 of the 23 Essential: yes packages in Buster that has everything you need to install the remaining 9 without having bootstrapped them from outside the system. It is, I presume, missing something that would prevent anything from booting and it's only usable via a chroot on an already booted system. And there's absolutely nothing with "Essential:" anything other than yes, which suggests that another possibility would be to have Essential: yes and Essential: needs_configure but option 2 above feels like the correct solution. I've never looked at dpkg source, but if it doesn't look too daunting I might try to put together at least a proof of concept for the idea of "only create, never modify" conffiles Regards, Tim.
Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked
On Mon, 22 Feb 2021, Helmut Grohne wrote: On Mon, Feb 22, 2021 at 07:33:10AM +, Tim Woodall wrote: A. /etc/passwd is part of base-passwd's interface and base-files is right in relying on it working at all times. Then base-passwd is rc buggy for violating a policy must. Fixing this violation is technically impossible. I seem to have hit this same issue independently. Could you explain why "Fixing this violation is technically impossible" The requirement here is that base-passwd needs to work when unpacked. The only way to make that work is making /etc/passwd a conffile. That would technically be possible, but it would be very annoying, because this file is different on virtually any Debian installation. So we cannot make it a conffile in practice. The next bet would be ensuring that base-passwd.postinst is run before other packages' postint somehow. Such an ordering mechanism does not exist at present and it would be prone to dependency loops. As far as I can see, making base-passwd not essential, only required, and then making passwd and base-files pre-depend on base-passwd the system seems to bootstrap /etc/passed and /etc/group OK. What you write is almost certainly self-contradictory. base-files is essential. Anything it depends on (including base-passwd in your scenario) is pseudo-essential and thus inherits all the same requirements except for actually being essential. You gained nothing. And you didn't explain how you'd make base-passwd non-essential. That also seems to conform to the debian policy. The oddity is that base-files and passwd only actually need to depend on base-passwd, not pre-depend on it as they only use /etc/passwd and /etc/group in the postinst scripts but the debian policy doesn't seem to consider this case. They don't have to depend on base-passwd at all, because dependencies on essential packages should be omitted. If base-passwd wasn't essential then passwd and base-files should depend on it. If passwd and base-files (pre)depend on base-passwd then base-passwd will be configured before passwd or base-files postinst is run. I suggest that you detail on the practical issue you have been hitting. Doing so allows evaluating prospective solutions against all relevant use cases. What I am doing - which seems similar to what others are doing with other tools, is to: 1. unpack apt, dpkg and debian-archive-keyring data.tar.xz into tmpdir/ (This provides a set of config that apt needs to run) 2. create a sources.list in tmpdir and touch image/var/lib/dpkg/status (dpkg needs this file to exist) 3. apt-get install -o RootDir=tmpdir -d $ESSENTIAL (This resolves all of the dependencies and downloads every package that needs to be installed. I cannot see a way to get apt to do this without jumping through the hoops of step 1 and 2 as --reinstall doesn't re-download dependencies) 4. unpack the data.tar.xz from every deb downloaded in 3 into image/ 5. repeat step 2 but in image/ 6. chroot image/ apt-get update apt-get install $ESSENTIAL And expect that to create a fully configured system. For buster at least, the _only_ sticking point is apt not configuring base-passwd early enough so one or the other of base-files and passwd postinst fails. I've created local copies of those two that have an explicit dependency on base-passwd and the problem is solved. I haven't tried with unstable or bullseye yet but I don't immediately see any other issues. Tim.
Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked
On Mon, 22 Feb 2021, Johannes Schauer Marin Rodrigues wrote: So yes, workarounds are (sadly) still necessary to debootstrap Debian. But arguing with Debian policy is the wrong way forward as policy does not talk about the debootstrap scenario but only about the system where your packages were at least configured once before. To find a good solution that can make it into Debian policy, talk to the dpkg maintainers and write patches against dpkg. As the author of mmdebstrap I already got them to integrate several changes into dpkg that make the work for programs like debootstrap and mmdebstrap easier and with features like DPKG_ROOT I'm very confident that they will greatly appreciate your help in further improving the situation. I didn't realize I was arguing with Debian policy! Right at the start I was as initially I _only_ wanted to add a depends to passwd and base-files - without realizing that that _did_ break the policy that you shouldn't state dependencies on Essential: yes packages. But since then I've been argying that Debian Policy _doesn't_ need to change at all. The existing wording of the policy, that on a strict reading implies that configure _never_ has had to be run can be correct. The reason I took this to debian-devel is because the "no-new functionality" change that makes everything work and have a strict reading of the policy is to remove Essential: yes from base-passwd. And I could see that that change was potentially going to impact thousands of packages as every package should then specify an implicit or explicit dependency on this package. c.f. i3lock-fancy which has a Dependency: gawk | cpl-plugin-hawki-calib | cpl-plugin-hawki-doc | mawk | original-awk | python-tomahawk But awk is a Pre-Depends of base-files and only gawk, mawk or original-awk provide it therefore this must be satisfied (unless there's something in non-free or the like that can also provide awk that I haven't looked for) (As far as I can see, the only reason base-files depends on awk is to make awk "essential". It doesn't seem to need it itself.) I am now working on a proof-of-concept patch to dpkg to achieve the same result (that base-passwd can be both Essential:yes and conform to the strictest reading of the policy on Essential:yes). Assuming I can get something working I'll open a bug against dpkg and see the the dpkg developers can make anything of it. dpkg is sufficently complicated and operates in so many different ways that I don't think I can possibly create something better than "works for me" but we'll see where I get to. I really didn't mean to tread on anyones toes here. This all started for me because debootstrap couldn't do what I wanted out of the box and I thought doing it myself would be easier than enhancing debootstrap. I then had the apparently trivial fix of adding a couple of dependencies to a couple of packages and it all spiralled from there. Had I known about the existency of mmdebstrap before I started then I might never have got to here. FWIW I would like debian to cover the bootstrap case, and I believe that it is already extremely close to achieving that out of the box. Tim.
Bug#983694: dpkg: Add "write-once" flag to conffiles that can then be created via the fsys-tarfile.
Package: dpkg
Version: 1.20.7.1
Severity: wishlist
Dear Maintainer,
This is a wishlist item relate to:
Re: Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked
With the patch included below the problem packages, Provides: awk and
base-passwd can be trivially modified so that they provide their
essential functionality via the fsys-tarfile only and do not need to
rely on the configure scripts to work before ever being configured.
This means that you need nothing more than apt to bootstrap a release as
apt can correctly work out the right order to configure the packages.
I also include example patches to base-passwd and mawk (gawk and
original-awk need almost identical changes to mawk)
The core feature is to add support for a flag "write-once" for
conffiles. In most circumstances this operates identical to a regular
conffile, however, it disables all questions about future changes and
always leaves the installed version untouched (except on purge).
The two base-passwd files are tagged like this and no longer need to be
created in the maintainer scripts for base-passwd essential
functionality to be avilable.
gawk/mawk/original-awk ship with a symlink
/usr/bin/awk -> /usr/bin/{g,m,original-}awk that is tagged similarly.
This does, currently cause a warning from dpkg-deb as the package is
built.
Under normal use cases /usr/bin/awk will exist and be maintained via the
alternatives mechanism, so dpkg will not use this packaged symlink as it
will see an existing file and "keep" it. But during bootstrapping when
the deb is initially unpacked using tar the symlink will be created and
so the awk functionality will be available before the correct symlink is
created via the maintainter scripts.
N.B. I think that it is probably necessary that gawk, mawk and
essential-awk are patched at the same time after this dpkg feature is
added. Otherwise I think that installing a package that doesn't use this
feature for the /usr/bin/awk symlink and then purging one that does will
result in the symlink being removed! There may will be other corner
cases like this that I'm unaware of.
= dpkg patch
diff -urN dpkg-1.20.7.1.orig/dpkg-deb/build.c dpkg-1.20.7.1/dpkg-deb/build.c
--- dpkg-1.20.7.1.orig/dpkg-deb/build.c 2021-01-09 06:04:59.0 +
+++ dpkg-1.20.7.1/dpkg-deb/build.c 2021-02-25 16:44:23.661053441 +
@@ -316,6 +316,9 @@
if (strcmp(flag, "remove-on-upgrade") == 0)
remove_on_upgrade = true;
+ else if (strcmp(flag, "write-once") == 0) {
+/* do nothing */
+ }
else
ohshit(_("unknown flag '%s' for conffile '%s'"), flag, conffilename);
}
diff -urN dpkg-1.20.7.1.orig/lib/dpkg/dpkg-db.h dpkg-1.20.7.1/lib/dpkg/dpkg-db.h
--- dpkg-1.20.7.1.orig/lib/dpkg/dpkg-db.h 2021-01-09 06:04:59.0
+
+++ dpkg-1.20.7.1/lib/dpkg/dpkg-db.h2021-02-25 16:42:48.269440879 +
@@ -83,6 +83,7 @@
const char *hash;
bool obsolete;
bool remove_on_upgrade;
+ bool write_once;
};
struct archivedetails {
diff -urN dpkg-1.20.7.1.orig/lib/dpkg/dump.c dpkg-1.20.7.1/lib/dpkg/dump.c
--- dpkg-1.20.7.1.orig/lib/dpkg/dump.c 2021-01-09 06:04:59.0 +
+++ dpkg-1.20.7.1/lib/dpkg/dump.c 2021-02-25 16:39:12.917286986 +
@@ -396,6 +396,8 @@
varbuf_add_str(vb, " obsolete");
if (i->remove_on_upgrade)
varbuf_add_str(vb, " remove-on-upgrade");
+if (i->write_once)
+ varbuf_add_str(vb, " write-once");
}
if (flags&fw_printheader)
varbuf_add_char(vb, '\n');
diff -urN dpkg-1.20.7.1.orig/lib/dpkg/fields.c dpkg-1.20.7.1/lib/dpkg/fields.c
--- dpkg-1.20.7.1.orig/lib/dpkg/fields.c2021-01-09 06:04:59.0
+
+++ dpkg-1.20.7.1/lib/dpkg/fields.c 2021-02-25 16:42:39.697116256 +
@@ -347,10 +347,11 @@
{
static const char obsolete_str[]= "obsolete";
static const char remove_on_upgrade_str[] = "remove-on-upgrade";
+ static const char write_once_str[] = "write-once";
struct conffile **lastp, *newlink;
const char *endent, *endfn, *hashstart;
int c, namelen, hashlen;
- bool obsolete, remove_on_upgrade;
+ bool obsolete, remove_on_upgrade, write_once;
char *newptr;
lastp = &pkgbin->conffiles;
@@ -371,6 +372,12 @@
conffvalue_lastword(value, endfn, endent, &hashstart, &hashlen, &endfn,
ps);
+write_once = (hashlen == sizeof(write_once_str) - 1 &&
+ memcmp(hashstart, write_once_str, hashlen) == 0);
+if (write_once)
+ conffvalue_lastword(value, endfn, endent, &hashstart, &hashlen, &endfn,
+ ps);
+
obsolete= (hashlen == sizeof(obsolete_str)-1 &&
memcmp(hashstart, obsolete_str, hashlen) == 0);
if (obsolete)
@@ -395,6 +402,7 @@
newlink->hash= newptr;
newlink->obsolete= obsolete;
newlink->remove_on_upgrade = remove_on_upgrade;
+newlink->write_once = write_once;
newlink->next =NULL;
*lastp= newlink;
lastp=
Bug#986442: debianutils: replace use of awk with grep in add-shell
Package: debianutils
Version: 4.8.6.1
Severity: wishlist
Dear Maintainer,
add-shell uses the following construct to ensure that the last line of
/etc/shells contains a newline:
if ! awk '{print}' "$file" > "$tmpfile"
I'd like to request that it be changed to
if ! grep '' "$file" > "$tmpfile"
awk causes some issues during bootstrapping a new system as it requires
the use of update-alternatives to create the necessary symlink. grep
doesn't have this issue meaning that, for example, installing dash no
longer depends on awk being configured first.
Additionally doing this would be another step to removing awk from the
Essential: yes set.
Patch against unstable:
diff -urN debianutils.orig/usr/sbin/add-shell debianutils/usr/sbin/add-shell
--- debianutils.orig/usr/sbin/add-shell 2020-09-27 17:25:47.0 +
+++ debianutils/usr/sbin/add-shell 2021-03-16 11:50:42.941481568 +
@@ -17,7 +17,7 @@
}
trap cleanup EXIT
-if ! awk '{print}' "$file" > "$tmpfile"
+if ! grep '' "$file" > "$tmpfile"
then
cat 1>&2 <
Bug#980140: usbip: kernel bug when removing usbip_host (started very recently)
Package: usbip Version: 2.0+4.19.160-2 Severity: important Dear Maintainer, usbip stops working (this has been a long standing issue) and not the bug I'm reporting. Previously, when this happens I would do rmmod usbip_host, modprobe usbip_host and then it would start working again. Now, when I do rmmod usbip_host after this happens I get a kernel gpf, the reference count in lsmod goes negative, and the only thing that will unstick things is a reboot (which is a problem as this is running on a xen dom-0). I'd never seen this issue prior to 11th Jan this year (and I've been running with this setup since March 2020 (COVID WFH) There was a xen hypervisor upgrade: -rw-r--r-- 1 root root616 Dec 16 06:25 /var/lib/dpkg/info/xen-hypervisor-4.11-amd64.list which I rebooted to pick up on 18th December. Due to the break I was not using usbip much until January. First failure was January 11th: Jan 11 09:08:20 xen17 vmunix: [2030320.071228] usbcore: deregistering device driver usbip-host Jan 11 09:08:20 xen17 vmunix: [2030320.071373] usbip-host 1-1.2: recv a header, 0 Jan 11 09:08:20 xen17 vmunix: [2030320.072303] general protection fault: [#1] SMP NOPTI Jan 11 09:08:20 xen17 vmunix: [2030320.073007] CPU: 3 PID: 4302 Comm: rmmod Not tainted 4.19.0-13-amd64 #1 Debian 4.19.160-2 Jan 11 09:08:20 xen17 vmunix: [2030320.073791] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J1900D2Y, BIOS P1.10 01/23/2015 Jan 11 09:08:20 xen17 vmunix: [2030320.074710] RIP: e030:__mutex_lock.isra.8+0x168/0x4a0 Jan 11 09:08:20 xen17 vmunix: [2030320.075575] Code: 39 9a ff 66 90 31 c0 48 8b 5c 24 48 65 48 33 1c 25 28 00 00 00 0f 8 5 3d 03 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <8b> 50 38 85 d2 0f 85 45 02 00 00 65 48 8b 04 25 40 5c 01 00 48 8b Jan 11 09:08:20 xen17 vmunix: [2030320.077619] RSP: e02b:c90042287de0 EFLAGS: 00010202 Jan 11 09:08:20 xen17 vmunix: [2030320.078720] RAX: 0001cdbfb0080120 RBX: 8882f38a58a0 RCX: Jan 11 09:08:20 xen17 vmunix: [2030320.079874] RDX: 0001cdbfb0080120 RSI: 88811eebde80 RDI: 8882f38a5900 Jan 11 09:08:20 xen17 vmunix: [2030320.081022] RBP: c90042287e58 R08: R09: 81534000 Jan 11 09:08:20 xen17 vmunix: [2030320.082195] R10: 8882b3f63b50 R11: 0001 R12: Jan 11 09:08:20 xen17 vmunix: [2030320.083407] R13: 0002 R14: R15: 8882f38a5900 Jan 11 09:08:20 xen17 vmunix: [2030320.084650] FS: 7f3dfb5b6480() GS:88846c98() knlGS: Jan 11 09:08:20 xen17 vmunix: [2030320.085939] CS: e033 DS: ES: CR0: 80050033 Jan 11 09:08:20 xen17 vmunix: [2030320.087255] CR2: 555c9f56c8d8 CR3: 0003fabf CR4: 0660 Jan 11 09:08:20 xen17 vmunix: [2030320.088634] Call Trace: Jan 11 09:08:20 xen17 vmunix: [2030320.090070] ? __kernfs_remove.part.15+0x100/0x1e0 Jan 11 09:08:20 xen17 vmunix: [2030320.091553] ? kobject_uevent_env+0x120/0x650 Jan 11 09:08:20 xen17 vmunix: [2030320.092997] __device_attach+0x34/0x160 Jan 11 09:08:20 xen17 vmunix: [2030320.094483] do_rebind.isra.1+0x32/0x80 [usbip_host] Jan 11 09:08:20 xen17 vmunix: [2030320.096012] usbip_host_exit+0x8b/0xf9f [usbip_host] Jan 11 09:08:20 xen17 vmunix: [2030320.097517] __x64_sys_delete_module+0x190/0x2e0 Jan 11 09:08:20 xen17 vmunix: [2030320.099035] do_syscall_64+0x53/0x110 Jan 11 09:08:20 xen17 vmunix: [2030320.100561] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jan 11 09:08:20 xen17 vmunix: [2030320.102154] RIP: 0033:0x7f3dfb6d6dd7 Jan 11 09:08:20 xen17 vmunix: [2030320.103742] Code: 73 01 c3 48 8b 0d b9 10 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 89 10 0c 00 f7 d8 64 89 01 48 Jan 11 09:08:20 xen17 vmunix: [2030320.107223] RSP: 002b:7ffc17301928 EFLAGS: 0206 ORIG_RAX: 00b0 Jan 11 09:08:20 xen17 vmunix: [2030320.109046] RAX: ffda RBX: 555c9f5645b0 RCX: 7f3dfb6d6dd7 Jan 11 09:08:20 xen17 vmunix: [2030320.110904] RDX: 000a RSI: 0800 RDI: 555c9f564618 Jan 11 09:08:20 xen17 vmunix: [2030320.112789] RBP: R08: 7ffc173008a1 R09: Jan 11 09:08:20 xen17 vmunix: [2030320.114716] R10: 7f3dfb748ae0 R11: 0206 R12: 7ffc17301b50 Jan 11 09:08:20 xen17 vmunix: [2030320.116649] R13: 7ffc17302e49 R14: 555c9f562260 R15: 555c9f5645b0 Jan 11 09:08:20 xen17 vmunix: [2030320.118613] Modules linked in: usbip_host(-) usbip_core usblp dm_snapshot dm_bufio xen_netback xen_blkback xen_gntdev xen_evtchn xenfs xen_privcmd bridge stp llc nls_ascii nls_cp437 vfat fat ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hci_uart btqca btrtl btbcm btintel snd_hda_codec_hdmi uvcvideo ast joydev videobuf2_vmalloc bluetooth intel_soc_dts_thermal intel_soc_dts_iosf
Bug#940473: closed by Alexander Zangerl (Bug#940473: fixed in dump 0.4b46-6)
Awesome, thank you! Confirmed that this has fixed my verification failure. (FWIW, my failure was on ext3) On Sun, 6 Oct 2019, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the dump package: #940473: dump: Verify fails when multiple extended attributes are present It has been closed by Alexander Zangerl . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Alexander Zangerl by replying to this email.
Bug#941148: alpine incorrectly reporting server name does not match certificate.
Package: alpine Version: 2.21+dfsg1-1.1 Severity: normal Dear Maintainer, This issue occurs when you use alpine in buster to connect (to an imap server running on squeeze). alpine in squeeze does not have the issue when connecting to the same imap server. Initially I was getting certificate name mismatches when alpine attempted to connect to my imap server. I resolved them by adding a Subject Alternative Name that matched the Common Name. However, I still get the certificate name mismatch when I try to send an email (which can then be ignored) # openssl x509 -in imapd.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 1044 (0x9896ac) Signature Algorithm: sha256WithRSAEncryption Issuer: C = GB, ST = London, O = Certificate Authority, CN = Tim Woodall CA Validity Not Before: Sep 15 13:20:28 2019 GMT Not After : Sep 14 13:20:28 2020 GMT Subject: C = GB, ST = London, O = Tim Woodall, CN = einstein.home.woodall.me.uk, emailAddress = * Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: DNS:einstein.home.woodall.me.uk Signature Algorithm: sha256WithRSAEncryption There was a failure validating the SSL/TLS certificate for the server einstein.home.woodall.me.uk The reason for the failure was Server name does not match certificate (details) Host given by user: einstein.home.woodall.me.uk Reason for failure: Server name does not match certificate Certificate being verified: /C=GB/ST=London/O=Tim Woodall/CN=einstein.home.woodall.me.uk/emailAddress=** -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages alpine depends on: ii libc6 2.28-10 ii libgssapi-krb5-2 1.17-3 ii libkrb5-3 1.17-3 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u1 ii libpam0g 1.3.1-5 ii libssl1.1 1.1.1c-1 ii libtinfo6 6.1+20181013-2+deb10u1 ii mlock 8:2007f~dfsg-6 Versions of packages alpine recommends: pn alpine-doc Versions of packages alpine suggests: ii aspell0.60.7~20110707-6 pn mail-transport-agent | exim4 -- no debconf information
Bug#914018: Acknowledgement (xen-hypervisor-4.8-amd64: kernel oops when starting wireless networking when booted with xen efi hypervisor)
I've just upgraded to buster and this problem is resolved.
Bug#940473: dump: Verify fails when multiple extended attributes are present
Package: dump Version: 0.4b46-3 Severity: minor Dear Maintainer, This is a very longstanding, but minor, bug that I've finally got around to reporting. I did investigate trying to fix but it appeared highly non-trivial. Note that this only affects a verify. A restore gives the correct results. Dump tape is compressed. ./tim/sipphone.cfg: EA count changed from 1 to 2 ./tim/sipphone.cfg: EA count changed from 1 to 2 ./tim/armhf/openssh-server_7.6p1-4_armhf.deb: EA count changed from 1 to 2 ./tim/armhf/openssh-server_7.6p1-4_armhf.deb: EA count changed from 1 to 2 Dump date: Sun Sep 15 09:10:04 2019 Dumped from: the epoch Level 0 dump of an unlisted file system on ***:/dev/vg0/home-backup Label: none filesys = /tmp/backup.f5BujJPgsv Some files were modified! 4 compare errors When files have multiple extended attributes, the restore and verify applies them one by one. For restore this works as, at the end of the restore, the file has all the attributes applied. But during verify, each attribute 'fails' verification as the EA count on the 'restore' is 1 while on the target file it is N. If a fix isn't possible, it would be nice to have an option to disable EA verification so that the return code of the verify can be used in automatic backup scripts. This bug is present in all versions of dump. -- System Information: Debian Release: 9.11 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 4.9.0-11-686-pae (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages dump depends on: ii e2fslibs 1.43.4-2 ii libblkid1 2.29.2-1+deb9u1 ii libbz2-1.01.0.6-8.1 ii libc6 2.24-11+deb9u4 ii libcomerr21.43.4-2 ii liblzo2-2 2.08-1.2+b2 ii libreadline7 7.0-3 ii libselinux1 2.6-3+b3 ii tar 1.29b-1.1 ii zlib1g1:1.2.8.dfsg-5 dump recommends no packages. dump suggests no packages. -- debconf information excluded
Bug#979354: Redone patch so that it applies against the dsc.
I have also hit this bug while backporting openssh from unstable to bullseye
(ironically so I can avoid the need to use dpkg-divert)
I've redone the patch proposed above so that it applies against the
unpacked source package:
apt-mirror@aptmirror17:/mnt/mirror/local-debs (master)$ cat main/u/ucf/ucf.patch
diff -urN ucf-3.0043.orig/ucf ucf-3.0043/ucf
--- ucf-3.0043.orig/ucf 2020-06-16 05:37:53.0 +
+++ ucf-3.0043/ucf 2020-06-16 05:37:53.0 +
@@ -439,16 +439,10 @@
fi
# Follow dpkg-divert as though we are installed as part of $opt_package
-divert_line=$(dpkg-divert --list "$dest_file")
+divert_line=$(dpkg-divert --listpackage "$dest_file")
if [ -n "$divert_line" ]; then
- if [ echo "$divert_line" | grep "^local" ]; then
- # local diversion; pick something not in the package namespace
- divert_package="LOCAL"
- else
- # extract the name of the diverted package.
- # The fact that this requires output parsing is bug #485012
- divert_package=$(dpkg-divert --listpackage "$dest_file")
- fi
+ # name of the package or 'LOCAL' for a local diversion
+ divert_package="$divert_line"
if [ "$divert_package" != "$opt_package" ]; then
dest_file=$(dpkg-divert --truename "$dest_file")
diff -urN ucf-3.0043.orig/ucfr ucf-3.0043/ucfr
--- ucf-3.0043.orig/ucfr2020-06-16 05:37:53.0 +
+++ ucf-3.0043/ucfr 2020-06-16 05:37:53.0 +
@@ -112,10 +112,18 @@
awk '{print $1;}' );
if [ "$pkg" != "$old_pkg" ]; then
-if [ "X$FORCE" = "X" ]; then
-echo >&2 "$progname: Attempt from package $pkg to take
${real_conf_file} away from package $old_pkg";
-echo >&2 "ucfr: Aborting.";
-exit 4;
+divert_package=$(dpkg-divert --listpackage "$conf_file")
+if [ -n "$divert_package" ]; then
+if [ "X$VERBOSE" != "X" ]; then
+echo >&2 "$progname: Package $pkg will not take
away diverted ${conf_file} from package $divert_package";
+fi
+exit 0;
+else
+if [ "X$FORCE" = "X" ]; then
+echo >&2 "$progname: Attempt from package $pkg to
take ${real_conf_file} away from package $old_pkg";
+echo >&2 "ucfr: Aborting.";
+exit 4;
+fi
fi
else
if [ "X$VERBOSE" != "X" ]; then
And I can confirm that it fixes my issue.
root@proxy19:~# apt-get install --reinstall openssh-server
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded.
Need to get 432 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://aptmirror17.home.woodall.me.uk/local bullseye/main amd64
openssh-server amd64 1:8.7p1-2+tjw11r1 [432 kB]
...
Setting up openssh-server (1:8.7p1-2+tjw11r1) ...
/usr/bin/ucf: 444: [: missing ]
grep: ]: No such file or directory
Restarting OpenBSD Secure Shell server: sshd.
root@proxy19:~# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
ucf
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 74.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://aptmirror17.home.woodall.me.uk/local bullseye/main amd64 ucf all
3.0043+tjw11r1 [74.1 kB]
Fetched 74.1 kB in 0s (359 kB/s)
(Reading database ... 22805 files and directories currently installed.)
Preparing to unpack .../ucf_3.0043+tjw11r1_all.deb ...
Unpacking ucf (3.0043+tjw11r1) over (3.0043) ...
Setting up ucf (3.0043+tjw11r1) ...
root@proxy19:~# apt-get install --reinstall openssh-server
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/432 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 22805 files and directories currently installed.)
Preparing to unpack .../openssh-server_1%3a8.7p1-2+tjw11r1_amd64.deb ...
Unpacking openssh-server (1:8.7p1-2+tjw11r1) over (1:8.7p1-2+tjw11r1) ...
Setting up openssh-server (1:8.7p1-2+tjw11r1) ...
Restarting OpenBSD Secure Shell server: sshd.
Bug#941148: Acknowledgement (alpine incorrectly reporting server name does not match certificate.)
My mistake. I was looking at the imap certificate but forgot to look at the SMTP certificate - which is where the Subject Alternative Name was missing. This can be closed.
Bug#954846: chromium: Requires a (possibly broken) default route in order to connect to a (reachable) ipv6 proxy
Package: chromium Version: 80.0.3987.149-1~deb10u1 Severity: normal Dear Maintainer, If you start chromium with valid working ipv6 proxy config but no default route configured then chromium will say: No internet There is something wrong with the proxy server, or the address is incorrect. Add a default route, even a broken one ip -6 route add default via ::::: (There is no such host) and chromium starts working. The same problem does not happen for an ipv4 proxy - you do not required a default route to access the proxy and the internet. -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages chromium depends on: ii chromium-common 80.0.3987.149-1~deb10u1 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatomic1 8.3.0-6 ii libatspi2.0-02.30.0-7 ii libavcodec58 10:4.1.5-dmo1+deb10u1 ii libavformat5810:4.1.5-dmo1+deb10u1 ii libavutil56 10:4.1.5-dmo1+deb10u1 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.2.10-6+deb10u2 ii libdbus-1-3 1.12.16-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-2+deb10u1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1+deb10u2 ii libopenjp2-7 2.3.0-2+deb10u1 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libpci3 1:3.5.2-1 ii libpng16-16 1.6.36-6 ii libpulse012.2-4+deb10u1 ii libre2-5 20190101+dfsg-2 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-6 ii libvpx5 1.7.0-3+deb10u1 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2.2~deb10u1 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 80.0.3987.149-1~deb10u1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: ii chromium-sandbox 80.0.3987.149-1~deb10u1 ii fonts-liberation 1:1.07.4-9 ii libgl1-mesa-dri 18.3.6-2+deb10u1 pn libu2f-udev pn notification-daemon ii upower 0.99.10-1 Versions of packages chromium-sandbox depends on: ii libatomic1 8.3.0-6 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 -- no debconf information
Bug#1022043: Race condition downloading index files.
I've managed to reproduce this issue when many hosts hit apt-cacher-ng
at the same time.
Attached a patch which fixes it for me - this is a quick and hacky
patch!
Sent debug logs of a run that reproduces this problem and a run with
this patch applied directly to the maintainer.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..5c003a9 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,18 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+ Lockstuff g{h.getRequestUrl()};
+
+ // Check if another job is running. If so link to that.
+ if(g.stuff->otherThread) {
+ m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+ USRDBG("Linked to other job");
+ return;
+ }
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +709,14 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody waiting for this thread to complete
+ // where to get their m_pItem and register a cleanup
+ // when this job completes.
+ g.setReturnValue(m_pItem.get());
+ m_ipc = std::make_unique(h.getRequestUrl());
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -759,6 +777,11 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
USRERR("PANIC! Error creating download job for " << m_sFileLoc);
return report_overload(__LINE__);
}
+ // Tell everybody waiting for this thread to complete
+ // where to get their m_pItem and register a cleanup
+ // when this job completes.
+ g.setReturnValue(m_pItem.get());
+ m_ipc = std::make_unique(h.getRequestUrl());
}
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
@@ -1190,4 +1213,58 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::Lockstuff::Lockstuff(const std::string& url_): url(url_) {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ while(true) {
+ auto [it, ins] = inProgress.insert({url, nullptr});
+ if(!ins) {
+ stuff = it->second;
+ if (stuff->otherThread) {
+break;
+ }
+ // Someone is already downloading this. Add ourselves to the waiters.
+ stuff->cv.wait(g._guard);
+ } else {
+ stuff = it->second = std::make_shared();
+ owner = true;
+ break;
+ }
+ }
+}
+
+void job::Lockstuff::setReturnValue(tFileItemPtr tfip) {
+ LOGSTARTFUNC;
+ if (const auto& it = inProgress.find(url); it != inProgress.end()) {
+ stuff->otherThread = tfip;
+ }
+}
+
+job::Lockstuff::~Lockstuff() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ if(owner) {
+ stuff->cv.notify_all();
+ // After notify_all, any waiting threads are guaranteed to
+ // be blocked on inProgressLock, not on the condition so
+ // it's safe to delete it. However we have to use shared
+ // pointers because we don't know how long it will take the
+ // waiters to read the tFileItemPtr;
+ if (!stuff->otherThread) {
+ inProgress.erase(url);
+ }
+ }
+}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ if (const auto& it = inProgress.find(url); it != inProgress.end()) {
+ inProgress.erase(it);
+ }
+}
+
+std::map> job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..97446e2 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,39 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // The data that we store in inProgress
+ struct Stuff {
+ std::condition_variable cv;
+ tFileItemPtr otherThread = 0;
+ };
+
+ // Map from URL to Stuff for in progress jobs that are requesting this file.
+ // The entry is "owned" by the job that added it and it is deleted when the job completes.
+ static std::map> inProgress;
+
+ // Where all the real work is done.
+ struct Lockstuff {
+ const std::strin
Bug#1022043: improved patch
I've cleaned up the patch and got rid of a lot of the cruft that got
added while I was debugging.
Also found one more race condition in my original solution that I
believe is now fixed.
And I believe it's now safe even if different urls map to the same cache
file which the previous patch didn't get right.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +710,13 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody downloading this url that we already
+ // have a job to download it and register a cleanup
+ // when this job completes.
+ setInProgress(m_sFileLoc);
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -760,6 +778,10 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
return report_overload(__LINE__);
}
}
+ // Tell everybody downloading this url that we already have a
+ // job to download it and register a cleanup when this job
+ // completes.
+ setInProgress(m_sFileLoc);
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
{
@@ -1190,4 +1212,16 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ USRDBG("url=" << url);
+ if (url.size()) {
+ inProgress.erase(url);
+ }
+}
+
+std::set job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..b4df3de 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,26 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // If there is an item in here then there is already a job downloading url
+ static std::set inProgress;
+
+ // Simple class which is destroyed when the job is destroyed. It deletes the entry from inProgress.
+ struct inProgressCleanup {
+ std::string url;
+ inProgressCleanup() { }
+ ~inProgressCleanup();
+ };
+
+ void setInProgress(const std::string& url_) {
+ m_ipc.url = url_;
+ inProgress.insert(url_);
+ }
+
+ inProgressCleanup m_ipc;
public:
enum eJobResult : short
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnl
Bug#1022043: Info received (improved patch)
Try again - without the old patch at the top.diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..c53feb1 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,19 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+
+ lockuniq g{inProgressLock};
+
+ if (inProgress.contains(m_sFileLoc)) {
+// Check if another job is running. If so link to that.
+m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+USRDBG("Linked to other job");
+return;
+}
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +710,13 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody downloading this url that we already
+ // have a job to download it and register a cleanup
+ // when this job completes.
+ setInProgress(m_sFileLoc);
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -760,6 +778,10 @@ void job::Prepare(const header &h, string_view headBuf, cmstring& callerHostname
return report_overload(__LINE__);
}
}
+ // Tell everybody downloading this url that we already have a
+ // job to download it and register a cleanup when this job
+ // completes.
+ setInProgress(m_sFileLoc);
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
{
@@ -1190,4 +1212,16 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ USRDBG("url=" << url);
+ if (url.size()) {
+ inProgress.erase(url);
+ }
+}
+
+std::set job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..c79459b 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,24 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // If there is an item in here then there is already a job downloading url
+ static std::set inProgress;
+
+ // Simple class which is destroyed when the job is destroyed. It deletes the entry from inProgress.
+ struct inProgressCleanup {
+ std::string url;
+ inProgressCleanup() { }
+ ~inProgressCleanup();
+ };
+
+ void setInProgress(const std::string& url_) {
+ m_ipc.url = url_;
+ inProgress.insert(url_);
+ }
public:
enum eJobResult : short
@@ -48,6 +66,7 @@ public:
} eActivity;
TFileItemHolder m_pItem;
+ inProgressCleanup m_ipc; // This MUST be destroyed before m_pItem
unique_fd m_filefd;
bool m_bIsHttp11 = true;
Bug#1086575: tgt: The example in the manpage for media_home isn't supported by tgt-admin
Package: tgt
Version: 1:1.0.85-1
Severity: wishlist
Dear Maintainer,
Under in the tgtadm man page under the media_home documentation there
are tgtadm commands to set this a virtual jukebox. However, the first
step, "The dvd starts out without a backing store" isn't supported by
tgt-admin.
I propose a patch that makes this supported. Additionally, I include two
example conf files for a dvd jukebox exactly as per the manpage and a
virtual tape library.
Note that this patch no longer allows shell expansion of variables (and
shell scripts) in the conf file in the areas of the code I've changed.
This might be classed as a regression. This patch should also fix
#905028.
tgt-admin.patch - the patch itself
tgt-admin.conf - a conffile that should be identical to the man page
example.
tapechanger.conf - a conffile for a vtl. Commented instructions at the
end for how to use it.
Additionally, I would suggest that tgt-admin verifies that all of the
conffiles it reads are owned and only writeable by root. There are
countless shell escape vulnerabilites that would allow anyone with write
access to a conf file to gain root permissions when it starts. (My perl
skills are not sufficient to do this so I have not included a patch but
I've made my best effort to resolve these issues in the areas of the
code I have touched.)
-- System Information:
Debian Release: 12.7
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-26-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages tgt depends on:
ii init-system-helpers1.65.2
ii libaio10.3.113-4
ii libc6 2.36-9+deb12u8
ii libconfig-general-perl 2.65-2
ii libibverbs144.0-2
ii librdmacm1 44.0-2
ii libsystemd0252.30-1~deb12u2
ii lsb-base 11.6
ii sg3-utils 1.46-3
ii sysvinit-utils [lsb-base] 3.06-4
tgt recommends no packages.
Versions of packages tgt suggests:
pn tgt-glusterfs
pn tgt-rbd
-- no debconf information
--- /usr/sbin/tgt-admin.orig2024-11-01 09:20:29.007424225 +
+++ /usr/sbin/tgt-admin 2024-11-01 15:13:29.826332459 +
@@ -423,6 +423,7 @@
}
}
+ $param_value =~ s/'/\\'/g;
if ($param eq "scsi_id" ||
$param eq "scsi_sn" ||
$param eq "vendor_id" ||
@@ -438,10 +439,12 @@
$param eq "optimal_xfer_gran" ||
$param eq "optimal_xfer_len" ||
$param eq "readonly") {
- return("tgtadm -C $control_port --lld $driver --op update
--mode logicalunit --tid $next_tid --lun=$lun --params
$param=\"$param_value\"");
+ return("tgtadm -C $control_port --lld $driver --op update
--mode logicalunit --tid $next_tid --lun=$lun --params $param='$param_value'");
}
if ($param eq "params") {
- return("tgtadm -C $control_port --lld $driver --op update
--mode logicalunit --tid $next_tid --lun=$lun --params \"$param_value\"");
+ $param_value =~ s/\${tid}/$next_tid/g;
+ $param_value =~ s/\${lun}/$lun/g;
+ return("tgtadm -C $control_port --lld $driver --op update
--mode logicalunit --tid $next_tid --lun=$lun --params '$param_value'");
}
}
@@ -488,7 +491,7 @@
}
if ($can_alloc == 1 &&
- ($bstype =~ "glfs" || $bstype =~ "rbd" || (-e $backing_store && ! -d
$backing_store))) {
+ ($bstype =~ "glfs" || $bstype =~ "rbd" || $backing_store =~ "^NONE:"
|| (-e $backing_store && ! -d $backing_store))) {
my @exec_commands;
my $device_type;
my $bs_type;
@@ -720,12 +723,20 @@
exit 1;
}
# Execute commands for a given LUN
- if (length $device_type) { $device_type = "--device-type
$device_type" };
- if (length $bs_type) { $bs_type = "--bstype $bs_type" };
- if (length $bsopts) { $bsopts = "--bsopts $bsopts" };
- if (length $bsoflags) { $bsoflags = "--bsoflags $bsoflags" };
- if (length $block_size) { $block_size = "--blocksize
$block_size" };
- execute("tgtadm -C $control_port --lld $driver --op new --mode
logicalunit --tid $next_tid --lun $lun -b \"$backing_store\" $device_type
$bs_type $bsopts $bsoflags $block_size");
+ # Escape any single quotes
+ $device_type =~ s/'/\\'/g;
+ $bs_type =~ s/'/\\'/g;
+ $bsopts =~ s/'/\\'/g;
+ $bsoflags =~ s/'/\\'/g;
+ $block_size =~ s/'/\\'/g;
+ $backing_store =~ s/'/\\'/g;
+
Bug#1081008: Info received (Bug#1081008: Consolidated fixes)
Hopefully the final patch!
Neither sockets nor pipes had their attributes verified correctly when
doing restore -C.
diff -urN dump-0.4b47.orig/restore/tape.c dump-0.4b47/restore/tape.c
--- dump-0.4b47.orig/restore/tape.c 2022-05-03 10:02:27.0 +
+++ dump-0.4b47/restore/tape.c 2022-05-03 10:02:27.0 +
@@ -1807,12 +1807,6 @@
uid = curfile.dip->di_uid;
gid = curfile.dip->di_gid;
- if ((mode & IFMT) == IFSOCK) {
- Vprintf(stdout, "skipped socket %s\n", name);
- skipfile();
- return;
- }
-
if ((r = lstat(name, &sb)) != 0) {
warn("unable to stat %s", name);
do_compare_error;
@@ -1859,13 +1853,12 @@
}
switch (mode & IFMT) {
default:
+ fprintf(stderr, "%s: unknown file mode 0%o\n", name, mode);
skipfile();
return;
case IFSOCK:
- skipfile();
- return;
-
+ case IFIFO:
case IFDIR:
skipfile();
compareattr(name);
Bug#1081008: Consolidated fixes
Attached the debian.tar.xz of my local build with many fixes included. configure-ac.patch ... 1 compiler-warnings.patch .. 1 handle-bigfiles.patch 4 xattr_verify.patch ... 3 ignore-ext4-extents-flag.patch . 2 fix-uninit-blocks.patch .. 4 fix-write-estimate.patch . 2 fix-paramter-maxsize.patch ... 2 handle-inline-data.patch . 4 I've ranked them from 1-4. 1 - it makes no difference if the patch is included 2 - Data is written to tape and restored correctly but a verify might fail or other visible effects. 3 - Data is written to tape correctly but a restore does not give correct results. 4 - Invalid data is written to tape. Details of each patch: (T) indicates that I have a testcase for the bug. configure-ac.patch Update configure.ac so that there are no warnings about deprecated usage. compiler-warnings.patch Fix some compiler warnings about suspicious usage. (The usage appears OK in the particular context) handle-bigfiles.patch (T) Correctly dump files that use blocks with index >=2^32. On a default bookworm install using default mkfs.ext4 this means filesystems >16T xattr_verify.patch (T) This replaces the existing xattr_verify. (which I notice is still present in the tarfile but isn't part of the quilt series - not sure what I did wrong there). As well as the original issue where verify of files that had EA across two blocks, this fixes a similar issue with directories except that directories didn't restore correctly. N.B. I've only tested the cases of files and directories. I now have proper testcases that I'll extend to the other types that can have EA so there might be another patch incoming shortly. ignore-ext4-extents-flag.patch (T) When verifying symlinks you cannot get or set the flags on the symlink. But with ext4 the flags can either be 0 or EXT4_EXTENTS_FL. This patch ignores this flag while verifying. fix-uninit-blocks.patch (T) Ext4 added the feature that an extent can reserve blocks on the FS but not write any data to them. This patch ensures that the dump gets blocks of zeros written to it rather than whatever random, uninitialized data exists on the disk. fix-write-estimate.patch The existing code incorrectly calculates the file size for very large files therefore the estimate of blocks to be written will also be wrong. fix-paramter-maxsize.patch The -D parameter to restore -C was limited to 64 characters. This meant verifies of a FS mounted on a patch longer than this would fail. handle-inline-data.patch (T) Ext4 adds the ability to store small files in the inode. These were not dumped to the tape at all. Additionally, they use a "system.data" EA which messes up both restore and verify of EAs. -O inline_data is not a default parameter for bookworm and so this bug will only be hit by people who explicitly request inline data. All of the testcases require root to run so I've not included them. They can be found here: https://sourceforge.net/p/dump/code/merge-requests/3/ dump_0.4b47-4+~tjw12r7.debian.tar.xz Description: application/xz
Bug#1091743: apt-ftparchive: support No-Support-For-Architecture-all
Package: apt
Version: 2.6.1
Severity: wishlist
Dear Maintainer,
Please consider supporting No-Support-For-Architecture-all in
apt-ftparchive. This is a one line change to ftparchive/writer.cc
tim@dirac:~/git/apt (main)$ git diff
diff --git a/ftparchive/writer.cc b/ftparchive/writer.cc
index 3c5237915..5e917d188 100644
--- a/ftparchive/writer.cc
+++ b/ftparchive/writer.cc
@@ -1012,6 +1012,7 @@ ReleaseWriter::ReleaseWriter(FileFd * const GivenOutput,
string const &/*DB*/) :
Fields["Components"] = "";
Fields["Description"] = "";
Fields["Signed-By"] = "";
+ Fields["No-Support-for-Architecture-all"] = ""
BoolFields["Acquire-By-Hash"] = _config->FindB("APT::FTPArchive::DoByHash",
false);
BoolFields["NotAutomatic"] = false;
BoolFields["ButAutomaticUpgrades"] = false;
Testing:
$ cat bookworm-nodefault-aptftp.conf
APT::FTPArchive {
DoByHash "true";
Release {
Origin "local debs";
Label "local debs";
Suite "stable-nodefault";
Version "12";
Codename "bookworm-nodefault";
NotAutomatic "yes";
ButAutomaticUpgrades "yes";
Acquire-By-Hash "yes";
Architectures "all amd64 i386 armel arm64";
Components "main";
Description "Debs for local installing";
MD5 "yes";
SHA1 "no";
SHA256 "yes";
SHA512 "no";
No-Support-For-Architecture-all "Packages";
ValidTime 31536000;
};
};
Generates:
Acquire-By-Hash: yes
Architectures: all amd64 i386 armel arm64
ButAutomaticUpgrades: yes
Codename: bookworm-nodefault
Components: main
Date: Mon, 30 Dec 2024 19:13:32 +
Description: Debs for local installing
Label: local debs
No-Support-for-Architecture-all: Packages
NotAutomatic: yes
Origin: local debs
Suite: stable-nodefault
Valid-Until: Tue, 30 Dec 2025 19:13:32 +
Version: 12
MD5Sum:
f893f7a4d6b717921e54661291504dd6 390 Release
95b0f67449a6ee7ec41a015f2f125a8c 142291 main/Contents-all
e122cf960be381c9a6b0b8f8290662f9 7500 main/Contents-all.gz
489e3496a9aa84cd740b1cd82be44702 175676 main/Contents-amd64
f7cf87c585ef7b902e3fdaec0eadbcc010927 main/Contents-amd64.gz
f1ef067fe94e1f123e4c979c52a77567 4289 main/binary-all/Packages
77db331ccd01c02539b908c8e9885d36 1924 main/binary-all/Packages.xz
db2c3d4f91f44611adb243601d02103020586 main/binary-amd64/Packages
ed32ebb40f5251c2c7092e4762ba5182 6576 main/binary-amd64/Packages.xz
b632d3e0adade02179345aea4f7e378911706 main/source/Sources
521e5caa8320ed6844d8d00d8ffae230 3391 main/source/Sources.gz
e1a778cb4abd07ee8850690fd7223c53 3204 main/source/Sources.xz
SHA256:
3415dfd1da0adb29f7f989204a8af2547211773deee5b8841bc5156c90ed5bf4
390 Release
435ba654dbacc62253a76bb0124d5a48b37931a5de9c9f1544994d257fcd1eba
142291 main/Contents-all
e745280081045ece9458487cdb6ddda56a4a4748d9e6cce2c412a2ffc0b337f1
7500 main/Contents-all.gz
b98e1b75f71819799d85a6856dd601cf78e5764e46798b1f0096be3c4d1bb78e
175676 main/Contents-amd64
8afd6de519b810ea5fde26475f6480929d1836a242634e27f8aca623d7c7dea2
10927 main/Contents-amd64.gz
e77d863f9b49ce32891de7187e4bc61ae85fd488a806220ad10f87889e70d131
4289 main/binary-all/Packages
ee75247c30a462969739fd55f12c47b1d0c21bf5b4e0cd3cdb75f0fc6ede117c
1924 main/binary-all/Packages.xz
9791f682646d6e379f1f079d38dd0e8d44f81de920c613aee209088248f51d74
20586 main/binary-amd64/Packages
e49ff92a6eec1c263cd61c03095a1a1ffb4d38fc72aa46f1c4b2d93a1954108c
6576 main/binary-amd64/Packages.xz
63caebd698d284035aa6bb797efd32b4ca0eb439f4cc169d6f22bf14bdb77cde
11706 main/source/Sources
9568945331d5d611e8b34490fa4345aeccb224083f77526dde2b2b97b58d186b
3391 main/source/Sources.gz
3e5c258063c02f951c9c3d5191d8698fc0b6edeca8f956efe08e17183535f0d6
3204 main/source/Sources.xz
Thanks.
Bug#1106420: xen-utils-common: block-iscsi script doesn't work when iqn is a prefix of an existing iqn
Package: xen-utils-common
Version: 4.17.5+23-ga4e5191dc0-1+deb12u1
Severity: normal
two issues with block-iscsi
1. If the iqn that is being used as a disk device is a prefix of an
existing in use iqn then xl create will fail with
libxl: error: libxl_device.c:1337:device_hotplug_child_death_cb: script: Device
already opened
My fix is to match a space before and after the iqn.
iscsiadm -m session | grep ' iqn.xen17:trixie17 '
tcp: [32] [fd01:8b0:bfcd:100:230:18ff:fe08:5ad6]:3260,1 iqn.xen17:trixie17
(non-flash)
Without the trailing space:
iscsiadm -m session | grep 'iqn.xen17:trixie17'
tcp: [30] [fd01:8b0:bfcd:100:230:18ff:fe08:5ad6]:3260,1
iqn.xen17:trixie17-build (non-flash)
tcp: [32] [fd01:8b0:bfcd:100:230:18ff:fe08:5ad6]:3260,1 iqn.xen17:trixie17
(non-flash)
2. There's no way to specify the LUN, it seems to always want lun-0. All
of my LUNS are 1, so I've changed the default to 1 rather than 0 but it
needs an extra lun=<> parameter.
diff -u scripts/block-iscsi.distrib scripts/block-iscsi
--- scripts/block-iscsi.distrib 2022-12-29 23:12:25.0 +
+++ scripts/block-iscsi 2025-05-24 16:24:53.0 +
@@ -26,6 +26,8 @@
dir=$(dirname "$0")
. "$dir/block-common.sh"
+LUN=1
+
remove_label()
{
echo $1 | sed "s/^\("$2"\)//"
@@ -59,6 +61,9 @@
multipath=*)
multipath=$(remove_label $param "multipath=")
;;
+lun=*)
+LUN=$(remove_label $param "lun=")
+;;
esac
done
if [ -z "$iqn" ] || [ -z "$portal" ]; then
@@ -73,7 +78,7 @@
find_device()
{
count=0
-while [ ! -e /dev/disk/by-path/*"$iqn"-lun-0 ]; do
+while [ ! -e /dev/disk/by-path/*"$iqn"-lun-"${LUN}" ]; do
sleep 1
count=`expr $count + 1`
if [ count = 100 ]; then
@@ -81,7 +86,7 @@
fatal "timeout waiting for iSCSI disk to settle"
fi
done
-sddev=$(readlink -f /dev/disk/by-path/*"$iqn"-lun-0 || true)
+sddev=$(readlink -f /dev/disk/by-path/*"$iqn"-lun-"${LUN}" || true)
if [ ! -b "$sddev" ]; then
fatal "Unable to find attached device path"
fi
@@ -109,9 +114,9 @@
prepare()
{
# Check if target is already opened
-iscsiadm -m session 2>&1 | grep -q "$iqn" && fatal "Device already opened"
+iscsiadm -m session 2>&1 | grep -q " $iqn " && fatal "Device already
opened"
# Discover portal targets
-iscsiadm -m discovery -t st -p $portal 2>&1 | grep -q "$iqn" || \
+iscsiadm -m discovery -t st -p $portal 2>&1 | grep -q " $iqn\$" || \
fatal "No matching target iqn found"
}
-- System Information:
Debian Release: 12.11
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-35-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages xen-utils-common depends on:
ii libc6 2.36-9+deb12u10
ii libxenhypfs1 4.17.5+23-ga4e5191dc0-1+deb12u1
ii libxenstore4 4.17.5+23-ga4e5191dc0-1+deb12u1
ii lsb-base 11.6
ii python33.11.2-1+b1
ii sysvinit-utils [lsb-base] 3.06-4
ii ucf3.0043+nmu1+deb12u1
ii udev 252.36-1~deb12u1
ii xenstore-utils 4.17.5+23-ga4e5191dc0-1+deb12u1
xen-utils-common recommends no packages.
Versions of packages xen-utils-common suggests:
pn xen-doc
-- Configuration Files:
/etc/xen/scripts/block-iscsi changed:
-- no debconf information
Bug#1106241: e2fsprogs: fuse2fs - rm fails for very large files
Package: e2fsprogs
Version: 1.47.2~rc1-2~bpo12+2
Severity: normal
Dear Maintainer,
when doing rm of a very large file (or possibly just a file whose block
extends past 2^32-1) it fails with
FUSE2FS-remove_inode: put ino=12 links=1
fuse: bad error value: 75
unique: 16, error: -34 (Numerical result out of range), outsize: 16
rm: cannot remove 'mount/filler': Numerical result out of range
rm in debugfs does work. Attached patch replaces the deallocate block
logic with that from debugfs.
This possibly points to a bug in the underlying ext2_punch routine that
fuse2fs is using but I haven't tried to investigate further. This
function is also called from punch_helper so I suspect that using
fallocate to punch holes might also have problems.
Four files are attached:
rm-fix.patch - the actual fix for this bug
test.sh - a short test script to trigger this bug
inusefile.patch - adds support for the -o inusefile= flag that the test
uses. If you don't apply this patch then you'll need to add a large
sleep after the fusermount -u calls instead (c50s is required on my
system)
lseek.patch - irrelevant to this fix but the other two patches are built
on it and will (probably) apply but with line offsets. This adds support
for SEEK_HOLE and SEEK_DATA. I intend to send this upstream eventually
but I've got no time to work on writing any tests right now - but it's
working perfectly for my usecase.
N.B. The test takes around 10-15 minutes to run, most of the time is in
the rm and requires c1.5GB of disk space. It will not clean up properly
if it fails part way through.
Tim.
-- System Information:
Debian Release: 12.11
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-35-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages e2fsprogs depends on:
ii libblkid12.38.1-5+deb12u3
ii libc62.36-9+deb12u10
ii libcom-err2 1.47.0-2
ii libext2fs2 1.47.2~rc1-2~bpo12+2
ii libss2 1.47.0-2
ii libuuid1 2.38.1-5+deb12u3
ii logsave 1.47.0-2
Versions of packages e2fsprogs recommends:
pn e2fsprogs-l10n
Versions of packages e2fsprogs suggests:
pn e2fsck-static
ii fuse2fs1.47.2~rc1-2~bpo12+2
pn gpart
pn parted
-- no debconf information
diff -urN e2fsprogs-1.47.2~rc1.orig/misc/fuse2fs.c
e2fsprogs-1.47.2~rc1/misc/fuse2fs.c
--- e2fsprogs-1.47.2~rc1.orig/misc/fuse2fs.c2024-11-29 08:02:27.0
+
+++ e2fsprogs-1.47.2~rc1/misc/fuse2fs.c 2024-11-29 08:02:27.0 +
@@ -1237,6 +1237,25 @@
return update_mtime(fs, dir, NULL);
}
+static int release_blocks_proc(ext2_filsys fs, blk64_t *blocknr,
+ e2_blkcnt_t blockcnt EXT2FS_ATTR((unused)),
+ blk64_t ref_block EXT2FS_ATTR((unused)),
+ int ref_offset EXT2FS_ATTR((unused)),
+ void *private)
+{
+ blk64_t block = *blocknr;
+ blk64_t *last_cluster = (blk64_t *)private;
+ blk64_t cluster = EXT2FS_B2C(fs, block);
+
+ if (cluster == *last_cluster)
+ return 0;
+
+ *last_cluster = cluster;
+
+ ext2fs_block_alloc_stats2(fs, block, -1);
+ return 0;
+}
+
static int remove_inode(struct fuse2fs *ff, ext2_ino_t ino)
{
ext2_filsys fs = ff->fs;
@@ -1278,8 +1297,11 @@
goto write_out;
if (ext2fs_inode_has_valid_blocks2(fs, (struct ext2_inode *)&inode)) {
- err = ext2fs_punch(fs, ino, (struct ext2_inode *)&inode, NULL,
- 0, ~0ULL);
+ blk64_t last_cluster = 0;
+ ext2fs_block_iterate3(fs, ino, BLOCK_FLAG_READ_ONLY,
+ NULL, release_blocks_proc, &last_cluster);
+// err = ext2fs_punch(fs, ino, (struct ext2_inode *)&inode, NULL,
+//0, ~0ULL);
if (err) {
ret = translate_error(fs, ino, err);
goto write_out;
#!/bin/bash
set -e
ROOT=mount
DEV=container_mount/pv1
rm -f container
rm -fr container_mount
rm -fr mount
mkdir -p container_mount
# create a container fs that can hold a 5T sparse file
truncate -s 3G container
/sbin/mke2fs -t ext4 -O \
none,has_journal,ext_attr,dir_index,filetype,extent,64bit,flex_bg,sparse_super,large_file,huge_file,dir_nlink,extra_isize,metadata_csum
\
-b 4096 container
fuse2fs -o fakeroot -o inusefile=container.inuse container container_mount
mkdir -p "$ROOT"
echo "truncate $(date)"
time truncate -s 5T "${DEV}"
echo "mke2fs $(date)"
time /sbin/mkfs.ext4 -N 100 -O \
none,has_journal,ext_attr,dir_index,filetype,extent,64bit,flex_bg,sparse_super,large_file,huge_file,dir_nlink,ex
Bug#1106241: e2fsprogs: fuse2fs - rm fails for very large files
For reasons I don't understand I don't get notified about updates to
bugs so this isn't a proper reply but I've cut and pasted your comments
from the bug report.
/me is on vacation today, but here's my hot take on the patches attached
to 1106241:
rm-fix.patch: we really need to figure out why that's borking up the
extent tree -- is it the punch itself that leaves things in a ruined
state, or something else that set up the tree that way? I noticed in my
stupid testing of non-iomap fuse2fs that if I fallocated 600M, wrote all
600M, and then did random reads/writes that I'd end up with a similarly
broken extent tree.
At least for my test, doing the rm via
debugfs -w -R "rm filler" "${DEV}"
works without issue (my fix is just a cut and paste of what debugfs does
in place of the call to ext2fs_punch) so I don't think the extent tree
is corrupted at this point.
test.sh: oooh reproducer, thank you!
inusefile.patch: Have you observed that umounting a fuse2fs mount
returns immediately but the fuse2fs server itself keeps running (and
flushing dirty data to disk) for several seconds more? That I think is
a bug/antifeature in the kernel and the solution to that is to move to a
fuseblk mount. OTOH if you're actually seeing this with regular files
then yeah, some other kind of locking is needed.
Yes, I'm seeing this with regular files being mounted and for test.sh on
my system it's around 50s
(Note that this is inside another fuse mount as the system I'm running
the tests on has 1K blocks so I cannot create a 5T sparse file to
contain the filesystem)
tim@dirac:/mnt/nobackup/test-fuse (none)$ truncate -s 5T fs
truncate: failed to truncate 'fs' at 5497558138880 bytes: File too large
For the most recent run of test.sh:
mke2fs of a 5T filesystem:
real0m48.137s
Creating the 4T file:
make filler Thu 22 May 19:21:21 BST 2025 - this is slow
real1m45.895s
Umounting after that:
fusermount -u mount Thu 22 May 19:23:07 BST 2025
real0m0.004s
but...
Waiting for fuse to complete
Waiting for fuse to complete
Waiting for fuse to complete
Waiting for fuse to complete
It takes 30-40s to finishe and actually remove that lock file after it
returns.
rm filler (with the latest patches)
rm filler Thu 22 May 19:24:10 BST 2025 - this is slow
real8m18.754s
unmounting again:
fusermount -u mount Thu 22 May 19:32:29 BST 2025
real0m0.004s
but...
Waiting for fuse to complete
Waiting for fuse to complete
Waiting for fuse to complete
https://lore.kernel.org/linux-ext4/174786678650.1385354.14994099236248944550.stgit@frogsfrogsfrogs/T/#t
I will give that a try but won't be until the weekend.
lseek.patch: Yeah, that seems to work, though one fringe benefit of
hooking fuse2fs up to iomap is that you get FIEMAP and SEEK_{DATA,HOLE}
for free, in addition to much better performance:
https://lore.kernel.org/linux-ext4/174787198370.1484996.3340565971108603226.stgit@frogsfrogsfrogs/T/#u
I will give this a try too.
FWIW, they're not pushed yet, but I've ported all of the tests here:
https://sourceforge.net/p/dump/code/ci/main/tree/testing/scripts/
to work with libfuse so I can work on this without being root and all
pass (with the exception of a couple that I expect to take an
inordinately long length of time that I haven't tried yet)
The lseek patch is a modified version of code from here :-)
Tim.
Bug#1106241: e2fsprogs: fuse2fs - rm fails for very large files
Patches redone. Main changes:
rename inusefile -> lockfile
check the error code from ext2fs_block_iterate3
diff -urN e2fsprogs-1.47.2~rc1.orig/misc/fuse2fs.c e2fsprogs-1.47.2~rc1/misc/fuse2fs.c
--- e2fsprogs-1.47.2~rc1.orig/misc/fuse2fs.c 2024-11-29 08:02:27.0 +
+++ e2fsprogs-1.47.2~rc1/misc/fuse2fs.c 2024-11-29 08:02:27.0 +
@@ -1238,6 +1238,25 @@
return update_mtime(fs, dir, NULL);
}
+static int release_blocks_proc(ext2_filsys fs, blk64_t *blocknr,
+ e2_blkcnt_t blockcnt EXT2FS_ATTR((unused)),
+ blk64_t ref_block EXT2FS_ATTR((unused)),
+ int ref_offset EXT2FS_ATTR((unused)),
+ void *private)
+{
+ blk64_t block = *blocknr;
+ blk64_t *last_cluster = (blk64_t *)private;
+ blk64_t cluster = EXT2FS_B2C(fs, block);
+
+ if (cluster == *last_cluster)
+ return 0;
+
+ *last_cluster = cluster;
+
+ ext2fs_block_alloc_stats2(fs, block, -1);
+ return 0;
+}
+
static int remove_inode(struct fuse2fs *ff, ext2_ino_t ino)
{
ext2_filsys fs = ff->fs;
@@ -1279,8 +1298,9 @@
goto write_out;
if (ext2fs_inode_has_valid_blocks2(fs, (struct ext2_inode *)&inode)) {
- err = ext2fs_punch(fs, ino, (struct ext2_inode *)&inode, NULL,
- 0, ~0ULL);
+ blk64_t last_cluster = 0;
+ err = ext2fs_block_iterate3(fs, ino, BLOCK_FLAG_READ_ONLY,
+ NULL, release_blocks_proc, &last_cluster);
if (err) {
ret = translate_error(fs, ino, err);
goto write_out;
diff -urN e2fsprogs-1.47.2~rc1.orig/misc/fuse2fs.c e2fsprogs-1.47.2~rc1/misc/fuse2fs.c
--- e2fsprogs-1.47.2~rc1.orig/misc/fuse2fs.c 2024-11-29 08:02:27.0 +
+++ e2fsprogs-1.47.2~rc1/misc/fuse2fs.c 2024-11-29 08:02:27.0 +
@@ -348,6 +348,8 @@
unsigned long offset;
FILE *err_fp;
unsigned int next_generation;
+ int haslockfile;
+ char* lockfile;
};
#define FUSE2FS_CHECK_MAGIC(fs, ptr, num) do {if ((ptr)->magic != (num)) \
@@ -3873,6 +3875,8 @@
FUSE2FS_OPT("no_default_opts", no_default_opts, 1),
FUSE2FS_OPT("norecovery", norecovery, 1),
FUSE2FS_OPT("offset=%lu", offset, 0),
+ FUSE2FS_OPT("lockfile", haslockfile, 1),
+ FUSE2FS_OPT("lockfile=%s", lockfile, 0),
FUSE_OPT_KEY("-V", FUSE2FS_VERSION),
FUSE_OPT_KEY("--version", FUSE2FS_VERSION),
@@ -3914,6 +3918,8 @@
"-o offset= similar to mount -o offset=, mount the partition starting at \n"
"-o norecovery don't replay the journal (implies ro)\n"
"-o fuse2fs_debug enable fuse2fs debugging\n"
+ "-o lockfileuse .lck to show that fuse is still using the file system image\n"
+ "-o lockfile= file to show that fuse is still using the file system image\n"
"\n",
outargs->argv[0]);
if (key == FUSE2FS_HELPFULL) {
@@ -3975,7 +3981,7 @@
fctx.err_fp = fopen(logfile, "a");
if (!fctx.err_fp) {
perror(logfile);
- goto out;
+ exit(1);
}
} else
fctx.err_fp = stderr;
@@ -3987,6 +3993,42 @@
fctx.alloc_all_blocks = 1;
}
+ ret = 1;
+ if (fctx.haslockfile && !fctx.lockfile) {
+ fctx.lockfile = malloc(strlen(fctx.device) + 5);
+ if (!fctx.lockfile) {
+ fprintf(stderr, "Out of memory\n");
+ goto out;
+ }
+ strcpy(fctx.lockfile, fctx.device);
+ strcat(fctx.lockfile, ".lck");
+ }
+ if (fctx.lockfile) {
+ int fd = open(fctx.lockfile, O_CREAT | O_EXCL | O_WRONLY, 0400);
+ if (fd == -1) {
+ if (errno == EEXIST)
+fprintf(stderr, "Requested lockfile=%s but it already exists\n", fctx.lockfile);
+ else
+fprintf(stderr, "Requested lockfile=%s but couldn't create: %s\n", fctx.lockfile, strerror(errno));
+ free(fctx.lockfile);
+ fctx.lockfile = NULL;
+ goto out;
+ }
+ close(fd);
+ char resolved[PATH_MAX];
+ if (!realpath(fctx.lockfile, resolved)) {
+ fprintf(stderr, "Could not resolve realpath for lockfile=%s: %s\n", fctx.lockfile, strerror(errno));
+ goto out;
+ }
+ char* resolveddup = strdup(resolved);
+ if (!resolveddup) {
+ fprintf(stderr, "Out of memory\n");
+ goto out;
+ }
+ free(fctx.lockfile);
+ fctx.lockfile = resolveddup;
+ }
+
/* Start up the fs (while we still can use stdout) */
ret = 2;
if (!fctx.ro)
@@ -4107,6 +4149,11 @@
com_err(argv[0], err, "while closing fs");
global_fs = NULL;
}
+ if(fctx.lockfile) {
+ err = unlink(fctx.lockfile);
+ if (err)
+ com_err(argv[0], err, "unlink: %s while unlinking '%s'", strerror(errno), fctx.lockfile);
+ }
return ret;
}
test.sh
Description: Bourne shell script
diff -urN e2fsprogs-1.47.2~rc1.orig/misc/fuse2fs.c e2fsprogs-1.47.2~rc1/misc/fuse2fs.c
--- e2fsprogs-1.47.2~rc1.orig/misc/fuse2fs.c 2024-11-29 08:02:27.0 +
+++ e2fsprogs-1.47.2~rc1/misc/fuse2fs.c 2024-11-29 08:02:27.0 +
@@ -2040,6 +2040,147 @@
return ret;
}
+struct block_context {
+ e2_blkcnt_t next_block;
+ off_t blksize;
+ off_t offset;
+ off_t pos;
+ off_t next_hole;
+ off_t next_data;
+};
+
+static int
+dumponeblock(ext2_filsys fs, blk64_t *blocknr, e2_blkcnt_t blockcnt,
+ blk64_t ref_block, int ref_offset, void * privdata)
Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs
On Wed, 2 Jul 2025, Theodore Ts'o wrote: On Wed, Jul 02, 2025 at 07:44:24PM +0100, Tim Woodall wrote: So it seems that my change is only needed on older kernels. OK, thanks for the hint. Using the same fuse2fs binary (built in a bookworm-amd64 chroot), I can replicate what you're seeing on 6.1.142: The thing is, for the ACL types in question, the kernel shouldn't even be looking at e_id; that field is undefined for ACL_USER_OBJ, ACL_GROUP_OBJ, et.al, since the kernel would be using the inode's user and group ownership, and for ACL_MASK and ACL_OTHER there is no id number to be used. So the kernel shouldn't even be *looking* at that field. So whether the value is 0 or -1 shouldn't make a difference. And change that I don't understand always give me pause I agree. I tried digging through the kernel code but I couldn't work out where the -1 wad coming from when not using fuse. I thought zero seemed more likely! If I followed the right bits there's a kvzmalloc where it goes to userspace. I gave up at this point, I don't know kernel programming and I was probably wasting my time. BTW, what caused you to think that -1 might fix things on a Bookworm 6.1 kernel? Here is near identical code: https://sourceforge.net/p/dump/code/ci/main/tree/restore/xattr.c#l284 and this is how I found it (by luck) when an EA failed to verify. I patched this code (to match libext2fs) and then recently discovered that it wad now failing when not testing on fuse. I don't think this 0/-1 value is used, it's just exposed via the getfattr interface to this EA. Tim.
Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs
On Tue, 1 Jul 2025, Theodore Ts'o wrote: On Mon, Jun 30, 2025 at 07:08:58PM +0100, Tim Woodall wrote: Package: e2fsprogs Version: 1.47.0-2 Severity: minor Dear Maintainer, Without using fuse at all: # touch x # setfacl -m u:root:rw x # getfattr -m - -d x # file: x system.posix_acl_access=0sAgEABgD/AgAGAAAEAAQA/xAABgD/IAAEAP8= When done via fuse2fs: # which fuse2fs /usr/bin/fuse2fs # mkdir mnt # fuse2fs img mnt # touch mnt/x # setfacl -m u:root:rw mnt/x # getfattr -m - -d mnt/x # file: mnt/x system.posix_acl_access=0sAgEABgAAAgAGAAAEAAQAABAABgAAIAAEAAA= Hmm, I can't replicate this on e2fsprogs 1.47.3~rc2-1. I believe this was fixed by this commit: commit 0111bdb70a9c460052387111414a2e2dc8c06822 Author: Darrick J. Wong Date: Thu Apr 24 14:41:49 2025 -0700 fuse2fs: remove posix acl translation Remove the POSIX ACL format translation since libext2fs takes care of that now. This is very strange. I cannot reproduce it on a trixie machine root@trixie17-build:/build# fuse2fs -V fuse2fs 1.47.2 (1-Jan-2025) FUSE library version 3.17.2 using FUSE kernel interface version 7.40 fusermount3 version: 3.17.2 root@trixie17-build:/build# apt-cache policy fuse2fs fuse2fs: Installed: 1.47.2-3+b1 root@trixie17-build:~# uname -a Linux trixie17-build.home.woodall.me.uk 6.12.27-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.27-1 (2025-05-06) x86_64 GNU/Linux root@trixie17-build:~# setfacl -m u:root:rw mnt/x root@trixie17-build:~# getfattr -m - -d mnt/x # file: mnt/x system.posix_acl_access=0sAgEABgD/AgAGAAAEAAQA/xAABgD/IAAEAP8= But when I build the latest code from master on a bookworm machine I can: root@dirac:/build/dump-sf/testing/scripts# /tmp/fuse2fs -V fuse2fs 1.47.3-rc2 (12-Jun-2025) FUSE library version 3.14.0 using FUSE kernel interface version 7.31 fusermount3 version: 3.14.0 root@dirac:/build/dump-sf/testing/scripts# uname -a Linux dirac.home.woodall.me.uk 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux root@dirac:/build/dump-sf/testing/scripts# getfattr -m - -d mnt/x # file: mnt/x system.posix_acl_access=0sAgEABgAAAgAGAAAEAAQAABAABgAAIAAEAAA= And I've just realized that the trixie version is in bookworm-backports. Installing that and I get the same: root@dirac:/build/dump-sf/testing/scripts# apt-cache policy fuse2fs fuse2fs: Installed: 1.47.2-3~bpo12+1 root@dirac:/build/dump-sf/testing/scripts# fuse2fs -V fuse2fs 1.47.2 (1-Jan-2025) FUSE library version 3.14.0 using FUSE kernel interface version 7.31 fusermount3 version: 3.14.0 root@dirac:/build/dump-sf/testing/scripts# getfattr -m - -d mnt/x # file: mnt/x system.posix_acl_access=0sAgEABgAAAgAGAAAEAAQAABAABgAAIAAEAAA= So it seems that my change is only needed on older kernels. Tim.
Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs
Package: e2fsprogs Version: 1.47.0-2 Severity: minor Dear Maintainer, Without using fuse at all: # touch x # setfacl -m u:root:rw x # getfattr -m - -d x # file: x system.posix_acl_access=0sAgEABgD/AgAGAAAEAAQA/xAABgD/IAAEAP8= When done via fuse2fs: # which fuse2fs /usr/bin/fuse2fs # mkdir mnt # fuse2fs img mnt # touch mnt/x # setfacl -m u:root:rw mnt/x # getfattr -m - -d mnt/x # file: mnt/x system.posix_acl_access=0sAgEABgAAAgAGAAAEAAQAABAABgAAIAAEAAA= # umount mnt # /tmp/fuse2fs img mnt # getfattr -m - -d mnt/x # file: mnt/x system.posix_acl_access=0sAgEABgD/AgAGAAAEAAQA/xAABgD/IAAEAP8= # umount mnt Note that the one run with my patched libext2fs gets the same value as without using fuse without rewriting the attribute showing that this is a read issue only. diff --git a/lib/ext2fs/ext_attr.c b/lib/ext2fs/ext_attr.c index 7723d0f9..d09a13da 100644 --- a/lib/ext2fs/ext_attr.c +++ b/lib/ext2fs/ext_attr.c @@ -671,7 +671,7 @@ static errcode_t convert_disk_buffer_to_posix_acl(const void *value, size_t size case ACL_GROUP_OBJ: case ACL_MASK: case ACL_OTHER: - entry->e_id = 0; + entry->e_id = -1; cp += sizeof(ext4_acl_entry_short); size -= sizeof(ext4_acl_entry_short); break; -- System Information: Debian Release: 12.11 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-37-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages e2fsprogs depends on: ii libblkid12.38.1-5+deb12u3 ii libc62.36-9+deb12u10 ii libcom-err2 1.47.0-2 ii libext2fs2 1.47.0-2 ii libss2 1.47.0-2 ii libuuid1 2.38.1-5+deb12u3 ii logsave 1.47.0-2 Versions of packages e2fsprogs recommends: pn e2fsprogs-l10n Versions of packages e2fsprogs suggests: pn e2fsck-static ii fuse2fs1.47.0-2 pn gpart pn parted -- no debconf information
