Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)
I'm also seeing this issue, also on a Debian Linux 4.19 kernel (on updated Debian unstable VM), also on KVM, straight after rebooting the VM. But without any suspending involved, I just reboot the VM, and as soon as I can log in after rebooting its showing 6+ days of uptime. The uptime jumps *very* early in the boot sequence, at the point that kvm-clock starts reporting, by many days in my case. Of note, the KVM host here is pretty old (Ubuntu 14.04 LTS, on 3.13.0-164-generic kernel, and qemu-kvm 2.0.0+dfsg-2ubuntu1.44). It's also naturally a fairly old CPU (Intel Xeon X3450). So I wonder if part of the trigger is newer (4.19) kernels relying on CPU/hypervisor features that older CPUs / older hypervisors do not provide/initialise. And maybe reading an uninitialised value as a result. From reading the upstream thread, this seems the closest to diagnosis: https://lore.kernel.org/lkml/20190126020410.gb3...@feynman.vault24.org/ around guest clock sources being chosen, and apparently the upstream maintainer has managed to reproduce the issue: https://lore.kernel.org/lkml/20190126161137.gme4vsrz3xmnc...@soleen.tm1wkky2jk1uhgkn0ivaxijq1c.bx.internal.cloudapp.net/ by changing the clock source (to HPET), as of late Jan 2019. Ewen -=- cut here -=- ewen@debian-unstable:~$ uptime 11:21:06 up 6 days, 22:40, 1 user, load average: 0.88, 0.75, 0.52 ewen@debian-unstable:~$ last | head -5 ewen pts/0172.20.254.10Mon Feb 11 11:10 still logged in reboot system boot 4.19.0-2-amd64 Mon Feb 11 11:07 still running ewen ttyS0 Mon Feb 11 11:06 - down (00:00) ewen pts/0172.20.254.10Mon Feb 11 11:06 - down (00:00) reboot system boot 4.19.0-2-amd64 Mon Feb 11 11:05 - 11:06 (00:01) ewen@debian-unstable:~$ date Mon Feb 11 11:21:21 NZDT 2019 ewen@debian-unstable:~$ ewen@debian-unstable:~$ uname -r 4.19.0-2-amd64 ewen@debian-unstable:~$ dpkg -l | grep linux-image ii linux-image-4.19.0-1-amd64 4.19.13-1 amd64Linux 4.19 for 64-bit PCs (signed) ii linux-image-4.19.0-2-amd64 4.19.16-1 amd64Linux 4.19 for 64-bit PCs (signed) ii linux-image-amd644.19+102 amd64Linux for 64-bit PCs (meta-package) ewen@debian-unstable:~$ ewen@debian-unstable:~$ sudo dmesg | grep -A 4 "Hypervisor" [0.00] Hypervisor detected: KVM [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [599207.077513] kvm-clock: cpu 0, msr 117d7001, primary cpu clock [599207.077513] clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [599207.077516] tsc: Detected 2659.982 MHz processor ewen@debian-unstable:~$ ewen@debian-unstable:~$ sudo dmesg | head -20 | grep -v BIOS-e820 [0.00] Linux version 4.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-14)) #1 SMP Debian 4.19.16-1 (2019-01-17) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-2-amd64 root=UUID=260df8b9-6a61-4f0e-9625-340dcdaf4017 ro console=ttyS0,9600 [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [0.00] Hypervisor detected: KVM [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [599207.077513] kvm-clock: cpu 0, msr 117d7001, primary cpu clock [599207.077513] clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [599207.077516] tsc: Detected 2659.982 MHz processor [599207.078351] e820: update [mem 0x-0x0fff] usable ==> reserved ewen@debian-unstable:~$ -=- cut here -=- -=- cut here -=- ewen@naosdell:~$ head -5 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Xeon(R) CPU X3450 @ 2.67GHz ewen@naosdell:~$ -=- cut here -=-
Bug#774851: torrus-common: cronjob produces output /srv/torrus/collector_rrd: No such file or directory
Andreas Beckmann a...@debian.org wrote:
3m11.8s DUMP:
find: `/srv/torrus/collector_rrd': No such file or directory
This output is also produced when the package is still installed. From
looking into the cron output, it appears to be a result of
/etc/cron.daily/torrus-common
calling
/usr/share/torrus/scripts/rrdup_notify
every day if the script is installed and executable, and that file is a
shell script which contains:
-=- cut here -=-
[...]
# Where the RRD files are located. Separate multiple paths with space
RRDSTORAGE=/srv/torrus/collector_rrd
[...]
for d in ${RRDSTORAGE}; do
find ${d} -name '*.rrd' ! -name '*.old.rrd' \
-mmin +${MAXAGE} -print ${TMPFILE}
done
-=- cut here -=-
On a Debian install, /srv/torrus/collector_rrd does not exist, hence the
find output. However it is the upstream default location for storing
RRD files (see, eg, http://torrus.org/manpages/torrus_genddx.pod.html).
So it seems likely this is a file that didn't get patched to be updated
with Debian's default location for storing RRD files, viz
/var/lib/torrus/collector_rrd/.
AFAICT this wouldn't happen when the package is removed, because
/usr/share/torrus/scripts/rrdup_notify doesn't appear to be a conffile
(eg, dpkg --status torrus-common | grep scripts returns nothing) so in
theory it should be removed when the package is removed, and thus the
cron.daily script shouldn't run it. From a quick skim of the log
attached to the bug it looks like piuparts failed to remove the package
(due to trying to remove too many packages, one which was needed by
something else), and then ran the cron job with the package still
installed. So this may only happen when the package is _installed_.
It'd still be helpful if that script
(/usr/share/torrus/scripts/rrdup_notify) could get patched to point at
the Debian location for RRD files, rather than the upstream default.
Thanks,
Ewen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775702: caff: Using gpg-agent without GPG_TTY causes silent caff failures
For completeness, with the help of an insightful question asked by the MacPorts signing-party package maintainer I re-discovered that I'd put in a shell script wrapper around gpg, which attempted to auto-set GPG_TTY from stdin or stderr. Because (from reading the comments in the script; this script was clearly written Many Years Ago) I'd had other tricky-to-debug errors with gpg and the agent where GPG_TTY was not set. So the why only me part is explained by it being self-inflicted (the wrapper script exited with an error if (a) GPG_TTY was not already set and (b) stdin was not a tty and (c) stderr was not a tty -- which ironically was set to /dev/null). Thanks for your help in debugging this, and taking the patch to make it a bit easier to debug in future. Apologies for the noise. I think it'd be perfectly fine to close the bug at this point :-) Ewen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775702: caff: Using gpg-agent without GPG_TTY causes silent caff failures
On 23/01/15 13:20, Guilhem Moulin wrote: [T]he next step would be to mail gnupg-de...@gnupg.org, at least if the culprit is not the OSX maintainer (I dunno how things work there; assuming these macports are not built by upstream). MacPorts is basically FreeBSD ports, for Mac OS X. So it functions roughly equivalently to, eg, Gentoo -- the portfile points at where to download the source, what dependencies need to be installed before building, and provides some build/install instructions (which in some cases might include some MacPorts-specific patches). The MacPorts project maintains the port files, and typically user's own computers actually build the software, so upstream isn't involve unless someone pushes patches up to them (or reports bugs to them). The gnupg portfile is here: https://trac.macports.org/browser/trunk/dports/mail/gnupg/Portfile and it only points at one patch: https://trac.macports.org/browser/trunk/dports/mail/gnupg/files/patch-gpg_agent-launchd.diff which seems tiny, and I suspect unrelated to the problem. So in theory this is upstream code triggering it for some reason. But it'd probably take a bunch of debugging to figure out why. I might try to have a look one day when I have a few hours spare, but it won't be this month :-) (And yes, if someone does find the root cause then taking that to the GnuPG upstream seems like the obvious next step.) (Completely random hunch: maybe there's something Linux specific that is able to look in, eg, /proc for the tty and recover from stderr being redirected that way. If so it'd be a happens to work on Linux situation rather than a fails only on OS X situation.) Alright. How about an error [on OS X if GPG_TTY is not set] then? That would be okay with me. I was suggesting a warning only to avoid forcing everyone to set GPG_TTY to continue. But maybe they have to set it to get sensible use anyway. While I agree a warning might be hard to spot, if it's near the start of the output and people do have problems there's a decent chance they'll scroll back far enough to spot it. So either is fine with me. Great. The manpage includes some of it already, but TBH I didn't know SSL_CERT_DIR/SSL_CERT_FILE would affect the server authentication. Me neither, until I spent a while digging through the various perl modules invoked via Mail::Mailer, looking for a way to get it to accept my organisation-wide CA. (Recent perl versions do actually do reasonable SSL certificate validation by default; and Mail::Mailer and friends do not have a way to pass through the parameters to override/fine tune that. Hence resorting to stuffing things into %ENV.) Ewen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775702: caff: Using gpg-agent without GPG_TTY causes silent caff failures
On 21/01/15 6:05, Guilhem Moulin wrote: Your report says you have signing-party 1.1.4-1, but your patch seems to be against a more recent version :-P Yes, the patch was originally written for the version in OS X MacPorts, which is currently between the version in Debian Stable and Debian Unstable. I ran reportbug on a Wheezy system, so it picked up the 1.1.4-1 version there. I thought it'd cause more confusion manually editing it, so I left it alone. gpg --version gpg --trust-model=always --no-auto-check-trustdb --fingerprint --with-colons --list-public-keys --no-tty --batch -- KEYID /dev/null That should be the faulting command; it works here, even after a ‘unset GPG_TTY’.[...] Thanks for investigating. For completeness, the test command needs to have stderr redirected to /dev/null as well (ie, 2/dev/null), as that was what was triggering it when caff did it (and the --list-public-keys is being run by caff with stderr redirected to /dev/null). Trying that on Debian Stable (gpg 1.4.12), Debian Unstable (gpg 1.4.18) and the OS X/MacPorts build (gpg 1.4.18) gives some puzzling results: - Debian Wheezy (gpg 1.4.12): works, with (and without) stderr redirected to /dev/null - Debian Unstable (gpg 1.4.18): works, with (and without) stderr redirected to /dev/null - MacPorts (OS X) (gpg 1.4.18): works _without_ sderr redirected, fails with stderr redirected (no output, exit code 1), unless GPG_TTY is set then it works again. GPG_AGENT_INFO doesn't seem to need to be set to trigger the problem. Full command output below for reference (the cut used just to avoid someone's email addresses ended up indexed on the web...). I'll take the works on Debian, fails on OS X back to the MacPorts ticket (https://trac.macports.org/ticket/46601). But I do think it'd be helpful if caff would either (a) not redirect stderr or (b) ensure that GPG_TTY is set when stderr is being redirected. Since those seem to be the two safe ways to run gpg reliably. Since it appears that gpg-agent is not related feel free to update the ticket title. Ewen PS: In case it helps, this is the MacPorts build file for GPG: https://trac.macports.org/browser/trunk/dports/mail/gnupg/Portfile I don't obviously see compile options that should cause different behaviour from Debian/Linux here, but maybe this is build option related. -=- debian stable -=- ewen@fileserver:~$ cat /etc/debian_version 7.7 ewen@fileserver:~$ gpg --version gpg (GnuPG) 1.4.12 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ewen@fileserver:~$ gpg --trust-model=always --no-auto-check-trustdb --fingerprint --with-colons --list-public-keys --no-tty --batch -- E4D3E863 /dev/null | cut -d : -f 1-9 tru:t:1:1421789858:0:3:1:5 pub:-:4096:1:4B53D931E4D3E863:2014-02-20:::- fpr uid:-2014-04-08::88B8E69DFB8879D35E0E1175A2DF0CAB293C25B6: uid:-2014-04-08::8A5CEE366E5F7EC4848EEA7A36061D438A9DBDA3: uid:-2014-04-08::848AF9F923716ACEDDF0731C43D87B12EC7B2A1C: uid:-2014-04-08::43CEEE6796FE783AB240EED811DB5EA31F901A04: uid:-2014-04-08::8A690AF6EF357372EA0D60A3C7625327A64D992C: sub:-:4096:1:9CF0A2343CD15819:2014-02-20::: ewen@fileserver:~$ gpg --trust-model=always --no-auto-check-trustdb --fingerprint --with-colons --list-public-keys --no-tty --batch -- E4D3E863 /dev/null 2/dev/null | cut -d : -f 1-9 tru:t:1:1421789858:0:3:1:5 pub:-:4096:1:4B53D931E4D3E863:2014-02-20:::- fpr uid:-2014-04-08::88B8E69DFB8879D35E0E1175A2DF0CAB293C25B6: uid:-2014-04-08::8A5CEE366E5F7EC4848EEA7A36061D438A9DBDA3: uid:-2014-04-08::848AF9F923716ACEDDF0731C43D87B12EC7B2A1C: uid:-2014-04-08::43CEEE6796FE783AB240EED811DB5EA31F901A04: uid:-2014-04-08::8A690AF6EF357372EA0D60A3C7625327A64D992C: sub:-:4096:1:9CF0A2343CD15819:2014-02-20::: ewen@fileserver:~$ -=- debian stable -=- -=- debian unstable -=- ewen@debian-unstable:~$ cat /etc/debian_version 8.0 ewen@debian-unstable:~$ gpg --version gpg (GnuPG) 1.4.18 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB,
Bug#775702: caff: Using gpg-agent without GPG_TTY causes silent caff failures
On 21/01/15 13:24, Guilhem Moulin wrote:
On Wed, 21 Jan 2015 at 11:12:44 +1300, Ewen McNeill wrote:
- MacPorts (OS X) (gpg 1.4.18): works _without_ sderr redirected, fails with
stderr redirected (no output, exit code 1), unless GPG_TTY is set then it
works again.
Wow that's odd.
I agree, it's pretty odd. My best guess is that there must be a code
path along the lines of do we have a way to tell the user about
Important Information, and it's failing out if it does (ie, stderr
redirected, no GPG_TTY to re-open to send messages). But I don't know
why it's OS X specific/MacPorts specific/whatever. And just exit,
error code 1 is hardly the most graceful way to handle it.
FTR, I've just verified it still happens like that (on OS X) even if I
move ~/.gnupg/gpg.conf aside, so it doesn't seem to be specific to my
gpg config either (I had wondered if having use-agent in there was
needed to trigger it, but apparently not).
I can't remember of a reason to redirect stderr, and right now it
doesn't seem like a good idea to me.
My best guess when trying to read the caff code was that it was done at
that point to hide gpg saying it couldn't find a key. But I think for
most reasonable use cases that shouldn't be reported often, and for most
cases where it is the user probably wants to see gpg report that anyway
(to help them figure out what is going wrong).
I'm a bit reluctant to modify the
environment though, especially since it's a weird behavior of GnuPG –
and OSX specific :-P — IMHO.
FWIW, I wasn't suggesting that caff should modify the environment. Just
issue a warning (eg, like the one about Mail::Mailer having config that
may or may not be right).
Eg, (completely untested; adjust to taste)
if (defined($ENV{MACHTYPE})
$ENV{MACHTYPE} =~ /apple/ ! defined($ENV{'GPG_TTY'})) {
warn warning: Certain gpg actions may fail if GPG_TTY is not set, ,
causing silent caff failures.\n;
}
But maybe there should be some other conditional on it (eg, if it's a
gpg build option that is the real trigger). (FTR: $MACHTYPE =
x86_64-apple-darwin13 on my OS X 10.9 system.)
So all in all I pushed your patch in r760.
Thanks. For future reference, there seems to be at least one other set
of gpg commands that caff uses (after the keys are signed, to figure out
what to send) which also fails without GPG_TTY set, but I didn't debug
that one as thoroughly once I'd guessed that setting GPG_TTY was a
viable workaround.
My blog post about caff on OS/X may possibly help someone else running
into the same issue:
http://ewen.mcneill.gen.nz/blog/entry/2015-01-19-keysigning-with-caff/
(and it also has a reasonable guide to Mail::Mailer settings for doing
SMTP Auth to an external mail server.)
Ewen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775702: caff: Using gpg-agent without GPG_TTY causes silent caff failures
Package: signing-party Version: 1.1.4-1 Severity: normal Initially encountered on OS/X with MacPorts (https://trac.macports.org/ticket/46601), but reported here because (a) Debian appears to be the upstream for signing-party/caff (http://pgp-tools.alioth.debian.org/) and (b) AFAICT by inspection the same problem would happen on Debian (which I also use), up through the version in Debian Unstable. (Email generated with reportbug from representative Debian Stable system.) When using caff with gpg-agent installed and active, but the GPG_TTY environment variable is not set, certain operations that caff attempts to get gpg to do silently fail, which cases caff to issue misleading error messages. These appear to be primarily the ones where caff is redirecting stderr to /dev/null (but there may be other cases too). In particular with GPG_AGENT_INFO=... and GPG_TTY not set, for a key that _does_ exist, caff is unable to find the key: -=- cut here -=- ewen@ashram:~$ caff --keys-from-gnupg -R e4d3e863 [INFO] Key E4D3E863 imported from your normal GnuPGHOME. [WARN] No public keys found with list-key E4D3E863 (note that caff uses its own keyring in /Users/ewen/.caff/gnupghome). [NOTICE] No keys to sign found ewen@ashram:~$ -=- cut here -=- The problem goes away (ie, caff finds the key) if (a) the caff source is edited to not redirect stderr in that situation (eg, diff on https://trac.macports.org/ticket/46601) or (b) GPG_TTY is set. Even if that particular problem is worked around, caff's use of gpg to extract the signed subkeys also fails if gpg-agent is in use, but GPG_TTY is not used, resulting in caff exiting without offering to email keys. By uncommenting trace2 one can see the error report for the latter case: [trace2] stderr is now GPG_TTY must be set in shell (cannot determine automatically). which is what (eventually!) gave me the clue to the underlying cause. In view of how difficult this is for a user to debug (eg, determine this is the real cause), especially because caff is deliberately redirecting stderr to /dev/null and thus hiding the gpg generated error messages (!!) I think it would be best if caff were to warn about this risk. Eg, if GPG_AGENT_INFO is set in the environment and GPG_TTY is *not* set in the environment, then caff should at least issue a warning that there may be silent failures and unpredictable behaviour (and possibly should refuse to continue in that situation). Ewen -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages signing-party depends on: ii gnupg 1.4.12-7+deb7u6 ii libc6 2.13-38+deb7u6 ii libclass-methodmaker-perl 2.18-1+b1 ii libgnupg-interface-perl0.45-1 ii libmailtools-perl 2.09-1 ii libmime-tools-perl 5.503-1 ii libterm-readkey-perl 2.30-4+b2 ii libtext-template-perl 1.45-2 ii perl 5.14.2-21+deb7u2 ii qprint 1.0.dfsg.2-2 Versions of packages signing-party recommends: ii exim4-daemon-light [mail-transport-agent] 4.80-7+deb7u1 ii libgd-gd2-noxpm-perl 1:2.46-2+b1 ii libpaper-utils 1.1.24+nmu2 ii libtext-iconv-perl 1.7-5 ii whiptail 0.52.14-11.1 Versions of packages signing-party suggests: ii imagemagick8:6.7.7.10-5+deb7u3 pn mutt none pn texlive-latex-recommended none pn wipe none -- 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#418757: Debian Etch: Patch: /proc/scsi/aacraid missing
In message [EMAIL PROTECTED], dann frazier writes: On Wed, Jun 11, 2008 at 04:28:49PM +1200, Ewen McNeill wrote: Amongst other things this prevents using the Dell afacli management tool to monitor/manage the RAID arrays, since it checks for /proc/scsi/aacraid and aborts if [/proc/scsi/aacraid] is not found. [Trivial patch, from Dell engineers] Thanks Ewen. The first step in getting it into Debian would be to make sure it gets upstream. Thanks for the prompt response. I've checked the Linux 2.6.24 kernel source (eg, as in Testing now) and it's not present there. I also emailed the two Dell engineers listed on the original patch and they tell me that the subsystem maintainer rejected their patch due to the move away from using procfs for such information (to using sysfs instead). Apparently Dell got their core management tool updated to use the new interface (by the third party supplier), but it looks like the command line management tool I want to use never got updated. I understand your reluctance to carry a special patch in Debian, but I do note that this appears to be a feature regression from Sarge - Etch as Marcin Owsiany noted 14 months ago (since the /proc interface was present in Sarge and gone in Etch, and the tool seems to have worked with Sarge but doesn't work with Etch, due to changes in the way the compiler handled uninitialised data and the things that needed to be set to make the proc file appear). Perhaps it's now too late to do anything about this. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418757: /proc/scsi/aacraid workarounds
FTR, a couple of (partial) work arounds for this issue: 1. Use an older version of afacli: http://ftp.us.dell.com/scsi-raid/afa-apps-snmp.2806076-A02.tar.gz as suggested by: http://wiki.club.cc.cmu.edu/org/ccwiki/AACRAID (and various mailing list postings I eventually found.) The older version doesn't abort when /proc/scsi/aacraid is missing, but is quite a bit older so is probably lacking some features. 2. Use the Adaptec Storage Manager tools instead, following these instructions on the Adaptec blog: http://linux.adaptec.com/?p=17 http://linux.adaptec.com/?p=15 The instructions given there work well enough with Debian Etch to get /usr/StorMan/arcconf running at leasst for getconfig which allows retrieving status information. (The Dell Perc 3/Di is an OEM'd Adaptec aacraid card.) I'm not sure if either of these solutions gives the full control of more recent afacli versions (eg, some options I tried with arcconf errored out on the Dell Perc 3/Di), but they do work for basic monitoring which was the main thing I wanted. From discussion with the Dell engineers listed on the patch it appears very unlikely that a newer version of the afacli tool will ever be built that doesn't need /proc/scsi/aacraid, so patching the kernel appears to be the only way to get the most recent version to work. They also told me that the Dell OMSA management set was updated to work without /proc/scsi/aacraid, so that's possibly another option for monitoring. So given this, and the time that has passed, perhaps we just accept this as a Sarge - Etch regression and hope others who run into the problem find this bug and possible work arounds. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418757: Debian Etch: Patch: /proc/scsi/aacraid missing
As noted by Marcin Owsiany [EMAIL PROTECTED] last year, with the
default Debian Etch kernel, /proc/scsi/aacraid is missing on the Debian
Etch kernel, even when the AACRAID driver is loaded and operating.
Amongst other things this prevents using the Dell afacli management tool
to monitor/manage the RAID arrays, since it checks for
/proc/scsi/aacraid and aborts if it is not found.
In the link that Marcin Owsiany provided:
http://lists.us.dell.com/pipermail/linux-poweredge/2007-January/029281.html
is a trivial patch for the aacraid driver which sets the necessary
elements in the structure which allow the /proc/scsi/aacraid file to
appear. Apparently originally from some Dell Engineers.
Would it be possible to have this applied to the Debian Etch kernel at
the next point release? (Etch and a half?) It's against 2.6.16
but seems easy enough to sort out for Etch's 2.6.18 kernel.
I've included it below to make it easier for you to get at.
Ewen
-=- cut here -=-
From: Patrick Boyd Patrick_Boyd at dell.com,
Bill Edwards Bill_Edwards at dell.com
The problem that we are having is that on the current version of RedHat
Enterprise Linux 5 (2.6.16 kernel) the Adaptec raid management libraries
(AFALIB) no longer function. We were able to root cause this to the fact
that the /proc/scsi/aacraid directory was missing.
This directory is created if two properties are set in the
scsi_host_template structure: proc_name and proc_info. However, previous
driver version were not setting proc_info and as far as we can tell
this was just being set to uninitialized memory which was allowing the
directory creation to succeed. Apparently compiler or runtime behavior
has changed so that uninitialized entries in this static struct are set
to 0. Our solution is to simply create a function and put the function
pointer into the struct to restore the original behavior under the
new compiler.
Signed-off-by: Patrick Boyd Patrick_Boyd at dell.com, Bill Edwards
Bill_Edwards at dell.com
---
--- linux-2.6.16/drivers/scsi/aacraid/linit.c.orig 2006-08-30
11:53:58.0 -0500
+++ linux-2.6.16/drivers/scsi/aacraid/linit.c 2006-08-30 11:55:27.0
-0500
@@ -782,10 +782,18 @@ static struct file_operations aac_cfg_fo
.open = aac_cfg_open,
};
+static int aacraid_proc_info(struct Scsi_Host *host, char *buffer, char
**start, off_t offset,
+int length, int inout) {
+ return 0;
+}
+
+
static struct scsi_host_template aac_driver_template = {
.module = THIS_MODULE,
.name = AAC,
.proc_name = AAC_DRIVERNAME,
+ .proc_info = aacraid_proc_info,
.info = aac_info,
.ioctl = aac_ioctl,
#ifdef CONFIG_COMPAT
-=- cut here -=-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433870: (Debian Sarge) not fixed (was Re: Bug#433870 closed by Aurelien Jarno [EMAIL PROTECTED] (Bug#433869: fixed in tzdata 2007f-1etch1))
In message [EMAIL PROTECTED], De bian Bug Tracking System writes: This is an automatic notification regarding your Bug report #433870: Sarge: TimeZone: New Zealand change to daylight time transition, which was filed against the tzdata package. It has been closed by Aurelien Jarno [EMAIL PROTECTED]. [tzdata update for Etch in debian-volatile] Thank you for the update of tzdata for Debian Etch in debian-volatile. I have installed this on several machines and it does fix the problem. However there is no fix for Debian Sarge available. The tzdata update is not appropriate (since the time zone data in Sarge is in the base libc6 package), and there is no libc6 update. But I see that this bug on Debian Sarge (#433870) has been closed by the Etch update due to being merged with the Etch bug report (#433869). Will there be an update issued for Debian Sarge to libc6 with the 2007f timezone data? Or does the fact that the Debian Sarge bug was closed without any separate explanation mean that this bug will not be fixed in Debian Sarge? Thanks, Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433869: Etch: New Zealand change to daylight time transition
Package: tzdata Version: 2007b-1 Severity: normal The New Zealand Government has altered the dates when Daylight Time will start and end starting this year. Daylight Time will begin one week earlier (on the last Sunday in September, instead of the first Sunday in October), and finish two weeks later: http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended?OpenDocument The tzdata package in testing and unstable (2007f-9) includes this change, and the timezone is correctly reported in those versions (as seen in, eg, tzdump -v Pacific/Auckland). However the tzdata package in stable (etch) -- 2007b-1 -- is now out of date for New Zealand (Pacific/Auckland) and still shows the Daylight Time transition following the old rules. I see an update was issued last year to pick up USA and Australian daylight time changes (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410146). Is an update for stable (etch) planned to pick up the New Zealand time zone change, either in the main archive or in debian-volatile and/or backports.org? If not, could you recommend the preferred way to update this package on systems running stable (etch)? Ewen -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-xen-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433870: Sarge: TimeZone: New Zealand change to daylight time transition
Package: libc6 Version: 2.3.2.ds1-22sarge6 Severity: normal The New Zealand Government has altered the dates when Daylight Time will start and end starting this year. Daylight Time will begin one week earlier (on the last Sunday in September, instead of the first Sunday in October), and finish two weeks later: http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended?OpenDocument The tzdata package in testing and unstable (2007f-9) includes this change, and the timezone is correctly reported in those versions (as seen in, eg, tzdump -v Pacific/Auckland). I have filed another bug on tzdata in stable (etch) about this problem. In oldstable (sarge) the timezone information is included in the libc6 package, which is based on tzdata 2006p-1, and is now out of date for New Zealand (Pacific/Auckland). I see that there was a libc6 update for sarge last year (2.3.2.ds1-22sarge5) which included time zone data 2006p-1, and brought in the correct time zone information for the USA and Western Australia. Is another update planned for sarge to bring in the updated tzdata (2007f) that includes the New Zealand time zone change? If not, can you recommend the best way to update this time zone information on sarge based systems? (And yes, I'm upgrading them to Etch as fast as possible, but there's a bunch to do.) Ewen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.17.8-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433870: Sarge: TimeZone: New Zealand change to daylight time transition
The equivilent bug for Etch is #433869: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433869 Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433869: Etch: New Zealand change to daylight time transition
I have also filed a bug on libc6 in Sarge for this issue (since the timezone information is rolled into the libc6 package in Sarge), #433870: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433870 You may possibly wish to coordinate with the libc6 maintainer. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349587: sudo: DSA946: omitting $HOME
In reply to bug 349729 Martin Schulze [EMAIL PROTECTED] wrote: Please read the advisory again: http://www.debian.org/security/2006/dsa-946 It says: Additional variables are only passed through when set as env_check in /etc/sudoers, which might be required for some scripts to continue to work. [the advisory indicates only LC_*, LANG, LANGUAGE and TERM are passed through] [ The discussion is now merged into: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349587 ] Out of interest what was the rationale for omitting $HOME from this list? Omitting it (when -H and/or set_home and/or always_set_home isn't in effect to overwrite $HOME) results in an environment without $HOME set at all. Since $HOME is one of the variables set by login(1), and rarely stripped out, a lot of (interactive) programs assume that it'll be set. Most recently I've encountered issues with vim complaining that it can't read/write $HOME/.viminfo (due to passing the literal string '$HOME/.viminfo' to open(2), since there was no variable to do expansion on). Obviously as a work around we can all do: Defaults env_reset, env_check = HOME on every single system we use that runs Debian. But if there's a security issue involved in passing through $HOME then I think it should at least be documented so that we can be aware of it when deciding to either put this work around in place, or live with the warnings when doing sudo vim foo, etc. If there's no security issue then $HOME seems like an obvious candidate to add into the default whitelist. (The only other variable set by default by login(1) which isn't now set in the sudo sh environment is $MAIL, and that doesn't seem particularly important in the context of sudo.) Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349196: sudo: proposed fix seems okay (was Re: sudo: DSA946: omitting $HOME)
Ewen McNeill writes: In reply to bug 349729 Martin Schulze [EMAIL PROTECTED] wrote: http://www.debian.org/security/2006/dsa-946 [...] [the advisory indicates only LC_*, LANG, LANGUAGE and TERM are passed through] [ The discussion is now merged into: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349587 ] Out of interest what was the rationale for omitting $HOME from this list? I see that the proposed update noted in bug 349196 (which unfortunately I missed before sending in my earlier comment) restores $HOME to the list of environment variables allowed by default. The Sarge package at: http://klecker.debian.org/~joey/security/sudo/ (referenced from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349196) seems to work for me, at least to resolve the issue I was having with vim and $HOME/.viminfo. Although curiously the extra variables allowed (HOME, LOGNAME, PATH, SHELL, TERM, DISPLAY, XAUTHORITY, XAUTHORIZATION, LANG, LANGUAGE, LC_*, and USER), don't appear in the sudo -V list of variables to check; only the original list of variables (in -1.3) appears there. Presumably this means they're being retained unconditionally which may or may not be desirable. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332251: Squid: Woody: -2woody11 fixes FTP issue
DSA 809-3 released squid 2.4.6-2woody11 which included the fix for the FTP instability regression. I have had a hand patched version in production for a week, and 2woody11 in production for two days, and both seem to have been stable. (With -2woody10 it would crash at least once an hour.) So I think that both these bugs (#331714, #332251) are now completed and can be closed. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331714: DSA-809-2: patch: squid: -woody10: crash on FTP data channel close
[EMAIL PROTECTED]: I'm CCing you because the bug was introduced in the
last security update (DSA-809-2) for Squid on Debian Woody. It would
be helpful if a security update could be issued without this bug; there
is a patch at the end of this message.
Credit for the discovery of the cause of this bug and providing a fix
should go to Kosa Attila [EMAIL PROTECTED] (see bug #332251)
I'm just (a) explaining how to reproduce the problem, (b) providing a
more easily applied patch and (c) bringing it to more people's attention,
since that fix seems to have been ignored.
Squid -woody10 introduces a flaw which causes the FTP connections
through Squid to cause squid to abort with an assertion failure when the
data channel completes, eg:
squid[20250]: assertion failed: comm.c:636: F-flags.open
squid[20235]: Squid Parent: child process 20250 exited due to signal 6
This is reported as bug #331714 (mine), and #332251.
The flaw is easily demonstrated by starting a FTP connection
through the Squid proxy (eg, ftp_proxy=http://localhost:3128/ lynx
ftp://ftp.debian.org/) and trying to download a file via FTP. Directory
listings are okay (there is separate code to handle those properly),
but any attempt to download a file will result in squid failing on
the assertion.
The cause is ftpDataRead() (src/ftp.c:872) calling commSetSelect()
(at src/ftp.c:942) irrespective of whether or not the the data connection
was completed, and hence ftpReadComplete() was called to close the data
connection. commSetSelect() (src/comm.c:632) checks that the connection
it is being told to watch is actually open with an assertion
(at src/comm.c:636), which fails when called on a connection that has
been closed.
-woody10 (with Debian patches) contains the source:
(-woody10 src/ftp.c: lines 938 to 946)
-=- cut here -=-
if (ftpState-size 0 mem-inmem_hi = ftpState-size +
mem-reply-hdr_sz)
ftpReadComplete(ftpState);
else
storeBufferFlush(entry);
commSetSelect(fd,
COMM_SELECT_READ,
ftpDataRead,
data,
Config.Timeout.read);
-=- cut here -=-
Despite the optimistic indenting, in C what this means is that if the
file transfer completed, close the socket and then try to set
up a call back on that closed socket.
The flaw is obvious when comparing it with the upstream 2.4.6 source:
(upstream 2.4.6 src/ftp.c: lines 924 to 931)
-=- cut here -=-
if (ftpState-size 0 mem-inmem_hi = ftpState-size +
mem-reply-hdr_sz)
ftpReadComplete(ftpState);
else
commSetSelect(fd,
COMM_SELECT_READ,
ftpDataRead,
data,
Config.Timeout.read);
-=- cut here -=-
The line storeBufferFlush(entry); has been introduced in -woody10, which
means that is reserved for the else-path rather than the commSetSelect()
being reserved for the else-path (ie, connection not finished).
The correct fix, as discovered by Kosa Attila [EMAIL PROTECTED],
is to enclose the else-path in braces, so that both the storeBufferFlush()
and the commSetSelect() are reserved for the else-path. I have tested
this on my Woody test server, and without it ftp data connections always
cause a crash, and with the fix ftp connections are fine; I plan to put
it into production tonight.
A more easily applied patch is enclosed below.
2.5.9-10sarge2 in Debian Sarge does not suffer from ths issue because
2.5.9 has a rewritten ftpDataRead() function that has been restructured
to avoid this sort of issue.
Ewen
-=- cut here -=-
diff -ur squid-2.4.6/debian/changelog squid-2.4.6-ftpfix/debian/changelog
--- squid-2.4.6/debian/changelogTue Nov 1 13:09:43 2005
+++ squid-2.4.6-ftpfix/debian/changelog Tue Nov 1 13:03:58 2005
@@ -1,3 +1,11 @@
+squid (2.4.6-2woody10.ftpfix) oldstable-security; urgency=high
+
+ * Added fix for broken ftpDataRead() handling (in ftp.c), which was broken
+by 2.4.6-2woody10 patches. Suggested by Kosa Attila
+[EMAIL PROTECTED] in #332251
+
+ -- Ewen McNeill [EMAIL PROTECTED] Tue, 1 Nov 2005 13:02:41 +1300
+
squid (2.4.6-2woody10) oldstable-security; urgency=high
* Upload to oldstable-security because of security issues
diff -ur squid-2.4.6/src/ftp.c squid-2.4.6-ftpfix/src/ftp.c
--- squid-2.4.6/src/ftp.c Tue Nov 1 13:09:43 2005
+++ squid-2.4.6-ftpfix/src/ftp.cTue Nov 1 13:00:17 2005
@@ -937,13 +937,14 @@
}
if (ftpState-size 0 mem-inmem_hi = ftpState-size +
mem-reply-hdr_sz)
ftpReadComplete(ftpState);
- else
- storeBufferFlush(entry);
+ else {
+ storeBufferFlush(entry);
commSetSelect(fd,
COMM_SELECT_READ,
ftpDataRead,
data,
Config.Timeout.read);
+ }
}
}
-=- cut here -=-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Bug#331714: 2.4.6-2woody10: regression: assertion failed: comm.c:636: F-flags.open
Package: squid Version: 2.4.6-2woody10 Severity: normal After installing the 2.4.6-2woody10 security update for Squid on Debian Woody (DSA 809-2, fixing a regression in DSA 751), squid now regularly restarts itself, logging: assertion failed: comm.c:636: F-flags.open This is happening approximately once an hour, and appears to be correlated with FTP requests through the proxy made by AV software (which seem to be happening every hour, a few seconds after the hour). The same behaviour didn't occur with 2.4.6-2woody8; I'm not sure if it occured with 2.4.26-2woody9 as we weren't able to run that for very long due to it failing on a (different) assertion every time it encountered a URL with an IP address in it. I haven't, yet, been able to find a reproducible example that definitely triggers the behaviour, and eg, going to the FTP urls in question with a web browser configured to ues the proxy for FTP doesn't seem to trigger the behaviour: ftp://ftp.mcafee.com/pub/datfiles/english/ ftp://ftp.mcafee.com/pub/datfiles/english//extra It's possible that it's not FTP requests causing the issue, and that it's just coincidence that they're happening at the same time (in which case squid may be restarting without logging the query causing the issue). Are you aware of any changes in 2.4.6-2woody10 that might cause this type of error? Ewen -- System Information: Debian Release: 3.0 Architecture: i386 Kernel: Linux mata 2.4.26-raidhost #1 Tue Apr 20 18:42:54 NZST 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages squid depends on: ii adduser 3.47 Add and remove users and groups ii debconf 1.0.32 Debian configuration management sy ii libc6 2.2.5-11.8 GNU C Library: Shared libraries an ii libldap2 2.0.23-6.3 OpenLDAP libraries. ii logrotate 3.5.9-8Log rotation utility ii netbase 4.07 Basic TCP/IP networking system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331718: Woody: reportbug crashes querying BTS: IndexError: list index out of range
Package: reportbug Version: 1.50 Severity: important Recently (last known to work a few weeks ago), reportbug in Debian Woody crashes with a Python error and traceback immediately after querying the Debian BTS. This means that bugs cannot be reported using the Woody reportbug, except by forcing reportbug not to query the BTS (eg, by giving it a proxy setting that doesn't work). I'm guessing that the BTS interface has changed in some manner which renders the Woody reportbug out of date, but am reporting the issue since Woody is still nominally supported. Full session: -=- cut here -=- [EMAIL PROTECTED]:~$ reportbug reportbug Using 'Ewen McNeill [EMAIL PROTECTED]' as your from address. Getting status for reportbug... Querying Debian bug tracking system for reports on reportbug (Use ? for help at prompts.) Traceback (most recent call last): File /usr/bin/reportbug, line 1180, in ? main() File /usr/bin/reportbug, line 646, in main http_proxy, source=issource) File /usr/lib/site-python/reportbug_ui_text.py, line 327, in handle_bts_quer y source=source, http_proxy=http_proxy, archived=archived) File /usr/lib/site-python/debianbts.py, line 598, in get_reports result = get_cgi_reports(package, system, http_proxy, archived, source) File /usr/lib/site-python/debianbts.py, line 529, in get_cgi_reports parser.feed(content) File /usr/lib/python2.1/sgmllib.py, line 91, in feed self.goahead(0) File /usr/lib/python2.1/sgmllib.py, line 121, in goahead k = self.parse_starttag(i) File /usr/lib/python2.1/sgmllib.py, line 311, in parse_starttag self.finish_starttag(tag, attrs) File /usr/lib/python2.1/sgmllib.py, line 345, in finish_starttag self.handle_starttag(tag, method, attrs) File /usr/lib/python2.1/sgmllib.py, line 385, in handle_starttag method(attrs) File /usr/lib/site-python/debianbts.py, line 484, in do_li self.lidatalist = self.hierarchy[-1][1] IndexError: list index out of range [EMAIL PROTECTED]:~$ -=- cut here -=- If this can't be fixed, or is not going to be fixed, it may be worth leaving the bug tagged wontfix and woody with an explanation of what is going on and a workaround to avoid others struggling with the same problem. (I couldn't obviously see a similar bug report.) Ewen Environment settings: EDITOR=/usr/bin/vi -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux ra 2.4.26-idehost #1 Tue Apr 20 17:56:52 NZST 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages reportbug depends on: ii python2.1.3-3.4 An interactive object-oriented scr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330999: samba.postinst destroys smbpasswd if LDAP/NIS is down
Package: samba Version: 3.0.14a-3 Severity: grave Justification: causes non-serious data loss When upgrading from Debian Woody (with Samba 2.x) to Debian Sarge (with Samba 3.x), /var/lib/dpkg/info/samba.postinst attempts to convert the smbpasswd database to the new TDB format, with the following commands: umask 066 pdbedit -i smbpasswd -e tdbsam rm /etc/samba/smbpasswd umask 022 Unfortunately if the user accounts are provided by, eg, LDAP (or NIS, or some other external password database), and that password database is down (due, eg, to being in the process of upgrading from Debian Woody to Debian Sarge...) then there will be a large number of errors reported of the form: build_sam_account: smbpasswd database is corrupt! username ewen with uid 1024 is not in unix passwd database! and the resulting TDB password database will contain few, if any, of the original users because these are omitted since they're missing (temporarily due to, eg, slapd being down). samba.postinst then removes the original /etc/samba/smbpasswd file with out making any backup copy or asking the user for permission to do so. This prevents the administrator from rerunning the migration once the LDAP/NIS/etc database has been restarted during the upgrade. IMHO it is inexcusible to deliberately destroy the old version of the password database simply on the assumption that the conversion command must have worked. The old password database should be renamed to something which makes it obvious that it is not used any longer (eg, /etc/samba/smbpasswd.pre-migration-to-tdb), but left in place to allow the administrator to recover from any issues that might occur. It would also be an extrememly good idea to delay running the smbpasswd conversion script until the end of the sequence of upgrades so that there is the most chance that LDAP/NIS/etc will be functional again. FWIW, the sole reason that I didn't mark this a critical bug was that, fortunately, smbpasswd is backed up daily into /var/backups. So I don't have to resort to last nights tape backup to recover from this destructive postinst script. Ewen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.26-wavelength-amd-via Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages samba depends on: ii debconf [debconf-2.0] 1.4.30.13 Debian configuration management sy ii libacl12.2.23-1 Access control list shared library ii libattr1 2.4.16-1 Extended attribute shared library ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libcomerr2 1.37-2sarge1 common error description library ii libcupsys2-gnutls101.1.23-10 Common UNIX Printing System(tm) - ii libkrb53 1.3.6-2sarge2 MIT Kerberos runtime libraries ii libldap2 2.1.30-8 OpenLDAP libraries ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libpopt0 1.7-5 lib for parsing cmdline parameters ii logrotate 3.7-5 Log rotation utility ii netbase4.21 Basic TCP/IP networking system ii samba-common 3.0.14a-3 Samba common files used by both th -- debconf information: samba/nmbd_from_inetd: * samba/run_mode: daemons * samba/log_files_moved: * samba/tdbsam: true * samba/generate_smbpasswd: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330268: Sun: Blade100: serial console install fails after reboot
Package: installation-reports Debian-installer-version: Version shipped with Debian 3.1r0a uname -a: Linux version 2.6.8-2-sparc64 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Wed Mar 23 04:23:37 EST 2005 Date: 2005/09/27 14:00:00 NZST Method: Network boot into install system, because Debian Sarge 3.1r0a netinst CD often does not boot properly on Sun Blade 100 system (see bugs #283666 and #257627), and even when it does boot from CD it is unable to detect either the CD or the hard drive (see below). Machine: Sun Blade 100 Processor: UltraSparc II Memory: 640MB Root Device: IDE: /dev/hda (15GB Seagate disk) Root Size/partition table: xIDE1 master (hda) - 15.3 GB ST315310A a x x #1 100.1 MB B f ext3 /boota x x #2 512.0 MB f ext3 /a x x #4 4.8 GB f ext3 /usr a x x #5 2.9 GB f ext3 /var a x x #6 1.0 GB f swap swap a x x #7 6.0 GB f ext3 /homea x Output of lspci and lspci -n: (not available, or relevant to report) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [E] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [E] Comments/Problems: I installed via serial console (it's how I typically install all non-PC systems). This worked for the initial install phase (prior to the first reboot, but failed after that). (Although there is a LOT of redrawing going on in the menus, partioner, etc, which is painfully obvious at 9600bps!) On first reboot after install, the system booted up, started various system daemons, then reported: error: Unable to switch charset mapping to ISO-8859-1 with terminal 'serial' warning: Disabling unsupported locale 'en_NZ'. /usr/sbin/base-config: line 31: /usr/bin/gettext: cannot execute binary file several times, before init gave up, and reported: INIT: Id 1 respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel (Yes, I chose New Zealand as my region during the install, as that's where I am.) While it's obviously nice to try to set up the terminal for the right character set, etc, I don't think not being able to do so (eg, on a serial line) should be a fatal error halting the installation. It would be nice to, eg, fall back to C or POSIX or something which at least stands a chance of working. Or at very least throw an error message, and spawn a shell to give the user an opportunity to fix it. (I'll fix the machine up, after I send this report, by booting with init=/bin/sh or similar, and working around this issue in some manner.) Finally with regard to the CD detection, when booting from the CD image (after carefully breaking into the boot rom at precisely the right moment, as described in bug #275627), it fails to detect either the (IDE) hard drive or the (IDE) CDROM. Jumping out to a shell indicates that it's loaded the right module for the IDE controller, and ide-cd and ide-disk, but not detected anything. It looked much as if IDE probe module wasn't being loaded at all (and it didn't appear to be present in the pre install environment) and thus it never had a chance to detect the hard drive or cdrom. Which possibly means that the Debian Sarge 3.1r0 netinst CD (at least) is non usable on all IDE-based Sparc system. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330268: Acknowledgement (Sun: Blade100: serial console install fails after reboot)
Further to my report: - I ended up forcing a reboot by powering the machine off (as sending a break on the serial console didn't seem to work, and there was no functional tty or remote access) - After rebooting the system complained that it couldn't fsck /dev/hda2 (the root disk) and prompted for a root password; when I tried manually, e2fsck failed with an Illegal instruction around the second pass on the disk, irrespective of which disk partition I used. - I then booted into the installer again, jumped out to a shell, mounted all the partitions and chroot'd into them, and did a bit of setup by hand, including installing ssh and starting the ssh server - From the ssh session I tried running /usr/sbin/base-config new again, which reported that /bin/cp wouldn't run (!!). I verified that /bin/cp was unable to copy a file, and ended up using apt to reinstall /bin/cp (and friends): apt-get --reinstall install coreutils I also reinstalled e2fsprogs just to be sure. - I was then able to run /usr/sbin/base-config new through the ssh session (in a chroot onto the target disk booted from the network boot image) This makes me suspect that something other than the locale selection was causing the initial problems (after first boot), although I'm puzzled as to what it was, or what caused it. (Especially since reinstalling packages from the same Debian mirror -- ftp.nz.debian.org -- seemed to fix it.) After rebooting again (from the new install) the system came up cleanly, and things like e2fsck ran okay. At this stage I think the system is now functional. But it's not the easiest Debian install I've done (and I've done lots of PC installs and a bunch of non-PC installs too). Ewen PS: The CPU in the Sun Blade 100 is in fact an UltraSparc IIe (Hummingbird) according to /proc/cpuinfo. And FWIW, the lspci output: blade100:~# lspci :00:00.0 Host bridge: Sun Microsystems Computer Corp. Ultra IIe :00:03.0 Non-VGA unclassified device: ALi Corporation M7101 Power Management Controller [PMU] :00:05.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) :00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] :00:08.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 01) :00:0c.0 Bridge: Sun Microsystems Computer Corp. RIO EBUS (rev 01) :00:0c.1 Ethernet controller: Sun Microsystems Computer Corp. RIO GEM (rev 01) :00:0c.2 FireWire (IEEE 1394): Sun Microsystems Computer Corp. RIO 1394 (rev 01) :00:0c.3 USB Controller: Sun Microsystems Computer Corp. RIO USB (rev 01) :00:0d.0 IDE interface: ALi Corporation M5229 IDE (rev c3) :00:13.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) blade100:~# -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310801: reopening upgrade bugs
In message [EMAIL PROTECTED], Bill Allombert writes: reopen 310801 [...] Hello, I reopen these report that have been summarily closed without being processed. When the bug is an upgrade failure, we should at least try to reproduce the failure before closing the bug. [...] While I agree with you in general, I believe it's reasonable to close #310801 (the bug I reported on upgrading from Woody to Sarge on a Mips/Cobalt system), as the major part of the bug was resolved in the manner you suggest (updated release notes, description provided). The only thing that hadn't been addressed was the note that my particular kernel (custom compiled) didn't have tmpfs/shmfs in it, and that caused a bunch of warnings in /etc/init.d/mountvirtfs when it tried to mount /dev/shm. My suggestion was that the requirement for this file system be mentioned in the release notes (or somewhere else appropriate so people building their own kernels were aware of it). But since the upgrade worked anyway I don't think it's a big deal. From my point of view, now that the Woody-Sarge upgrade QA cycle is over, you can close this (#310801) bug again. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324204: mozilla-firefox_1.0.4-2sarge3 fixes issue
Hi, It appears that mozilla-firefox_1.0.4-2sarge3 resolves the issue with mozilla-firefox_1.0.4-2sarge2; with the new update installed from DSA 779-2 both middle-click and ctrl-click work again to open new tabs. So I think you can close this bug. Bug #324686 and bug #325612 appear to report the same issue, and may well be resolved as well. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324686 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325612 Thanks, Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325663: README.Debian: Document --disable-debug setting
Package: libneon24 Version: 0.24.7.dfsg-2 Severity: normal libneon24 is compiled with the --disable-debug parameter. This apparently means that setting ne_debug is completely ignored. Which in turn means that the subversion recommendation to set neon-debug-mask (in .subversion/servers) to debug client/server interaction issues is ineffective for non-obvious reasons. (It was really only when I downloaded the Debian source to libneon24 that I figured out what was wrong; prior to that I spent a while trying to figure out why subversion wasn't picking up the setting.) It would be very helpful if there were a README.Debian file installed with the libneon24 package saying something to the effect: NOTE: This package is compiled with --disable-debug, which means you will not be able to enable debugging/trace output in the neon library. If you need this trace output please download the source to libneon24 and recompile the package. Ewen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.12.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libneon24 depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libssl0.9.70.9.7e-3 SSL shared libraries ii libxml22.6.16-7 GNOME XML library ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325663: README.Debian: Document --disable-debug setting
In message [EMAIL PROTECTED], Laszlo Boszormenyi writes: On Tue, 2005-08-30 at 18:20 +1200, Ewen McNeill wrote: Package: libneon24 Version: 0.24.7.dfsg-2 Severity: normal libneon24 is compiled with the --disable-debug parameter. This apparently means that setting ne_debug is completely ignored. What happens if you use experimental and libneon25-dbg? Is that work for you with correct debugging? No, I don't think so. According to the debian/rules file that builds libneon25-dbg, it is still compiled with: --disable-debug \ which means that the debug/trace output is omitted from the library. The libneon25-dbg package appears only to affect whether the symbol table is stripped off the .o/.a files or not (an option to dh_strip). Having not-stripped versions is useful for other reasons, but does not solve my problem. As I said, I think the simplest option is to add a brief README.Debian to explain the compile options used, and how to work around the issue. There is suggested text in my original report. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324204: mozilla-firefox: 1.0.4-2sarge2 breaks middle-button and ctrl-click for new tab
Package: mozilla-firefox Version: 1.0.4-2sarge2 Severity: normal In 1.0.4-2sarge1 (and every other Firefox build I've used), it's possible to open a new tab (or window) with the middle mouse button, or with ctrl-click, on a link. In 1.0.4-2sarge2 neither of these features work any longer; clicking with the middle button or ctrl-click is simply ignored. Starting with a new set of firefox configuration (stop browser; mv .mozilla/firefix .mozilla/firefox.new; start browser) makes no difference; the functionality is still broken in 1.0.4-2sarge2 with the fresh config. Changing: user_pref(middlemouse.contentLoadURL, false); makes no difference either (controls whether hitting the middle button slightly off a link causes going to some random URL you selected hours ago). Right-click Open in a new tab does work (opens new tab with link content), as does New Tab (opens new blank tab), so the tabbing fuctionality works. It's only the mouse bindings which are broken. This appears to be a fairly significant regression introduced with 1.0.4-2sarge2; for me at least it completely breaks my normal way of using a web browser in what should have been a minor security update. I see #318667 reported a similar issue with 1.0.4-2sarge1, which was resolved with works for me, although in their case it seems the middle mouse button worked and the others didn't which seems odd. In my case it appears to be the mouse keybindings which are broken. I don't obviously see any config features to reenable this feature (but even if there is, I don't think the behaviour should be changed by a minor security update). For now I am reverting to 1.0.4-2sarge1, as 1.0.4-2sarge2 is too painful to use like this. Ewen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.12.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mozilla-firefox depends on: ii debianutils2.8.4 Miscellaneous utilities specific t ii fontconfig 2.3.1-2 generic font configuration library ii libatk1.0-01.8.0-4 The ATK accessibility toolkit ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libfontconfig1 2.3.1-2 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc11:3.4.3-13GCC support library ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgtk2.0-02.6.4-3 The GTK+ graphical user interface ii libidl00.8.5-1 library for parsing CORBA IDL file ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libkrb53 1.3.6-2sarge2 MIT Kerberos runtime libraries ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio ii libpng12-0 1.2.8rel-1PNG library - runtime ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-14 X Window System miscellaneous exte ii libxft22.1.7-1 FreeType-based font drawing librar ii libxp6 4.3.0.dfsg.1-14 X Window System printing extension ii libxt6 4.3.0.dfsg.1-14 X Toolkit Intrinsics ii psmisc 21.5-1Utilities that use the proc filesy ii xlibs 4.3.0.dfsg.1-14 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310801: Failed: mips(el) (cobalt): no aptitude package in woody for mips(el)
reopen 310801 retitle 310801 Release Notes: mips(el): further notes on upgrade approach In message [EMAIL PROTECTED], [EMAIL PROTECTED] r writes: Frans Pop has changed the release notes to follow your suggestions: [] # apt-get install aptitude aptitude will show you a list of the changes that will be made and ask you to c onfirm them. You should take a careful look at the proposed changes, especially packages that will be removed by the upgrade, before you confirm. I see from looking at: http://www.debian.org/releases/testing/mips/release-notes/ch-upgrading.en.html that this has been reworded further to remove the obvious mistake (ie, it's not aptitude that shows the list of changes; it's apt-get). You may also want to suggest: apt-get -s install aptitude as a way of seeing exactly what will be done in a slightly easier to follow list (the default apt-get display has a lot of categories of things, some of which are info, and some of which are important, and may be mor confusing to people). Also this approach (change to sarge in apt/sources.list; apt-get update; apt-get install aptitude) will bring in a new libc6. These new libc6s will require particular kernel versions depending on the architecture (taken from libc6.preinst): i386: 2.4.24 or 2.6.0 or higher sparc:2.4.21 or 2.2.0 or higher (depending on CPU type) parisc: 2.4.17 or higher parisc64: 2.4.19 or higher; 2.5.53 or higher mips: 2.4.22 or higher amd64:2.6.0 or higher It'd be useful to include the actual versions that are required in the releaes notes, rather than just a generic you should install a new kernel first note. It's really important that the kernel be done first if it's not new enough, but if it is new enough there seems little point in doing the kernel update first (and a risk of module tools, etc, being out of date). Perhaps this note could be included as a preface to the 4.4.3 Installing aptitude section -- ie, make sure your kernel is at least this version, then I'm trying this approach now (since I already have a 2.4.26 custom kernel); I'll send an update on how it went when I'm done. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310801: Successful: mipsel: Cobalt: Woody-Sarge upgrade
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: Thanks again for your report, report from upgrade on less mainstream architectures are very valuable to us. FWIW, I've successfully upgraded my Cobalt RAQ2 (mipsel) from Woody to Sarge by updating to the Sarge apt sources, apt-get update, apt-get install aptitude, aptitude -f --with-recommends dist-upgrade. Fortunately because I'd already built a custom kernel 2.4.22, I was spared much of the pain that might otherwise go with that type of upgrade (ie, Sarge aptitude needs new libc6, which needs new kernel). The only other issue I've noted is that Sarge has a /etc/init.d/mountvirtfs, which does: domount tmpfs shmfs /dev/shm $tmpfs_opt that doesn't work with my kernel, presumably because tmpfs/shmfs was one of many things I sacrificed to ensure that I could actually fit my kernel into the space the Cobalt firmware will boot directly. This causes a number of messages like this: -=- cut here -=- mount: wrong fs type, bad option, bad superblock on tmpfs, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so -=- cut here -=- on the console during a reboot, but otherwise seems to be okay for the limited range of software I run on my cobalt (it's a test machine). It may be worth mentioning the requirement for tmpfs/shmfs to be compiled into the kernel in the release notes. I haven't yet tried to install the Debian packaged kernel, largely because I'm dubious about it actually fiting in the space the Cobalt firmware will boot. (I'm aware there is an alternative two stage boot loader -- colo -- which seems to be packaged for Debian, but I haven't tried it, and it doesn't seem to be mentione in the release notes.) Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310801: Failed: mips(el) (cobalt): no aptitude package in woody for mips(el)
Package: upgrade-reports [NOTE: This duplicates some information in report #310005; I'm still filing as a separate bug because I think the specific issue (aptitude missing in woody for mips(el)) is sigificant enough to warrant separate attention. Feel free to close this bug if/when issue raised in this/#310005 are addressed somehow -- even if it's just duplicating the recommended approach from #310005 into the mips(el) Sarge release notes.] Archive date: Wed May 25 19:00:01 UTC 2005 Upgrade date: 2005/05/26 16:00:00 +1200 uname -a: Linux cobalt-linux 2.4.26 #2 Tue Apr 27 13:29:20 NZST 2004 mips unknown Method: Attempted to upgrade with aptitude following instructions here http://www.debian.org/releases/sarge/mipsel/release-notes/ch-upgrading.en.html Unfortunately I didn't get very far with my attempt to upgrade my Cobalt box (running Debian Linux, Woody, installed following Paul Martin's instructions from a few years ago). One of the first instructions (after make a backup) is: -=- cut here -=- First the aptitude package needs to be installed. This is done with: apt-get install aptitude Provided that you have a working APT configuration this will install the woody version of aptitude. -=- cut here -=- Unfortunately this isn't possible on a mips(el) architecture. -=- cut here -=- [EMAIL PROTECTED]:~$ sudo apt-get install aptitude Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package aptitude [EMAIL PROTECTED]:~$ -=- cut here -=- There is no aptitude package for mips prior to the 0.2.15.9-2 (from Sarge). Eg, from ftp.debian.org: -=- cut here -=- ftp cd debian/pool/main 250 Directory successfully changed. ftp cd a/aptitude 250 Directory successfully changed. ftp ls *mips* 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -rw-rw-r--1 1176 1176 1932216 Apr 09 18:47 aptitude_0.2.15.9-2_mips.deb -rw-rw-r--1 1176 1176 1922778 Apr 07 18:32 aptitude_0.2.15.9-2_mipsel.deb 226 Directory send OK. -=- cut here -=- Version in Woody on, eg, i386 is -=- cut here -=- [EMAIL PROTECTED]:~ $ apt-cache show aptitude | grep Version Version: 0.2.11.1-4 -=- cut here -=- At a guess that is due to bug #84935 (g++ fails to compile aptitude on the mips architecture), which is marked as Normal/Resolved, as of a month ago. Apparently not resolved in time to get a version into Woody, even with the most recent Debian Woody minor-release (which IIRC did include an aptitude update in order to make Woody-Sarge updates easier; but not for mips(el) it seems). I see there is one last Debian Woody mini-release planned: http://people.debian.org/~joey/3.0r6/ but it doesn't include aptitude at this stage. It seems to me that either: (a) aptitude should be built for Woody on all Sarge architectures, and included in 3.0r6; or (b) on those architectures where aptitude isn't available (ie, mips(el)) the release notes should provide alternative instructions on upgrading (eg, using apt-get cautiously, or perhaps doing enough of the upgrade to pull in aptitude from Sarge then using aptitude). I'm sure that I can figure out some way to upgrade this system to Sarge even if neither of those are done (I've backported enough packages myself for one thing; and done Debian upgrades since Bo without using aptitude), but in the interests of accurate documention it seems something worth addressing. Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309705: Successful: Alpha: A/S 255: Woody-Sarge upgrade
Package: upgrade-reports Archive date: Tue May 17 20:00:01 UTC 2005 Upgrade date: 2005/05/19 09:00:00 +1200 uname -a: Linux alphadeb 2.4.18-1-generic #1 Sat Apr 10 10:19:35 EST 2004 alpha GNU/Linux Method: aptitude following instructions here: http://www.debian.org/releases/sarge/alpha/release-notes/ch-upgrading.en.html NOTE: I'm assuming that upgrade reports for non-x86 architectures are still useful at this point, hence I'm reporting successful upgrades. If not someone please reply to this bug and advise otherwise. Contents of /etc/apt/sources.list: # APT configuration file for alphadeb # deb http://stupa.sv.naos.co.nz:/debian sarge main contrib non-free deb http://stupa.sv.naos.co.nz:/non-US sarge/non-US main contrib non-free deb http://stupa.sv.naos.co.nz:/security sarge/updates main contrib non-free deb ftp://security.debian.org/debian-security sarge/updates main contrib non-fre Most of those sources point at a local apt-proxy server on a local Debian Woody system. The primary FTP archive used is ftp.nz.debian.org - Were there any non-Debian packages installed before the upgrade? If so, what were they? Yes, pkgmonkey-client, which is a local Debian Package for reporting package versions installed on various servers we maintain. (This was also on the sparc system I upgraded yesterday; bug #309576.) - Was the system pre-update a pure woody system? If not, which packages were not from woody? This system was definitely installed with Debian Woody; I'm sure I've owned it less than 3 years. To the best of my knowledge there were no backported packages on the system, and there were definitely no pinned packages. - Did any packages fail to upgrade? Everything seemed to upgrade fine. - Were there any problems with the system after upgrading? So far everything seems to be fine. The system rebooted fine on the old kernel, and also rebooted okay after I'd installed a 2.4.27-2-generic kernel from Debian. (I haven't yet tried the 2.6 kernels.) Further Comments/Problems: The hardware is an AlphaStation 255/300, with 192MB of RAM. It has a 1GB disk. This upgrade went more smoothly than the previous one (sparc -- ss5, see bug #309576) that I did, despite having a similar sized (1GB) disk. I suspect this is largely due to having somewhat fewer packages on the system, and remembering to do an apt-get clean prior to doing the update. (It may be worth advising people to do that -- apt-get clean -- prior to starting the upgrade, especially if low on disk space.) Minimum disk space during the upgrade was around 175MB. After the upgrade, and an apt-get clean, there is about 270MB free again. -=- COLUMNS=200 dpkg -l (woody) -=- Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii aboot0.9-1 Linux bootloader for the SRM console ii adduser 3.47 Add and remove users and groups ii apt 0.5.4 Advanced front-end for dpkg ii apt-utils0.5.4 APT utility programs ii ash 0.3.8-37 NetBSD /bin/sh ii at 3.1.8-11 Delayed job execution and batch processing rc base-config 1.33.18 Debian base configuration package ii base-files 3.0.2 Debian base system miscellaneous files ii base-passwd 3.4.1 Debian Base System Password/Group Files ii bash 2.05a-11 The GNU Bourne Again SHell ii binutils 2.12.90.0.1-4 The GNU assembler, linker and binary utilities. ii bsdmainutils 5.20020211-4.99 More utilities from FreeBSD. ii bsdutils 2.11n-7 Basic utilities from 4.4BSD-Lite. ii bzip21.0.2-1 A high-quality
Bug#309560: Release Notes typo
Package: upgrade-reports Archive date: Tue May 17 20:00:01 UTC 2005 Upgrade date: 2005/05/18 12:30:00 +1200 Apologies for abusing this method to report a Sarge release documentation issue, but it seemed the most likely to get to the relevant people in a position to actually fix it before the release. In the provisional release notes, eg: http://www.debian.org/releases/sarge/sparc/release-notes/ch-whats-new.en.html there are references to Woody which look like they should be Sarge, eg -=- cut here -=- 2.1 What's new in the distribution? [...] To replace the aging, much-maligned, yet still popular dselect, many apt frontends have been in development during the woody release cycle. -=- cut here -=- It might be worth someones time to search for woody in the release notes and just double check that all the instances really should be woody. (The rest on that page seem fine.) Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309576: Successful: Sparc: SS5: Woody-Sarge upgrade
Package: upgrade-reports Archive date: Tue May 17 20:00:01 UTC 2005 Upgrade date: 2005/05/18 12:30:00 +1200 uname -a: Linux ss5 2.4.26-ss5 #1 Tue Apr 20 11:19:22 NZST 2004 sparc GNU/Linux Method: aptitude (via instructions at http://www.debian.org/releases/sarge/sparc/release-notes/ch-upgrading.en.html) Contents of /etc/apt/sources.list: # APT sources for ss5.sv.naos.co.nz # deb http://stupa.sv.naos.co.nz:/debian sarge main contrib non-free deb http://stupa.sv.naos.co.nz:/non-US sarge/non-US main contrib non-free deb http://stupa.sv.naos.co.nz:/security sarge/updates main contrib non-free That's a local apt-proxy setup running on a Debian Woody system; it primarily uses ftp.nz.debian.org as its mirror. - Were there any non-Debian packages installed before the upgrade? If so, what were they? Yes, the system had custom compiled kernel packages (which I see are in need of updating); packages were compiled with make-kpkg from kernel.org source. It also had recompiled libssl; the host is a SparcStation 5, which (at least with Debian Woody) had considerably improved crypto (eg, ssh) performance with libssl recompiled to use the muliply/divide instructions present in the newer Sparc chips. - Was the system pre-update a pure woody system? If not, which packages were not from woody? My recollection is that this system was installed with Woody; IIRC I've had it only about 3 years. - Did any packages fail to upgrade? The only package that had issues during the upgrade was gpm, which failed to restart because it couldn't talk to the mouse device. Since the system has no mouse (I manage it serial console) this is unsurprising; I removed gpm after the upgrade. - Were there any problems with the system after upgrading? So far everything seems to be okay. I've rebooted the system and it came up okay. I've yet to decide whether I need to rebuild libssl to use the additional process instructions for faster crypto. Further Comments/Problems: I did notice a few errors on the console at one point in the ugprade: libc6.postrm[10052]: Unimplemented SPARC system call 188 rm[10053]: Unimplemented SPARC system call 188 rm[10056]: Unimplemented SPARC system call 188 rm[10057]: Unimplemented SPARC system call 188 grep[10058]: Unimplemented SPARC system call 188 mv[10059]: Unimplemented SPARC system call 188 but they didn't appear again after (IIRC) the first init reload, and don't seem to have appeared again after the reboot. Possibly this is related to having a custom 2.4.26 kernel. It would be a very good idea to warn people in the upgrade documentation to check they have sufficient disk space to perform the upgrade. At the low point this system had 18MB of disk left (having started with over 300MB) free: ss5:/etc/texmf/texmf.d# df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 838344776832 18924 98% / Doing apt-get clean helped considerably in freeing up disk space (with apt-get clean, and removing some uneeded packages, the system has about 275MB free). A number of these (older) systems will have quite small disks; that SS5 has a 1GB disk, with about 850MB available for data and the rest for swap. (There are also some NFS mounts which I umounted during the upgrade. That and the fact that it's a test machine make it practical to still use.) Unfortunately I don't have a COLUMNS=200 dpkg -l from before the upgrade, or from immediately after it. I do have a dpkg --get-selections from before the upgrade, and one from shortly after the upgrade. Unfortunately I'd removed some packages before taking this later dpkg --get-selections, due to the space cramp -=- dpkg --get-selections (before upgrade) -=- adduser install apt install apt-utils install aptitudeinstall at install base-config install base-files install base-passwd install bashinstall bc install biffinstall bind9-host install binutilsinstall bison install bsdmainutilsinstall bsdutilsinstall bzip2 install console-common install console-datainstall console-tools install console-tools-libs install cpioinstall cpp
