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#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#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 , 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 , 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 , 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#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 , 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 , 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 , 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 , 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,
@@
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 , 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 , 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 , 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::string
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#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#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#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#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#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#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#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_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 = >conffiles;
@@ -371,6 +372,12 @@
conffvalue_lastword(value, endfn, endent, , , ,
ps);
+write_once = (hashlen == sizeof(write_once_str) - 1 &&
+ memcmp(hashstart, write_once_str, hashlen) == 0);
+if (write_once)
+ conffvalue_lastword(value, endfn, endent, , , ,
+ 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= >next;
diff -urN dpkg-1.20.7.1.orig/lib/dpkg/fsys.h
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#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, 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#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
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 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#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
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#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#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#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#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
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#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#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#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#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#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#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#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=detailaid=3133762group_id=1306atid=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-requ...@lists.debian.org
with a subject
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#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#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 none (no description available) Versions of packages xscreensaver suggests: pn fortune none (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 none (no description available) pn xdaliclock none (no description available) pn xfishtank none (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#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#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: snip 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#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#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
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#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: none 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#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#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 lct/utils.h
#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);}
-RVALUE{Literal}
{return((yylval=ksymtocode(yytext))==-1?ERROR:LITERAL);}
+RVALUE{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);
+
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#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; pbuf; 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]
