You are not logged in.
Have you told the system where swap for hiberation is?
The usual place is in the file /etc/initramfs-tools/conf.d/resume
On my system swap in on a LVM volume, so I have:
marjorie@grendel:~$ cat /etc/initramfs-tools/conf.d/resume
RESUME=/dev/mapper/grendel--vg-grendel--swap
For a non-LVM system this would be:
RESUME=/dev/sdxn
where /dev/sdxn is your swap partition.
You can also specify swap using UUID
RESUME=UUID=
To disable change it to
RESUME=NONE
You will then need to update your initramfs to make it work.
sudo update-initramfs -u
sudo reboot
Update: on the messages you are seeing in syslog.
I've now had a look in mine and by comparison I think the ones you are citing may be normal and are simply being repeated when you sleep/resume.
This is what I get on resume from hibernation:
Aug 20 22:43:34 grendel kernel: [63606.742486] ------------[ cut here ]------------
Aug 20 22:43:34 grendel kernel: [63606.742487] WARNING: CPU: 0 PID: 2045 at drivers/iommu/amd/init.c:851 amd_iommu_enable_interrupts+0x32a/0x400
Aug 20 22:43:34 grendel kernel: [63606.742494] Modules linked in: fuse rfcomm ccm cmac algif_hash algif_skcipher af_alg bnep binfmt_misc ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog nft_limit xt_limit xt_addrtype xt_tcpudp ip_tables xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat x_tables nf_tables nct6687(OE) nfnetlink hwmon_vid firewire_sbp2 firewire_core crc_itu_t msr parport_pc ppdev lp parport intel_rapl_msr intel_rapl_common edac_mce_amd iwlmvm btusb btrtl wmi_bmof btbcm btintel kvm mac80211 btmtk bluetooth irqbypass crc32_pclmul snd_hda_codec_realtek libarc4 ghash_clmulni_intel snd_hda_codec_generic ledtrig_audio iwlwifi aesni_intel uvcvideo crypto_simd cryptd snd_hda_codec_hdmi videobuf2_vmalloc snd_usb_audio videobuf2_memops jitterentropy_rng videobuf2_v4l2 videobuf2_common snd_hda_intel rapl pcspkr sha512_ssse3 snd_intel_dspcfg videodev k10temp snd_usbmidi_lib snd_intel_sdw_acpi sha512_generic snd_hda_codec cfg80211 snd_rawmidi
Aug 20 22:43:34 grendel kernel: [63606.742531] snd_seq_device ctr mc snd_hda_core joydev drbg r8169 snd_hwdep ansi_cprng snd_pcm sp5100_tco realtek watchdog ecdh_generic snd_timer mdio_devres ecc i2c_piix4 libphy snd ccp rfkill soundcore sr_mod rng_core cdrom sg video button acpi_cpufreq wmi amd_pmc ext4 crc16 mbcache jbd2 raid10 raid456 libcrc32c crc32c_generic async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid0 multipath linear dm_mod evdev raid1 md_mod hid_generic amdgpu sd_mod usbhid drm_ttm_helper t10_pi ttm hid gpu_sched crc64_rocksoft crc64 crc_t10dif i2c_algo_bit crct10dif_generic drm_dp_helper drm_kms_helper ahci libahci xhci_pci drm libata xhci_hcd usbcore scsi_mod cec crct10dif_pclmul crct10dif_common crc32c_intel rc_core usb_common scsi_common gpio_amdpt gpio_generic
Aug 20 22:43:34 grendel kernel: [63606.742566] CPU: 0 PID: 2045 Comm: elogind-daemon Tainted: G W OE 5.18.0-0.bpo.1-amd64 #1 Debian 5.18.2-1~bpo11+1
Aug 20 22:43:34 grendel kernel: [63606.742568] Hardware name: Micro-Star International Co., Ltd. MS-7C56/MPG B550 GAMING PLUS (MS-7C56), BIOS 1.50 01/14/2021
Aug 20 22:43:34 grendel kernel: [63606.742570] RIP: 0010:amd_iommu_enable_interrupts+0x32a/0x400
Aug 20 22:43:34 grendel kernel: [63606.742572] Code: ff ff 48 8b 7b 18 89 04 24 e8 72 e6 ef ff 8b 04 24 e9 78 fd ff ff 0f 0b 48 8b 1b 48 81 fb 10 ad 1f 90 0f 85 33 fd ff ff eb 96 <0f> 0b 48 8b 1b 48 81 fb 10 ad 1f 90 0f 85 1f fd ff ff eb 82 31 c9
Aug 20 22:43:34 grendel kernel: [63606.742573] RSP: 0018:ffffbf3ac3493cd0 EFLAGS: 00010046
Aug 20 22:43:34 grendel kernel: [63606.742575] RAX: 0000001ff3504f4a RBX: ffff9ebd8004b000 RCX: 0000000000000000
Aug 20 22:43:34 grendel kernel: [63606.742576] RDX: 000000000000a12e RSI: 00000000000096d9 RDI: 0000001ff34fae1c
Aug 20 22:43:34 grendel kernel: [63606.742577] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000002f
Aug 20 22:43:34 grendel kernel: [63606.742577] R10: 0000000000000000 R11: ffff9ec02e2928d8 R12: 0000000080000000
Aug 20 22:43:34 grendel kernel: [63606.742578] R13: 000ffffffffffff8 R14: 0800000000000000 R15: 0008000000000000
Aug 20 22:43:34 grendel kernel: [63606.742579] FS: 00007f06861fe980(0000) GS:ffff9ec01f800000(0000) knlGS:0000000000000000
Aug 20 22:43:34 grendel kernel: [63606.742580] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 20 22:43:34 grendel kernel: [63606.742581] CR2: 00007f82300032f6 CR3: 000000010869c000 CR4: 0000000000750ef0
Aug 20 22:43:34 grendel kernel: [63606.742582] PKRU: 55555554
Aug 20 22:43:34 grendel kernel: [63606.742583] Call Trace:
Aug 20 22:43:34 grendel kernel: [63606.742584] <TASK>
Aug 20 22:43:34 grendel kernel: [63606.742587] ? memcpy_toio+0x1c/0xb0
Aug 20 22:43:34 grendel kernel: [63606.742591] amd_iommu_reenable+0x39/0x40
Aug 20 22:43:34 grendel kernel: [63606.742592] lapic_resume+0x279/0x2d0
Aug 20 22:43:34 grendel kernel: [63606.742595] syscore_resume+0x4a/0x160
Aug 20 22:43:34 grendel kernel: [63606.742597] hibernation_snapshot+0x227/0x490
Aug 20 22:43:34 grendel kernel: [63606.742601] hibernate.cold+0x8b/0x206
Aug 20 22:43:34 grendel kernel: [63606.742604] state_store+0xcb/0xd0
Aug 20 22:43:34 grendel kernel: [63606.742606] kernfs_fop_write_iter+0x124/0x1b0
Aug 20 22:43:34 grendel kernel: [63606.742609] new_sync_write+0x109/0x190
Aug 20 22:43:34 grendel kernel: [63606.742612] vfs_write+0x20d/0x290
Aug 20 22:43:34 grendel kernel: [63606.742614] ksys_write+0x5f/0xe0
Aug 20 22:43:34 grendel kernel: [63606.742615] do_syscall_64+0x3b/0xc0
Aug 20 22:43:34 grendel kernel: [63606.742618] entry_SYSCALL_64_after_hwframe+0x44/0xae
Aug 20 22:43:34 grendel kernel: [63606.742620] RIP: 0033:0x7f0686413f6f
Aug 20 22:43:34 grendel kernel: [63606.742626] Code: Unable to access opcode bytes at RIP 0x7f0686413f45.
Aug 20 22:43:34 grendel kernel: [63606.742626] RSP: 002b:00007fff5a227fc0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
Aug 20 22:43:34 grendel kernel: [63606.742628] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f0686413f6f
Aug 20 22:43:34 grendel kernel: [63606.742628] RDX: 0000000000000005 RSI: 00007fff5a2280d0 RDI: 0000000000000011
Aug 20 22:43:34 grendel kernel: [63606.742629] RBP: 00007fff5a2280d0 R08: 0000000000000000 R09: 00007fff5a2271f0
Aug 20 22:43:34 grendel kernel: [63606.742630] R10: 00007fff5a2270a4 R11: 0000000000000293 R12: 0000000000000005
Aug 20 22:43:34 grendel kernel: [63606.742630] R13: 00005612510ba2a0 R14: 0000000000000005 R15: 00007f06864e48a0
Aug 20 22:43:34 grendel kernel: [63606.742632] </TASK>
Aug 20 22:43:34 grendel kernel: [63606.742632] ---[ end trace 0000000000000000 ]---
Aug 20 22:43:34 grendel kernel: [63607.283878] LVT offset 0 assigned for vector 0x400
Aug 20 22:43:34 grendel kernel: [63607.284206] Enabling non-boot CPUs ...
So I suspect whatever is intermittently spamming your syslog is something else.
I'm afraid I've no experience of this sort of error: It seems the kernel is throwing some sort of exception and triggering a trace. Could be something specific to your acer or your kernel version. I do note that the bios is from 2007 - might be worth checking if there is a newer version.
Maybe someone else can make a suggestion?
Meanwhile you could make changes to logrotate to limit the size of the files being generated:
1) Switch from weekly to daily rotations.
2) Remove the delaycompress command so gzip is done immediately
or I would suggest:
3) Change from a periodic (hourly/daily/weekly/monthly) to using a log file size or maxsize parameter. This would force log rotation when the log gets to a specific size. Maxsize works in combination with periodic rotation, size instead of.
You might want to do this just for the messages, kern and syslog log files, thoug I suspect any reasonably generous maxsize wont limit other log files too much.
You can look up the definitions of these parameters in man logrotate.
The downside to doing this is that you obviously have fewer logs available to debug problems.
OK, logrotate is working as intended.
If you suspend or hibernate and resume then it's probably that anacron will only do it's daily execute and call logrotate when you resume.
However it looks likely that some process has 'spammed' your systems logs between 31 July 31 and 7 August: 65Mb of compressed log files in that period is impressive - obviously it would have been much more when it happened and the log file was uncompressed.
I suggest you have a look in /var/log/syslog.3.gz for what is causing the problem. I assume that whatever it is is triggering happens intermittently if the partitions are filling up repeatedly.
Thanks. That's not the problem then.
Is logrotate working properly?
If I look in /var/log for messages (for example) I see:
marjorie@grendel:~$ ls -alF /var/log/messages*
-rw-r----- 1 root adm 224595 Aug 21 13:07 /var/log/messages
-rw-r----- 1 root adm 992245 Aug 18 17:24 /var/log/messages.1
-rw-r----- 1 root adm 159582 Aug 8 21:47 /var/log/messages.2.gz
-rw-r----- 1 root adm 63014 Jul 23 10:18 /var/log/messages.3.gz
-rw-r----- 1 root adm 110513 Jul 13 21:37 /var/log/messages.4.gz
Obviously in your case what you see may depend on when messages is logrotated, but the size and number of archives should be similar.
You might also want to check the syslog and kern log files for size and dates.
Also check that you have a logrotate cron job: mines run daily by anacron so I have:
marjorie@grendel:~$ ls -alF /etc/cron.daily/logrotate
-rwxr-xr-x 1 root root 377 Aug 28 2018 /etc/cron.daily/logrotate*
Have you got your logrotate set up properly? You should be limiting how long/how many log messages you keep.
Can you report the content of your /etc/logrotate.d/rsyslog.
Mine looks like this:
/var/log/syslog
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
Hi Alex,
no I don't think it's that:
the curl command on the website (that I copied and pasted and executed, sorry should have also listed in my message) uses https://...
For some reason the error message refer to http://..
Changing the curl command to use http://.. results in the same error message when I run sudo apt update.
I would be interested in having Ungoogled Chromium since I use firefox-esr with security/privacy extensions and there are a small number of commercial websites that don't play ball. I'm not keen on using the standard chromium deb in the Chimaera repositories, though I did install it on a spare PC for a guest who relies on his saved google setting (bookmarks, etc).
However having gone to https://github.com/ungoogled-software/u … d-chromium I tried to follow the download instructions here:
https://github.com/ungoogled-software/u … ium-debian (since there isn't a devuan repository) and get stuck at the apt update stage:
marjorie@grendel:~$ sudo apt update
Hit:1 https://updates.signal.org/desktop/apt xenial InRelease
Get:2 http://download.opensuse.org/repositories/home:/ungoogled_chromium/Debian_Bullseye InRelease [1,565 B]
Err:2 http://download.opensuse.org/repositories/home:/ungoogled_chromium/Debian_Bullseye InRelease
The following signatures were invalid: EXPKEYSIG 02456C79B2FD48BF home:ungoogled_chromium OBS Project <home:ungoogled_chromium@build.opensuse.org>
Hit:3 http://deb.devuan.org/merged chimaera InRelease
Hit:4 http://deb.devuan.org/merged chimaera-updates InRelease
Hit:5 http://deb.devuan.org/merged chimaera-security InRelease
Hit:6 https://debian.rickslab.com/gpu-utils eddore InRelease
Hit:7 http://deb.devuan.org/merged chimaera-backports InRelease
Reading package lists... Done
W: GPG error: http://download.opensuse.org/repositories/home:/ungoogled_chromium/Debian_Bullseye InRelease: The following signatures were invalid: EXPKEYSIG 02456C79B2FD48BF home:ungoogled_chromium OBS Project <home:ungoogled_chromium@build.opensuse.org>
E: The repository 'http://download.opensuse.org/repositories/home:/ungoogled_chromium/Debian_Bullseye InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
Just checking.
Can you post the code for your
/etc/fstab,
the primary menuentry from /etc/boot/grub/grub.cfg
the results of sudo blkid
and the results of sudo fdisk -l?
I'm wondering whether with your copying root partition contents around the UUID have got misaligned or you are using the wrong /dev/ (LVM vols. are usually on /dev/mapper/)
Both laptops also have a flavour of Ubuntu installed with DNS being looped in some way by systemd (127.0.0.63) I think. I have no idea about systemd, Both Ubuntu installs resolved deb.devuan.org.
Any ideas?
Indeed, systemd in it's usual feature creep tries to provide DNS resolution (and just about anything else) as well as init functions in this case with systemd-resolved.
Of course you don't find it on Devuan.
I use dsncrypt-proxy which uses a similar redirection to 127.0.0.1#53 to provide a local first-point-of-call for DNS (Port 53 is the default port for DNS queries). Along with local caching the proxy then looks up DNS on DNS servers out there on the internet. In the case of dnscrypt-proxy these are dns-over-https or dnscrypt servers and mine polls for ones that are DNSSEC and local.
In dnscrypt-proxy I can block evil DNS and IP. I don't know whether systemd-resolved has this capability, however clearly a systemd OS would be rather foolish to use deb.devuan.org as its repositories are systemd-free.
Seems to be working fine, using dnscrypt-proxy (hence local DNS server IP: 127.0.0.1#53 ) and Zen as my ISP in the UK.
marjorie@grendel:~$ dig deb.devuan.org
; <<>> DiG 9.16.27-Debian <<>> deb.devuan.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29801
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;deb.devuan.org. IN A
;; ANSWER SECTION:
deb.devuan.org. 2399 IN CNAME deb.rr.devuan.org.
deb.rr.devuan.org. 2399 IN A 130.225.254.116
deb.rr.devuan.org. 2399 IN A 185.203.114.135
deb.rr.devuan.org. 2399 IN A 185.178.192.43
deb.rr.devuan.org. 2399 IN A 95.216.15.86
deb.rr.devuan.org. 2399 IN A 125.228.189.120
deb.rr.devuan.org. 2399 IN A 5.9.122.185
deb.rr.devuan.org. 2399 IN A 185.183.113.131
deb.rr.devuan.org. 2399 IN A 200.236.31.1
deb.rr.devuan.org. 2399 IN A 46.4.50.2
deb.rr.devuan.org. 2399 IN A 160.16.137.156
deb.rr.devuan.org. 2399 IN A 195.85.215.180
deb.rr.devuan.org. 2399 IN A 185.38.15.81
deb.rr.devuan.org. 2399 IN A 89.174.102.150
deb.rr.devuan.org. 2399 IN A 158.69.153.121
deb.rr.devuan.org. 2399 IN A 141.84.43.19
deb.rr.devuan.org. 2399 IN A 131.188.12.211
;; Query time: 43 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 19 14:10:01 BST 2022
;; MSG SIZE rcvd: 320
I assume the list of IP are those of the component mirrors in the round-robin, so for the first 130.225.254.116 the corresponding DNS is mirrors.dotsrc.org.
marjorie@grendel:~$ dig -x 130.225.254.116
; <<>> DiG 9.16.27-Debian <<>> -x 130.225.254.116
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20569
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;116.254.225.130.in-addr.arpa. IN PTR
;; ANSWER SECTION:
116.254.225.130.in-addr.arpa. 3594 IN CNAME 116.96-27.254.225.130.in-addr.arpa.
116.96-27.254.225.130.in-addr.arpa. 3594 IN PTR mirrors.dotsrc.org.
;; Query time: 23 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 19 14:13:31 BST 2022
;; MSG SIZE rcvd: 113
Indeed. And package mariadb-server-10.5 on Chimaera provides an /etc/init.d/mariadb init script:
#!/bin/bash
#
### BEGIN INIT INFO
# Provides: mariadb
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Should-Start: $network $named $time
# Should-Stop: $network $named $time
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start and stop the mysql database server daemon
# Description: Controls the main MariaDB database server daemon "mariadbd"
# and its wrapper script "mysqld_safe".
### END INIT INFO
#
set -e
set -u
${DEBIAN_SCRIPT_DEBUG:+ set -v -x}
test -x /usr/sbin/mariadbd || exit 0
. /lib/lsb/init-functions
SELF=$(cd $(dirname $0); pwd -P)/$(basename $0)
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
# priority can be overridden and "-s" adds output to stderr
ERR_LOGGER="logger -p daemon.err -t /etc/init.d/mariadb -i"
if [ -f /etc/default/mysql ]; then
. /etc/default/mysql
fi
# Also source default/mariadb in case the installation was upgraded from
# packages originally installed from MariaDB.org repositories, which have
# had support for reading /etc/default/mariadb since March 2016.
if [ -f /etc/default/mariadb ]; then
. /etc/default/mariadb
fi
# Safeguard (relative paths, core dumps..)
cd /
umask 077
# mysqladmin likes to read /root/.my.cnf. This is usually not what I want
# as many admins e.g. only store a password without a username there and
# so break my scripts.
export HOME=/etc/mysql/
## Fetch a particular option from mysql's invocation.
#
# Usage: void mariadbd_get_param option
mariadbd_get_param() {
/usr/sbin/mariadbd --print-defaults \
| tr " " "\n" \
| grep -- "--$1" \
| tail -n 1 \
| cut -d= -f2
}
## Do some sanity checks before even trying to start mariadbd.
sanity_checks() {
# check for config file
if [ ! -r /etc/mysql/my.cnf ]; then
log_warning_msg "$0: WARNING: /etc/mysql/my.cnf cannot be read. See README.Debian.gz"
echo "WARNING: /etc/mysql/my.cnf cannot be read. See README.Debian.gz" | $ERR_LOGGER
fi
# check for diskspace shortage
datadir=`mariadbd_get_param datadir`
if LC_ALL=C BLOCKSIZE= df --portability $datadir/. | tail -n 1 | awk '{ exit ($4>4096) }'; then
log_failure_msg "$0: ERROR: The partition with $datadir is too full!"
echo "ERROR: The partition with $datadir is too full!" | $ERR_LOGGER
exit 1
fi
}
## Checks if there is a server running and if so if it is accessible.
#
# check_alive insists on a pingable server
# check_dead also fails if there is a lost mariadbd in the process list
#
# Usage: boolean mariadbd_status [check_alive|check_dead] [warn|nowarn]
mariadbd_status () {
ping_output=`$MYADMIN ping 2>&1`; ping_alive=$(( ! $? ))
ps_alive=0
pidfile=`mariadbd_get_param pid-file`
if [ -f "$pidfile" ] && ps `cat $pidfile` >/dev/null 2>&1; then ps_alive=1; fi
if [ "$1" = "check_alive" -a $ping_alive = 1 ] ||
[ "$1" = "check_dead" -a $ping_alive = 0 -a $ps_alive = 0 ]; then
return 0 # EXIT_SUCCESS
else
if [ "$2" = "warn" ]; then
echo -e "$ps_alive processes alive and '$MYADMIN ping' resulted in\n$ping_output\n" | $ERR_LOGGER -p daemon.debug
fi
return 1 # EXIT_FAILURE
fi
}
#
# main()
#
case "${1:-''}" in
'start')
sanity_checks;
# Start daemon
log_daemon_msg "Starting MariaDB database server" "mariadbd"
if mariadbd_status check_alive nowarn; then
log_progress_msg "already running"
log_end_msg 0
else
# Could be removed during boot
test -e /run/mysqld || install -m 755 -o mysql -g root -d /run/mysqld
# Start MariaDB!
/usr/bin/mysqld_safe "${@:2}" 2>&1 >/dev/null | $ERR_LOGGER &
for i in $(seq 1 "${MYSQLD_STARTUP_TIMEOUT:-30}"); do
sleep 1
if mariadbd_status check_alive nowarn ; then break; fi
log_progress_msg "."
done
if mariadbd_status check_alive warn; then
log_end_msg 0
# Now start mysqlcheck or whatever the admin wants.
output=$(/etc/mysql/debian-start)
if [ -n "$output" ]; then
log_action_msg "$output"
fi
else
log_end_msg 1
log_failure_msg "Please take a look at the syslog"
fi
fi
;;
'stop')
# * As a passwordless mysqladmin (e.g. via ~/.my.cnf) must be possible
# at least for cron, we can rely on it here, too. (although we have
# to specify it explicit as e.g. sudo environments points to the normal
# users home and not /root)
log_daemon_msg "Stopping MariaDB database server" "mariadbd"
if ! mariadbd_status check_dead nowarn; then
set +e
shutdown_out=`$MYADMIN shutdown 2>&1`; r=$?
set -e
if [ "$r" -ne 0 ]; then
log_end_msg 1
[ "$VERBOSE" != "no" ] && log_failure_msg "Error: $shutdown_out"
log_daemon_msg "Killing MariaDB database server by signal" "mariadbd"
killall -15 mariadbd
server_down=
for i in `seq 1 600`; do
sleep 1
if mariadbd_status check_dead nowarn; then server_down=1; break; fi
done
if test -z "$server_down"; then killall -9 mariadbd; fi
fi
fi
if ! mariadbd_status check_dead warn; then
log_end_msg 1
log_failure_msg "Please stop MariaDB manually and read /usr/share/doc/mariadb-server-10.5/README.Debian.gz!"
exit -1
else
log_end_msg 0
fi
;;
'restart')
set +e; $SELF stop; set -e
shift
$SELF start "${@}"
;;
'reload'|'force-reload')
log_daemon_msg "Reloading MariaDB database server" "mariadbd"
$MYADMIN reload
log_end_msg 0
;;
'status')
if mariadbd_status check_alive nowarn; then
log_action_msg "$($MYADMIN version)"
else
log_action_msg "MariaDB is stopped."
exit 3
fi
;;
'bootstrap')
# Bootstrap the cluster, start the first node
# that initiates the cluster
log_daemon_msg "Bootstrapping the cluster" "mariadbd"
$SELF start "${@:2}" --wsrep-new-cluster
;;
*)
echo "Usage: $SELF start|stop|restart|reload|force-reload|status"
exit 1
;;
esac
I stand corrected.
Yes 5 * means 5 wildcards, so it will run whenever cron checks, which is presumably once every minute.
When do you actually want this cron job to repeat?
The five * you have at the beginning are where you should put the date/time info.
minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-7, Sat=6, or mon..sun).
A * is used where that position is not specified. So five * means you haven't set a time/date at all.
As an example here is the mdadm job in my /etc/cron.d/
# cron.d/mdadm -- schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft <madduck@madduck.net>
# distributed under the terms of the Artistic Licence 2.0
#
# 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).
# time reset on grendel to 11:57 as more likely to be awake
57 11 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
If you look at the dependencies: GUFW depends on UFW, UFW depends iptables, iptables depends on nftables.
As, at this stage you only want a basic firewall, can I suggest you just install the nftables deb and a simple /etc/nftables.conf to specify the basic rules? Don't reinstall the others.
If you install nftables there are a number of example configurations including one for a simple workstation at /usr/share/doc/nftables/examples/workstation.nft. As root, copy this to /etc/nftables.conf.
This file contains the following:
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
# accept any localhost traffic
iif lo accept
# accept traffic originated from us
ct state established,related accept
# activate the following line to accept common local services
#tcp dport { 22, 80, 443 } ct state new accept
# accept neighbour discovery otherwise IPv6 connectivity breaks.
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
# count and drop any other traffic
counter drop
}
}
You should then check that nftables is enabled and running.
sudo service nftables status
If it is then it should also automatically start when the system is booted and provide a firewall.
You can turn it off and on with:
sudo service nftables stop
sudo service nftables start
Going beyond a simple firewall you might then need to open ports in the the firewall for specific services (syntax as in line 16, currently commented out). e.g open port 22 for tcp if you want to be able to ssh into the machine.
On my PC I also open ports to allow my Brother printer access for scanning and printing and to get system time (from, in my case, chrony).
In these cases I also lock down the IP of the machine(s) that can access the port.
Unfortunately I've not found a simple nftables front-end to replace gufw
GUFW has used nftables as the backend by default since beowulf: https://www.debian.org/releases/buster/ … l#nftables
Use the alternatives system to switch between iptables & nftables: https://wiki.debian.org/nftables#Revert … cy_xtables
Yes I know that the default in Beowulf (and Chimaera) is that iptables uses the nft kernal backend, but it still uses iptables syntax. This is how my own PC is set up with ufw/gufw.
I think (and I may be wrong about this) is that gufw only uses and accepts iptables syntax rules on top of the translation layer iptables-nft.
If you just want to use nftables then you just put your nftables syntax rules in /etc/nftables.conf and you could probably get rid of the iptables packages which are installed by default.
It's not a universal problem on Chimaera as on my PC ufw does work OK under Chimaera/sysvinit (upgraded from Beowulf, where it also worked), obviously using the iptables compatibility layer (which is the default).
In /var/log/boot I get:
Sat Mar 28 13:36:57 2020: [....] Starting Setting kernel variables: sysctl??7[ ok 8??.
Sat Mar 28 13:36:57 2020: [....] Starting firewall: ufw...Setting kernel variables (/etc/ufw/sysctl.conf)...??7[ ok 8??done.
Sat Mar 28 13:36:57 2020: [....] Configuring network interfaces...??7[ ok 8??done.
Sat Mar 28 13:36:57 2020: [....] Cleaning up temporary files...??7[ ok 8??.
Sat Mar 28 13:36:57 2020: [....] Setting up ALSA...??7[ ok 8??done.
Sat Mar 28 13:36:57 2020: [....] Setting sensors limits...??7[ ok 8??done.
Sat Mar 28 13:36:58 2020: [....] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix??7[ ok 8??.
Sat Mar 28 13:36:58 2020: INIT: Entering runlevel: 2
This suggest there is something specific in your setup that's triggering the error.
Are you using UFW in default mode or have you added rules?
What output do you get if you run:
sudo service ufw start
Have you tried reinstalling ufw and iptables?
On my mail server I set it up to use nftables when it was on Beowulf (now upgraded to Chimaera) and that also works. Unfortunately I've not found a simple nftables front-end to replace gufw though the nftables syntax is not that difficult.
May or may not be related.
I recently built a new PC powered by an AMD5600G CPU/GPU. As the motherboard (MSI MPG MS-7C56 1.0) had a newish sensor chip (nct6687-isa-0a20) on it I couldn't get fan rpm readings from using the standard Chimaera kernel 5.10. So I installed the newest kernel 5.16 from backports.
Although I could then see my fan speed data in sensors it completely mucked up suspend/resume that either didn't work at all (just got a lock screen when invoked) or even more annoyingly on a reboot failed to find the resume swap partition and hung for a long time before telling me it couldn't find it and asking if I wanted to just boot. Initially I thought this might be due to my using a swap partition on my RAID1 SSDs, however pointing grub to a normal swap partition didn't help.
However downgrading to 5.15 seems to have partly solved the suspend/resume issue (no longer hangs for swap file error on reboot, but suspend still only works intermittently) but it still recognises the motherboard sensor.
So it seems there is a suspend/resume regression in 5.16 on some systems at least.
Shift-PageUp / Shift-PageDown also works in gnome terminal (Cinnamon - Chimaera).
My unattended-upgrades installed a new version of zlib1g:amd64 (1:1.2.11.dfsg-2+deb11u1) from Chimaera-security this morning. This is the zlib runtime.
https://security-tracker.debian.org/tra … ckage/zlib say this is the patched version and say it is no longer vulnerable. Both Buster and Bullseye have now been patched.
It has been fixed in Debian for Bookworm and Sid (in zlib 1:1.2.11.dfsg-4).
Stretch, Buster and Bullseye have yet to be fixed.
https://security-tracker.debian.org/tra … ckage/zlib
I expect it will be fixed shortly in the remaining versions and all pulled into the Devuan repositories shortly thereafter.
For now stable and older remain vulnerable and can't yet be updated.
Try this line instead in /etc/default/grub (and of course then run update-grub).
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=7ade7026-f504-4f6e-a768-105e4a93b05e"
This is how I specify a swap partition for hibernation.
The change to your error message when you tried to do this with incorrect syntax confirms that your PC is attempting to hibernate not suspend.
It's unclear why this is happening (doesn't happen on mine unless I ask for hibernation).
Have already tried
sudo /usr/sbin/pm-suspend
to get suspend?
On my PC I have put /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate in /etc/sudoers.d/Suspend to allow me to run it passwordless.
username ALL = NOPASSWD: /usr/sbin/pm-hibernate
username ALL = NOPASSWD: /usr/sbin/pm-suspend
I then have these as options, along with Quit, Restart, Logout and Screenlock in a panel applet 'Shutdown Menu with Icons'. However this is under Cinnamon not XFCE.
migf, your last syslog listing relates to hibernating (to disk), not suspending to memory.
Have you specified the swap partition where you are saving the hibernation image?
On the linux /boot/vmlinuz-5.10.0-12-amd64 line in your /boot/grub/grub-cfg you need an entry such as resume=UUID=1e9fb381-0966-401f-b649-7958a6df7307. Obviously the UUID for the swap area you use will be different on your PC to the one I use on mine.
[edit] If the system is hibernating and you really just want it to suspend then you need to track down where PM is making the 'wrong' call.
You only need nvidia-persistenced if you are running CUDA.
I never did get to the bottom of the inability of Evolution to get a lock on the /var/mail/marjorie Mbox folder after the Chimaera upgrade.
However I have solved the problem, by moving my local mail from Mbox to Maildir format and configuring Postfix, Mutt and Evolution to use it. As it stores individual emails in separate files, Maildir doesn't need file locking.
As a mail storage solution Mbox is of course obsolete, however it was what was installed, I think by default, when I first installed Ascii and at that point it did work with both Evolution and Mutt without the file locking issues so I never bothered to change it.
Converting to Maildir was pretty simple, once I had tracked down how to do it.
However I remain a bit puzzled why the Debian/Devuan installation defaults local mail to use mbox.