Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack

2024-05-07 Thread Tito Ragusa 
Package: src:linux
Version: 6.1.90-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

   Rebooting the box after kernel package upgrade

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

   * What was the outcome of this action?
 
   Nothing 

   * What outcome did you expect instead?

   Rebooting without traces in the logs
 
-- Package-specific info:
** Version:
Linux version 6.1.0-21-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64 
root=UUID=a75e6ad5-37fc-4f69-9361-f94d6c0e5d2f ro net.ifnames=0 apparmor=0 
selinux=0 noresume consoleblank=0 console=tty1

** Tainted: WOE (12800)
 * kernel issued warning
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
  May  7 08:10:12 cerberus kernel: [   76.203881] [ cut here 
]
May  7 08:10:12 cerberus kernel: [   76.203895] WARNING: CPU: 3 PID: 0 at 
net/bridge/br_netfilter_hooks.c:622 br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
May  7 08:10:12 cerberus kernel: [   76.203911] Modules linked in: ctr ccm 
nf_tables xt_nat xt_recent xt_geoip(OE) xt_NFQUEUE xt_mark xt_CT xt_tcpudp 
xt_helper nf_nat_ftp nf_conntrack_ftp ip6table_raw ip6table_mangle ip6table_nat 
xt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_LOG nf_log_syslog ipt_REJECT 
nf_reject_ipv4 iptable_raw iptable_mangle xt_multiport xt_state xt_limit 
xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c 
ip6table_filter ip6_tables iptable_filter ip_tables x_tables ovpn_dco_v2(OE) 
ip6_udp_tunnel udp_tunnel tcp_bbr nct6775 nct6775_core hwmon_vid br_netfilter 
bridge stp llc nfnetlink_queue nfnetlink i915 ppdev intel_rapl_msr evdev 
intel_rapl_common x86_pkg_temp_thermal intel_powerclamp drm_buddy coretemp 
video rt2800usb wmi ghash_clmulni_intel drm_display_helper rt2x00usb 
sha512_ssse3 sha512_generic rt2800lib rt2x00lib cec sha256_ssse3 sha1_ssse3 
rc_core mac80211 aesni_intel ttm crypto_simd drm_kms_helper libarc4 cryptd 
cfg80211 rapl intel_cstate drm intel_uncore rfkill parport_pc pcspkr
May  7 08:10:12 cerberus kernel: [   76.203999]  serio_raw iTCO_wdt 
intel_pmc_bxt iTCO_vendor_support parport watchdog at24 button ext4 crc16 
mbcache jbd2 crc32c_generic sg sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif 
crct10dif_generic ahci libahci libata crct10dif_pclmul crct10dif_common 
crc32_pclmul crc32c_intel psmouse scsi_mod i2c_i801 i2c_smbus ehci_pci ehci_hcd 
scsi_common lpc_ich usbcore igb i2c_algo_bit usb_common dca
May  7 08:10:12 cerberus kernel: [   76.204039] CPU: 3 PID: 0 Comm: swapper/3 
Tainted: G   OE  6.1.0-21-amd64 #1  Debian 6.1.90-1
May  7 08:10:12 cerberus kernel: [   76.204044] Hardware name: Sophos UTM/To be 
filled by O.E.M., BIOS 4.6.4 11/08/2011
May  7 08:10:12 cerberus kernel: [   76.204046] RIP: 
0010:br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
May  7 08:10:12 cerberus kernel: [   76.204056] Code: df e8 4b b7 cd fa 66 83 
ab b8 00 00 00 08 eb 94 be 04 00 00 00 48 89 df e8 34 b7 cd fa 66 83 ab b8 00 
00 00 04 e9 7a ff ff ff <0f> 0b e9 f0 fe ff ff 0f 0b e9 dd fe ff ff 48 89 ef e8 
41 67 d8 fa
May  7 08:10:12 cerberus kernel: [   76.204059] RSP: 0018:bf5600144928 
EFLAGS: 00010202
May  7 08:10:12 cerberus kernel: [   76.204062] RAX: 0002 RBX: 
9ac2862ff300 RCX: 
May  7 08:10:12 cerberus kernel: [   76.204065] RDX: bf5600144980 RSI: 
9ac2862ff300 RDI: 
May  7 08:10:12 cerberus kernel: [   76.204067] RBP: 9ac2848a8100 R08: 
0001 R09: 9ac2872be980
May  7 08:10:12 cerberus kernel: [   76.204070] R10: 9ac2872be000 R11: 
0002 R12: bf5600144980
May  7 08:10:12 cerberus kernel: [   76.204072] R13:  R14: 
9ac282f4bac0 R15: 9ac2d027da00
May  7 08:10:12 cerberus kernel: [   76.204074] FS:  () 
GS:9ac5b018() knlGS:
May  7 08:10:12 cerberus kernel: [   76.204077] CS:  0010 DS:  ES:  
CR0: 80050033
May  7 08:10:12 cerberus kernel: [   76.204080] CR2: 5618751eb018 CR3: 
2e610006 CR4: 000606e0
May  7 08:10:12 cerberus kernel: [   76.204083] Call Trace:
May  7 08:10:12 cerberus kernel: [   76.204087]  
May  7 08:10:12 cerberus kernel: [   76.204090]  ? __warn+0x7d/0xc0
May  7 08:10:12 cerberus kernel: [   76.204097]  ? br_nf_local_in+0x1a9/0x1d0 
[br_netfilter]
May  7 08:10:12 cerberus kernel: [   76.204105]  ? report_bug+0xe2/0x150
May  7 08:10:12 cerberus kernel: [   76.204113]  ? handle_bug+0x41/0x70
May  7 08:10:12 cerberus kernel: [   76.204118]  ? exc_invalid_op+0x13/0x60
May  7 08:10:12 cerberus kernel: [   76.204122]  ? asm_exc_invalid_op+0x16/0x20
May  7 08:10:12 cerberus kernel: [   76.204128]  ? br_nf_local_in+0x1a9/0x1d0 
[br_netfilter]
May  7 08:10:12 cerberus

Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script

