Bug#1071396: apt-move does not include the component 'non-free-firmware' when building the dists "Release" file

2024-05-18 Thread Lee Elliott
Package: apt-move
Version: 4.2.27-6
Severity: important
Tags: patch
X-Debbugs-Cc: leeejobsacco...@mail.co.uk

Dear Maintainer,

   * What led up to the situation?

I ran apt-move packages and found that when I then ran apt-update it reported 
the
following warning:

mirrors/debian bookworm InRelease' doesn't have the component 
'non-free-firmware' (component misspelt in sources.list?)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I edited /usr/bin/apt-move to include the 'non-free-firmware' component in the
'if' statements at lines 1302 and 1376

   * What was the outcome of this action?

When I re-ran apt-move pacakages the 'non-free-firmware' component was included 
in
the "Release" file and apt update did not report the warning

   * What outcome did you expect instead?




-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.90-1-sunset-6-20240511-00 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-move depends on:
ii  bc 1.07.1-3+b1
ii  dash   0.5.12-2
ii  libapt-pkg6.0  2.6.1
ii  libc6  2.36-9+deb12u7
ii  libgcc-s1  12.2.0-14
ii  libstdc++6 12.2.0-14

Versions of packages apt-move recommends:
ii  apt  2.6.1

apt-move suggests no packages.

-- Configuration Files:
/etc/apt-move.conf changed:
APTSITES="/all/"
LOCALDIR=/nfs/LE-Server/packages/mirrors/debian
DIST=bookworm
PKGTYPE=binary
FILECACHE=/nfs/LE-Server/packages/apt-bookworm_amd64/archives
LISTSTATE=/var/lib/apt/lists
DELETE=yes
MAXDELETE=20
COPYONLY=no
PKGCOMP=gzip
CONTENTS=no
GPGKEY=


-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/apt-move (from apt-move package)



Bug#1065320: linux-image-6.1.0-18-amd64: 6.1.0-18 kernel enters ACPI Error loop during boot & requires power cycle

2024-03-02 Thread Lee Elliott
Package: src:linux
Version: 6.1.76-1
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: leeejobsacco...@mail.co.uk

Dear Maintainer,

   * What led up to the situation?

   Trying to boot the system with the 6.1.0-18 kernel

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   I tried adding 'boot_delay=1000' boot option to slow the console
   scroll rate, to enable better recording of the error messages.

   I tried rebooting the previous 6.1.0-17 kernel.

   * What was the outcome of this action?

   After adding the 'boot_delay=1000' option the boot process
   progressed no further than "Loading initial ramdisk ..."
   (left for several minutes - required power cycle).

   The system boots sucessfully on the previous 6.1.0-17 kernel

   * What outcome did you expect instead?

   I expected the system to successfully boot.

   * Additional observations

   This system also normally includes 'hpet=disable' and
   'acpi_enforce_resources=lax' boot options but removing these
   made no difference.

   Although I was not able to boot the system with the
   'boot_delay=1000' option and obtain clear photographs of the
   console output - the ones I've attached suffer from
   'overprinting' - it does seem clear that ACPI errors are
   being reported.

   There appear to be two distinct phases to this problem.
   Initially, ACPI seems to be reporting errors for "GPE", as
   shown in the first attached photograph, but after ~10 seconds
   or so, ACPI then switches to continuously reporting an error
   for PM_TIMER, as shown in the second attached photograph. At
   this point a power cycle is required.

   Purging and reinstalling the package made no difference. Atm,
   only three kernels are installed on this system but I have
   had more in the past as I normally compile my own kernels
   from the corresponding Debian source package. My own 6.1.76-1
   kernel also suffers from the same problem, whereas my own
   6.1.69-1 kernel boots and runs Ok.

   Comparing the kernel configs for 6.1.0-17 and 6.1.0-18
   showed just one functional change - an additional
   Compile-time checks and compiler option, which did not seem
   relevant to this problem.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: E203NA
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: E203NA.312
board_vendor: ASUSTeK COMPUTER INC.
board_name: E203NA
board_version: 1.0   

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback


** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Celeron N3350/Pentium N4200/Atom 
E3900 Series Host Bridge [8086:5af0] (rev 0b)
Subsystem: ASUSTeK Computer Inc. Celeron N3350/Pentium N4200/Atom E3900 
Series Host Bridge [1043:1980]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 500 
[8086:5a85] (rev 0b) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. HD Graphics 500 [1043:1980]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+ FLReset+
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- 
TransPend-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- 
NROPrPrP- LTR-
 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- 
EETLPPrefix-
 EmergencyPowerReduction Not Supported, 
EmergencyPowerReductionInit-
 FRS-
 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 
10BitTagReq- OBFF Disabled,
 AtomicOpsCtl: ReqEn-
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00018  Data: 
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 No

Bug#608455: nagios3: return_code of passive checks sent via nsca to central server are in wrong format

2010-12-30 Thread Lee Elliott
Package: nagios3
Version: 3.0.6-4~lenny2
Severity: important

When a passive check is sent by a remote/distributed server via nsca the 
return_code is in the form of a string i.e. "OK/WARNING/CRITICAL/UNKNOWN" but 
this results in the central nagios 
monitoring server always interpreting the return_code as "OK" in the nagios web 
interface, even when it is not (although the plugin output data/'Status 
Information' details are correctly 
shown in the nagios web-interface).  As a result, no notifications are issued 
when a passive check returns a warning, failure or unknown status.

The cause of this problem seems to be that the passive check return_code should 
be an integer, with values of "0/1/2/3", corresponding to the 
"OK/WARNING/CRITICAL/UNKNOWN" string values 
that are actually sent.

Using an amended version of the SUBMIT_CHECK_RESULT_VIA_NSCA bash shell script, 
which substitutes the appropriate integer value for the supplied string (and 
which is invoked to execute 
the [/usr/sbin/]send_nsca command that transmits the passive check data to the 
central monitoring server) results in the correct 'Status' being displayed in 
the central nagios web 
interface and the corresponding notifications being issued.

The underlying cause of the problem seems to be inconsistancy between the use 
of integer and string return_codes deeper within the nagios logic i.e. the 
passive check return_code should be 
supplied to the SUBMIT_CHECK_RESULT_VIA_NSCA script as an integer and not as a 
string.


-- System Information:
Debian Release: 5.0.7
Architecture: i386 (i686)

Kernel: Linux 2.6.32
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages nagios3 depends on:
ii  libc6   2.7-18lenny6 GNU C Library: Shared libraries
ii  libgd2-xpm  2.0.36~rc1~dfsg-3+lenny1 GD Graphics Library version 2
ii  libjpeg62   6b-14The Independent JPEG Group's JPEG 
ii  libperl5.10 5.10.0-19lenny2  Shared Perl library
ii  libpng12-0  1.2.27-2+lenny4  PNG library - runtime
ii  nagios3-common  3.0.6-4~lenny2   support files for nagios3
ii  perl5.10.0-19lenny2  Larry Wall's Practical Extraction 
ii  zlib1g  1:1.2.3.3.dfsg-12compression library - runtime

nagios3 recommends no packages.

Versions of packages nagios3 suggests:
ii  nagios-nrpe-plugin2.12-1 Nagios Remote Plugin Executor Plug

-- 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