2023-12-01 Thread tito 
On Fri, 1 Dec 2023 09:48:50 +0100
Lorenzo  wrote:

> On Fri, 1 Dec 2023 07:53:57 +0100
> tito  wrote:
> 
> > > > 
> > > > Even the cronjob is gone.
> > > 
> > > sorry, the patch does not include cronjob since o-s-s does not have
> > > a way to handle it.
> > 
> > Couldn't it be appended to crontab?
> there is no mechanism to selectively add (and remove/purge) additional
> file or snippets such as cronjobs or /etc/default/*
> 
> > Hi,
> > shouldn't /etc/default/mdadm be moved also to o-s-s?
> > I bet it is the next file to be dropped after timers
> 
> can't find the file, even in buster
> https://packages.debian.org/buster/amd64/mdadm/filelist
> 
> Well, I have it on my system but same problem as for the cronjob

Hi,
but the file is still referenced in /etc/init.d/mdadm

# grep /etc/default/mdadm /etc/init.d/mdadm*
/etc/init.d/mdadm:DEBIANCONFIG=/etc/default/mdadm

from the 5 variables set in /etc/default/mdadm:

AUTOCHECK, AUTOSCAN, VERBOSE at a first glance are ignored

 START_DAEMON has already been moved to the initscript
 so that from the /etc/default/mdadm you can only turn
the initscript off.  

I would propose to move  DAEMON_OPTIONS="--syslog"
to the initscript so that we can forget about /etc/default/mdadm.

The cronjob that will be removed soon is still a problem as it checks the 
arrays periodically

# By default, run at 00:57 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 
]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

There will be other cron jobs like this that will be susbtituted by systemd 
timers
so we need to find how to handle this.

Ciao,
Tito

> 
> $ cat /etc/default/mdadm 
> # mdadm Debian configuration
> #
> # You can run 'dpkg-reconfigure mdadm' to modify the values in this file, if
> # you want. You can also change the values here and changes will be preserved.
> # Do note that only the values are preserved; the rest of the file is
> # rewritten.
> #
> 
> # AUTOCHECK:
> #   should mdadm run periodic redundancy checks over your arrays? See
> #   /etc/cron.d/mdadm.
> AUTOCHECK=true
> 
> # AUTOSCAN:
> #   should mdadm check once a day for degraded arrays? See
> #   /lib/systemd/system/mdmonitor-oneshot.service
> AUTOSCAN=true
> 
> # START_DAEMON:
> #   should mdadm start the MD monitoring daemon during boot?
> START_DAEMON=true
> 
> # DAEMON_OPTIONS:
> #   additional options to pass to the daemon.
> DAEMON_OPTIONS="--syslog"
> 
> # VERBOSE:
> #   if this variable is set to true, mdadm will be a little more verbose e.g.
> #   when creating the initramfs.
> VERBOSE=false
> 
> 
> Lorenzo
> 
> >  
> > Ciao,
> > Tito
>

Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script

2023-11-30 Thread tito 
On Fri, 1 Dec 2023 02:41:21 +0100
Lorenzo  wrote:

> Control: tags -1 patch
> 
> Hello Matthew,
> 
> attached is a git patch that adds mdadm and mdadm-waitidle
> scripts.
> 
> On Thu, 9 Nov 2023 16:09:22 +0100
> Stephan Seitz  wrote:
> 
> > [...]
> 
> >   * Removing cron jobs in favour of systemd timers:
> > - daily checks also work if system is not always on (Closes:
> > #889978).
> I thought that anacron could handle this..
> 
> > 
> > Even the cronjob is gone.
> 
> sorry, the patch does not include cronjob since o-s-s does not have
> a way to handle it.

Couldn't it be appended to crontab?

> By the way I don't remember a project consensus for dropping
> cronjobs in favour of timers..
> 
> Best Regards,
> Lorenzo
> 

Hi,
shouldn't /etc/default/mdadm be moved also to o-s-s?
I bet it is the next file to be dropped after timers
 
Ciao,
Tito

Bug#998893: closed by Debian FTP Masters (reply to Matthew Vernon ) (Bug#998893: fixed in orphan-sysvinit-scripts 0.09)

2021-11-20 Thread tito 
On Sun, 21 Nov 2021 02:09:55 +0100
Axel Beckert  wrote:

> Hi,
> 
> On Wed, Nov 10, 2021 at 05:48:38PM +, Matthew Vernon wrote:
> > On 10/11/2021 16:51, Adam Borowski wrote:
> > > On Wed, Nov 10, 2021 at 12:21:09PM +, Debian Bug Tracking System 
> > > wrote:
> > > > #998893: orphan-sysvinit-scripts: fails to configure: "not replacing 
> > > > deleted config file /etc/init.d/rsyslog"
> > > > It has been closed by Debian FTP Masters 
> > > >  (reply to Matthew Vernon 
> > > > ).
> > > 
> > > Alas, systems that were affected by this bug still fail to upgrade:
> > 
> > Yes, I'm afraid that's expected (because ucf still "knows" that the user
> > deleted /etc/init.d/rsyslog). Sorry!
> 
> Seems to have worked for me, but now I get the same error for 
> /etc/init.d/nftables:
> 
> Setting up orphan-sysvinit-scripts (0.10) ...
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> Not replacing deleted config file /etc/init.d/nftables
> update-rc.d: error: initscript does not exist: /etc/init.d/nftables
> dpkg: error processing package orphan-sysvinit-scripts (--configure):
>  installed orphan-sysvinit-scripts package post-installation script 
> subprocess returned error exit status 1
> 
> Shall I open a new bug or is this considered the same issue?
> 
> Hmm, after reading the changelog entry for this fix:
> 
>   * Check for scripts still owned by another package (Closes: #998893)
> 
> This sounds like a quite generic fix.
> 
> > > dpkg-query: no path found matching pattern /etc/init.d/rsyslog
> > > Not replacing deleted config file /etc/init.d/rsyslog
> > > update-rc.d: error: initscript does not exist: /etc/init.d/rsyslog
> > > dpkg: error processing package orphan-sysvinit-scripts (--configure):
> > >   installed orphan-sysvinit-scripts package post-installation script 
> > > subprocess returned error exit status 1
> > > Processing triggers for man-db (2.9.4-2) ...
> > > Errors were encountered while processing:
> > >   orphan-sysvinit-scripts
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > 
> > I think the easiest fix is:
> > ln -s /usr/share/orphan-sysvinit-scripts/rsyslog /etc/init.d/rsyslog
> > 
> > And then dpkg --pending --configure should work OK
> 
> So I tried this for nftables as well, but it seems to have made things
> worse:
> 
> # ln -s /usr/share/orphan-sysvinit-scripts/nftables /etc/init.d/nftables
> # dpkg --pending --configure
> Setting up orphan-sysvinit-scripts (0.10) ...
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> cp: '/usr/share/orphan-sysvinit-scripts/nftables' and 
> '/usr/share/orphan-sysvinit-scripts/nftables' are the same file
> dpkg: error processing package orphan-sysvinit-scripts (--configure):
>  installed orphan-sysvinit-scripts package post-installation script 
> subprocess returned error exit status 1
> Errors were encountered while processing:
>  orphan-sysvinit-scripts
> 
> Any adivce here?
> 
>   Regards, Axel

Hi,
couldn't renaming the scripts in the orphan-sysvinit-scripts package be a 
solution to solve this?
E.g from nftables to nftables-sv or nftables.sh or nftables-s5i or 
nftables-orphan.
Just my 0,2 cents.
Ciao,
Tito

Bug#994275: Reverting breaking changes in debianutils

2021-10-26 Thread tito 
On Sun, 24 Oct 2021 19:08:20 +
Clint Adams  wrote:

> On Sat, Oct 16, 2021 at 05:56:17PM +0200, Thorsten Glaser wrote:
> > No. You’re conflating “which ”, which indeed is mostly redundant
> > with “command -v”, with “which -a ”, which is NOT otherwise
> > available, and a very useful thing to have, and one which (heh, pun
> > not intended) I pretty much expect to exist on a system.
> 
> I can think of no reason why anyone would need to run `which -a`
> from a maintainer script.  For interactive use, csh (and tcsh)
> never had -a for `which`.  The reason that zsh has `which -a` is
> because it shares code with `whence -a`, which was taken from
> ksh in the '80s.  Of course there's no telling whether it would
> have evolved later on if it had been originally csh-compatible.
> 
> > I know that feeling… some package maintainers don’t seem to care about
> > warnings. But as something in an Essential package I fear it’s up to
> > you to ping them, time and time again, until they don’t depend on it
> > any more, instead of proactively removing it.
> 
> I disagree.  This is not a good system.  This is how you architect an
> ultraconservative culture that discourages people from fixing things.
> 
> On Sun, Oct 17, 2021 at 06:32:33AM -0400, James Cloos wrote:
> > i got hit by the removal of tepfile(1); pv-grub-menu uses it in its
> > postint script and its removal started blocking my apt upgrades.  i had
> > to copy tempfile over from a virt stuck on an older deb to get around it.
> > 
> > (cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101)
> > 
> > it would be useful to ensure no packages rely on something before
> > removing it...
> 
> The fix for pv-grub-menu is as follows:
> 
> ---8<---snip---8<---
> diff --git a/update-menu-lst b/update-menu-lst
> index f2ca1c7..2e01a39 100755
> --- a/update-menu-lst
> +++ b/update-menu-lst
> @@ -128,7 +128,7 @@ fi
>  # Default options to use in a new config file. This will only be used if 
> $menu_file
>  # doesn't already exist. Only edit the lines between the two "EOF"s. The 
> others are
>  # part of the script.
> -newtemplate=$(tempfile)
> +newtemplate=$(mktemp)
>  cat > "$newtemplate" <  # $menu_file_basename - See: grub(8), info grub, update-grub(8)
>  #grub-install(8), grub-floppy(8),
> @@ -443,7 +443,7 @@ howmany=$(GetMenuOpt "howmany" "$howmany")
>  memtest86=$(GetMenuOpt "memtest86" "$memtest86")
>  
>  # Generate the menu options we want to insert
> -buffer=$(tempfile)
> +buffer=$(mktemp)
>  echo $start >> $buffer
>  echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" 
> >> $buffer
>  echo "## by the debian update-grub script except for the default options 
> below" >> $buffer
> ---8<---snip---8<---
> 
> How much effort is involved with that?  I would guess that it is less than
> bullying me into adding a `tempfile` as a Debian-specific patch to debianutils
> or bullying me into uploading a `tempfile` package that I do not wish to
> maintain.
> 
> On Sun, Oct 17, 2021 at 05:36:25AM -0700, Felix Lechner wrote:
> > Lintian's last remaining reference to 'tempfile' was dropped. [1] The
> > updated tag description is now live on our website. [2]
> 
> Thanks.
> 
> On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> > I think causing build failures is enough reason to say this. I don't
> > suppose that mine is the only one. Yes those builds are buggy and
> > should not do this, and we should make efforts to find out why bazel
> > (or possibly the build scripts it is operating on) is/are so crappy,
> > but for now I agree that reverting this is the right thing to do.
> > 
> > We have time to do this transition properly and quietly in the
> > background, without causing random breakage. A message about a binary
> > moving from one package to another does not need to be printed on
> > every usage of that binary. Indeed it is actively unhelpful to do so.
> 
> Boyuan packaged GNU which and uploaded it to NEW in August.  It is now
> October, and neither GNU which nor *BSD which nor any other which
> alternative is in unstable.  Presumably one of these could have put
> a band-aid on your bazel problem, though of course any version of
> `which` might output things to stderr for a variety of reasons.

Hi,
there is busybox that has which compiled in and is available
in all repos :

$busybox which
BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) multi-call binary.

Usage: which [COMMAND]...

Locate a COMMAND

and It does have command line option -a 

getopt32(argv, "

Bug#670585: "ok hat location is writable"

2019-05-09 Thread Tito 




On 5/9/19 9:35 AM, Dmitry Bogatov wrote:


[2019-05-08 14:57] Tito 

Problem is that I do not understand, when /var/log/fsck exist for sure.

Collegues, I need help with evaluating proposed change.


Hi,
I guess if it is a one partition only setup /var/log will
exist as soon as as root is switched from initrd and/or
remounted read-write, if it is a multi-partition setup
with separated partitions for /tmp, /home and /var,
/var will exist as soon as root is switched from
initrd but /var/log will exist only after /var is mounted.


So it means, that check 'test -w "${FSCK_LOGFILE}"' that you proposed is
only meaningful after 'mountall', but not in 'checkfs'. So I have to
keep more vague

"Log is being saved in ${FSCK_LOGFILE} if that location is writable"

Did I miss something?


Hi,
No you didn't. An alternative approach could be:

test if we are in a single-partition environment
and /var/log/ exists, maybe it is not writable yet
but we are optimistic that we can write to it

if test -d `dirname ${FSCK_LOGFILE}` ; then
"Log is being saved in ${FSCK_LOGFILE}"
else
/var/log doesnt' exist yet and we really cannot say
if it ever will, stay more vague
"Trying to save log to ${FSCK_LOGFILE}"
fi

but that is only cosmetic.

The KISS solution would be to use always

"Trying to save log to ${FSCK_LOGFILE}"

and so if the user really needs to read the file
he will go to see if it is there, if the user
doesn't care it makes no difference if it was
"being saved" or "Trying to be saved".

Ciao,
Tito

Bug#670585: "ok hat location is writable"

2019-05-08 Thread Tito 




On 5/8/19 6:38 AM, Dmitry Bogatov wrote:


[2019-05-06 07:33] Tito 

[ Dmitry Bogatov ]

-   log_success_msg "Done checking file systems.
-A log is being saved in ${FSCK_LOGFILE} if that location is writable."
+   log_success_msg 'Done checking file systems'
+   log_success_msg "Log is being saved in 
${FSCK_LOGFILE} if that location is writable"
fi
fi



Hi,
maybe something like:

if test -w ${FSCK_LOGFILE} ; then
log_success_msg "Log is saved in ${FSCK_LOGFILE}
else
log_success_msg "Cannot save log in ${FSCK_LOGFILE}
fi


Thank you, Tito. But I am not sure this is correct:

As I understand the whole point of "logsave" is that if directory of
logfile (/var/log/fsck) does not exist, "logsave" will wait till it
appears.

So, by the time we are logging this message, ${FSCK_LOGFILE} may not
exists yet, but its future content is hanging somewhere in memory of
"logsave" process.

Problem is that I do not understand, when /var/log/fsck exist for sure.

Collegues, I need help with evaluating proposed change.


Hi,
I guess if it is a one partition only setup /var/log will
exist as soon as as root is switched from initrd and/or
remounted read-write, if it is a multi-partition setup
with separated partitions for /tmp, /home and /var,
/var will exist as soon as root is switched from
initrd but /var/log will exist only after /var is mounted.
If there is something in the outbuf buffer
logsave loops forever !?  until it gets a file descriptor:

setsid();   /* To avoid getting killed by init */
while (outfd < 0) {
outfd = open(outfn, openflags, 0644);
sleep(1);
}
write_all(outfd, outbuf, outbufsize);
free(outbuf);
}

open(), openat(), and creat() return the new file descriptor, or -1 if an error 
occurred

Hope this helps.
Ciao,
Tito

Bug#670585: "ok hat location is writable"

2019-05-05 Thread Tito 




On 5/5/19 9:41 PM, Dmitry Bogatov wrote:


control: usertags -1 +objections

[2019-05-02 22:00] Antoni Villalonga 

I've found the message here:

/etc/rcS.d/S10checkfs.sh
124 log_success_msg "Done checking file systems.
125 A log is being saved in ${FSCK_LOGFILE} if that location is writable."

I think the console width was 80 chars and it caused "if that location..."
message drop to next line. After that, "[ ok " message overwrited from the
beggining of the line, causing the anoying message.



If this problem is meant to be "fixed"? Shorter messages (if any) may
be the easy way.


Thank you for suggestion. I managed reproduce similar (but not exactly
same) glitch with long line and 80 column wide terminal.

I believe following patch, that splits and slightly rewords message
should fix issue. Second part is still quite long -- long enough to fill
exactly 80 columns, but I have no idea how to shorten it futher.
Opinions?

 From 2799d371c413b9c606e968eb61f94711ce70cd4f Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Fri, 3 May 2019 17:21:17 +
Subject: [PATCH] Split long message into several lines

Long message on 80-column may cause visual glitches due interation of
terminal control characters and newline breaking, so it is safer to
make sure that no argument to 'log_{success,warning,error}_msg' is
no longer than 70 characters (generously leaving 10 characters for colored
ok/warn/error marker on the left).

Closes: #670585
Thanks: Antoni Villalonga 
---
  debian/src/initscripts/etc/init.d/checkfs.sh | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/src/initscripts/etc/init.d/checkfs.sh 
b/debian/src/initscripts/etc/init.d/checkfs.sh
index 13a10d10..67929dec 100755
--- a/debian/src/initscripts/etc/init.d/checkfs.sh
+++ b/debian/src/initscripts/etc/init.d/checkfs.sh
@@ -121,8 +121,8 @@ Continuing with system boot in 5 seconds."
then
handle_failed_fsck
else
-   log_success_msg "Done checking file systems.
-A log is being saved in ${FSCK_LOGFILE} if that location is writable."
+   log_success_msg 'Done checking file systems'
+   log_success_msg "Log is being saved in 
${FSCK_LOGFILE} if that location is writable"
fi
fi
fi






Hi,
maybe something like:

if test -w ${FSCK_LOGFILE} ; then
log_success_msg "Log is saved in ${FSCK_LOGFILE}
else
log_success_msg "Cannot save log in ${FSCK_LOGFILE}
fi

Ciao,
Tito

Bug#918227: xtables-addons-common: GeoIPCountryCSV.zip ERROR 404: Not Found

2019-01-04 Thread Tito Ragusa 
Package: xtables-addons-common
Version: 2.12-0.1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 Running periodically a script that calls 
/usr/lib/xtables-addons/xt_geoip_dl
 to update GeoIPv6.csv.gz and GeoIPCountryCSV.zip
   * What exactly did you do (or not do) that was effective (or
 ineffective)
 Call  /usr/lib/xtables-addons/xt_geoip_dl
   * What was the outcome of this action?
 --2019-01-04 14:26:53--  
http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
 Reusing existing connection to geolite.maxmind.com:80.
 HTTP request sent, awaiting response... 404 Not Found
   * What outcome did you expect instead?
 Download GeoIPCountryCSV.zip, but starting January 2, 2019 it was removed
 from the website and a switch to GeoLite2 format databases is needed
 which could be downloaded at 
https://geolite.maxmind.com/download/geoip/database/GeoLite2-Country-CSV.zip.
 Sadly it seems to me that the xtables packages in the stable repositories
 are unable to handle the GeoLite2 format databases. 
 

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xtables-addons-common depends on:
ii  libc6 2.24-11+deb9u3
ii  libxtables12  1.6.0+snapshot20161117-6

Versions of packages xtables-addons-common recommends:
ii  unzip6.0-21
ii  wget 1.18-5+deb9u2
ii  xtables-addons-dkms  2.12-0.1

Versions of packages xtables-addons-common suggests:
ii  libtext-csv-xs-perl  1.26-1

-- no debconf information

Bug#363132: hdparm 6.3-3: minor bug

2006-04-17 Thread Tito 
Package:hdparm
Version:6.3-3
Severity:minor
Tags:patch

When I invoke the hdparm -i /dev/hda it shows some NULL
pointers in the output. Here is a transcript:

hdparm -i /dev/hda

/dev/hda:

 Model=Maxtor 6Y120P0, FwRev=YAR41BW0, SerialNo=Y360H3DE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=240121728
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=yes: disabled (255) WriteCache=enabled

 ==Drive conforms to: (null):  ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 
ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

 * signifies the current active mode

I suggest to apply the following patch that adds two missing commas to the 
source:
Ciao,
Tito Ragusa [EMAIL PROTECTED]

diff -uN identify_orig.c identify.c
--- identify_orig.c 2006-04-17 21:31:07.0 +0200
+++ identify.c  2006-04-17 21:31:31.0 +0200
@@ -262,8 +262,8 @@
Reserved, /* 0x001a   */
ATA/ATAPI-6 T13 1410D revision 2, /* 0x001b   */
ATA/ATAPI-6 T13 1410D revision 1, /* 0x001c   */
-   Reserved  /* 0x001d   */
-   Reserved  /* 0x001e   */
+   Reserved, /* 0x001d   */
+   Reserved, /* 0x001e   */
Reserved  /* 0x001f-0xfffe*/
 };
 const char actual_ver[] = {

--- identify_orig.c	2006-04-17 21:31:07.0 +0200
+++ identify.c	2006-04-17 21:31:31.0 +0200
@@ -262,8 +262,8 @@
 	Reserved,	/* 0x001a	*/
 	ATA/ATAPI-6 T13 1410D revision 2,		/* 0x001b	*/
 	ATA/ATAPI-6 T13 1410D revision 1,		/* 0x001c	*/
-	Reserved	/* 0x001d	*/
-	Reserved	/* 0x001e	*/
+	Reserved,	/* 0x001d	*/
+	Reserved,	/* 0x001e	*/
 	Reserved	/* 0x001f-0xfffe*/
 };
 const char actual_ver[] = {