Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

META | Add script for distro upgrade to Bookworm #6103

Merged
merged 10 commits into from
Jan 30, 2023
Merged

META | Add script for distro upgrade to Bookworm #6103

merged 10 commits into from
Jan 30, 2023

Conversation

MichaIng
Copy link
Owner

@MichaIng MichaIng commented Jan 26, 2023

Use with caution, this can always go badly wrong and destroy your system! At best do a full system drive clone and use the offer to create a dietpi-backup when on production system.

However, we are happy for everyone testing it, so we can add more fixes and migration required for software configs, package changes etc, to make this script safer to use for future users.

Currently, for a successful PHP migration, you need to move to DietPi dev branch as well.

G_DEV_BRANCH dev
bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-bookworm-upgrade')"

Bookworm support and testing status: https://github.com/MichaIng/DietPi/wiki/Debian-Bookworm-testing

Best if you just want to test Bookworm, is to flash a Bookworm image freshly: https://dietpi.com/downloads/images/

@Joulinar
Copy link
Collaborator

Joulinar commented Jan 27, 2023

ok did some testing:

  • "empty" systems
    ✅ RPi 3B+ 32bit ARMv7
    ✅ RPi 4B 64bit ARMv8
    ✅ NanoPi R5S
    ✅ NanoPi R6S (already on Bookworm, was correctly detected 😉 )

One point we need to consider, the failed to connect to bus message on reboot. Something to be fixed or hide.

  • typical software installed
    ✅ RPi 4B 64bit ARMv8 (all *arr services)
    ✅ NanoPi R5S (Home Assistant)
    ❌ RPi 3B+ 32bit ARMv7 (NextCloud)
    reinstall on PHP 8.1 packages is failing. We would need to adjust our install script to PHP 8.2 in generall 😉
[FAILED] DietPi-Software | APT install for: php8.1-fpm php8.1-apcu php8.1-curl php8.1-gd php8.1-mbstring php8.1-xml php8.1-zip php8.1-mysql php8.1-redis

And NC 25 don't like PHP 8.2. There is a warning about incompatibility at the end of the reinstall process.

As a last step, we force a software reinstall of selected software title. There you will be asked to run a backup (again), next to the one executed before Bookworm upgrade. In most cases this will overwrite the initial Bullseye backup with Bookworm. If things go wrong on reinstall, you will not be able to restore to a point before the upgrade. Just as an idea: would it make sense to skip the second backup?

@Joulinar
Copy link
Collaborator

Joulinar commented Jan 27, 2023

Some more test. My R5S was booting to fast leading to a conflict during login. Because on first login after upgrade, we force the autopurge which might run into a started apt package check. We might need to disable the apt package check on this initial first login after Bookworm upgrade. 🤔

[ INFO ] Autoremoving leftover packages from Bookworm upgrade...
[ INFO ] APT autopurge, please wait...
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1211 (apt-get)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
[FAILED] APT autopurge
 - Command: apt-get -y autopurge

EDIT:
OK might be a user issue. I had 2 sessions open reconnecting automatically same time, leading to two concurrent executions of the autopurge step. 🙄

@MichaIng
Copy link
Owner Author

reinstall on PHP 8.1 packages is failing. We would need to adjust our install script to PHP 8.2 in generall 😉

Already done on dev 😉.

And NC 25 don't like PHP 8.2. There is a warning about incompatibility at the end of the reinstall process.

I added a patch in dev to make it compatible with PHP 8.2. There are some deprecation warnings, but otherwise it works fine (running my home server like this).

@MichaIng
Copy link
Owner Author

OK might be a user issue. I had 2 sessions open reconnecting automatically same time, leading to two concurrent executions of the autopurge step. 🙄

Two things to enhance:

  1. Skip step if non-root user is logging in
  2. Remove script before running autopurge, so it cannot be called concurrently

@MichaIng MichaIng force-pushed the bookworm branch 2 times, most recently from b4bea39 to 3b438e5 Compare January 28, 2023 13:32
@Joulinar
Copy link
Collaborator

actually it's failing right at the beginning

[ INFO ] DietPi-Update | APT update -f, please wait...
E: Command line option 'f' [from -f] is not understood in combination with the other options.
[FAILED] DietPi-Update | APT update -f
 - Command: apt-get -y -eany update -f

@MichaIng
Copy link
Owner Author

Transition freeze for Bookworm btw. has happened at schedule: https://lists.debian.org/debian-devel-announce/2023/01/msg00004.html

What I missed is that this (reasonably) does not stop in-progress transitions, which was true for PHP (8.1 => 8.2) and Python (3.10 => 3.11). Both transitions have now been completed, so both can now be tested reasonably:

  • Test all PHP applications with PHP 8.2 on Bookworm
  • Test all Python applications with Python 3.11 on Bookworm

In case of Python, ARMv6/7 need a special eye on, since piwheels does not ship wheels for Bookworm/Python 3.11 yet. Since the version is now however fixed, I'll check back with the piwheels maintainers whether support can be added already now, to allow early testing and smooth upgrades. Of course this adds significant additional load to their build servers, for probably a small audience.

@Joulinar
Copy link
Collaborator

ahh and I cancelled the install on the issue above. However the process continued

[FAILED] DietPi-Update | Unable to continue, DietPi-Update will now terminate.
[ INFO ] dietpi-bookworm-upgrade | Updating package lists
[  OK  ] dietpi-bookworm-upgrade | sed -i s/bullseye/bookworm/g /etc/apt/sources.list
[ INFO ] dietpi-bookworm-upgrade | Reverting some package lists which have no Bookworm suite
[  OK  ] dietpi-bookworm-upgrade | sed -i s/bookworm/bullseye/ /etc/apt/sources.list.d/raspi.list

@MichaIng
Copy link
Owner Author

Ah I see the issue.

@Joulinar
Copy link
Collaborator

Joulinar commented Jan 28, 2023

some more issues along the way

[  OK  ] dietpi-bookworm-upgrade | APT dist-upgrade
/boot/dietpi/func/dietpi-globals: line 25: unset: G_PROGRAM_NAME: cannot unset: readonly variable
[  OK  ] dietpi-bookworm-upgrade | Congratulations, you are now on Bookworm:
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
[ INFO ] dietpi-bookworm-upgrade | Running post upgrade migrations

and one more for a NC/Apache2 system

[ INFO ] dietpi-bookworm-upgrade | Running post upgrade migrations
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : apache2
[  OK  ] DietPi-Services | stop : mariadb
[  OK  ] DietPi-Services | stop : redis-server
[  OK  ] dietpi-bookworm-upgrade | Setting in /root/.ssh/known_hosts adjusted: [ssh.dietpi.com]:29248 ssh-ed25519 AAAA
[FAILED] dietpi-bookworm-upgrade | a2dismod php7.4
 ERROR: Module php7.4 does not exist!

@Joulinar
Copy link
Collaborator

Joulinar commented Jan 28, 2023

After the upgrade NC is not working/ running due to PHP8.2

This version of Nextcloud is not compatible with PHP>=8.2.
You are currently running 8.2.1.

@MichaIng
Copy link
Owner Author

MichaIng commented Jan 28, 2023

Both issues fixed. One test I need to do:

  • We use PHP-FPM since a while for Apache as well, so mod_php is not installed, which is why the command fails.
  • We did however not enforce the transition. It was applied on reinstall only.
  • So I need to test whether the module gets disabled automatically when the libapache2-mod-php7.4 package is purged. It actually should be. This would render the step as well redundant on Buster => Bullseye upgrade.
    EDIT: Yes, it is redundant.

@StephanStS
Copy link
Collaborator

Did some tests with Proxmox-VMs:

  • Basic console VM: ✅

  • VM with node-red, NGINX, PHP, NFS client: ✅

  • VM with X11 (Xfce): ✅

  • VM with Plex Media Server: ✅

  • VM with Nextcloud: ❌
    image
    (I keep it at this state for further investigations)

  • VM with MQTT Server: ✅

  • VM with X11 (Xfce) and many office applications (XSane, OpenOffice,...): ✅

  • VM with X11 (Xfce) and many development applications (VSCodium, GitHub Desktop, KeePassXC, Atom, Firefox,...): ✅

  • LXC container: ✅

I had only minor issues that sometimes apt update etc. hangs, a "retry" option of the scripts always helped.

@MichaIng
Copy link
Owner Author

@StephanStS
Awesome, thanks for the many tests. On the failing Nextcloud reinstall, can you check the Redis service logs:

journalctl -u redis-server

@Joulinar
Copy link
Collaborator

Joulinar commented Jan 28, 2023

tested NC/ Apache2 on RPi 64bit again. Except one issue, it's working fine.

[  OK  ] dietpi-bookworm-upgrade | APT dist-upgrade
/boot/dietpi/func/dietpi-globals: line 25: unset: G_PROGRAM_NAME: cannot unset: readonly variable
[  OK  ] dietpi-bookworm-upgrade | Congratulations, you are now on Bookworm:

@MichaIng
Copy link
Owner Author

/boot/dietpi/func/dietpi-globals: line 25: unset: G_PROGRAM_NAME: cannot unset: readonly variable

Good catch. It's actually unnecessary to load dietpi-globals again. It's sufficient to reload only the hardware model info file.

@Joulinar
Copy link
Collaborator

Joulinar commented Jan 28, 2023

btw, do we really need to print /etc/os-release?

[  OK  ] dietpi-bookworm-upgrade | Congratulations, you are now on Bookworm:
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
[ INFO ] dietpi-bookworm-upgrade | Running post upgrade migrations

Personally, the congratulations message would be fine for me.

@MichaIng
Copy link
Owner Author

I thought it would be a nice verification. It was in the Bullseye upgrade guide, so I added it. But if you think it is unnecessary, we can remove it.

@Joulinar
Copy link
Collaborator

We can check with @StephanStS and Holger. At the end it is visual only, somewhere within the package update and reinstall phase.

@MichaIng
Copy link
Owner Author

MichaIng commented Jan 28, 2023

You are right, the script moves on, so not much time to see this anyway. I thought about adding some halts to give time reviewing what has been done so far. E.g. after the upgrade itself:

read -rp 'Next, some migrations are done for all software to run nicely on Bookworm. This can include dietpi-software reinstalls. Press any key to continue ...'

Benefit compared to a whiptail is that you see and can review the above console output.

@StephanStS
Copy link
Collaborator

StephanStS commented Jan 29, 2023

Did some tests with Proxmox-VMs:

  • Basic console VM: ✅

  • VM with node-red, NGINX, PHP, NFS client: ✅

  • VM with X11 (Xfce): ✅

  • VM with X11 (Cinnamon): ✅

  • VM with X11 (Many GUIs, like Xfce, LXDE, LXQt, MATE, KDE Plasma, GNOME, Cinnamon, Budgie, Enlightenment): ✅

  • VM with Plex Media Server: ✅
    @MichaIng : There was a minor issue with the automated reinstall (but only with this VM)

    [ INFO ] DietPi-Software | 180: Bazarr is not currently installed
    [ INFO ] DietPi-Software | Use "dietpi-software install 180" to install Bazarr.
    [  OK  ] DietPi-Software | No changes applied for: Bazarr
    Failed to connect to bus: No such file or directory
    

    But the following reboot and finalizing update worked fine.

  • VM with Nextcloud: (First ❌), now ✅
    image
    (I keep it at this state for further investigations)

  • VM with MQTT Server: ✅

  • VM with X11 (Xfce) and many office applications (XSane, OpenOffice,...): ✅

  • VM with X11 (Xfce) and many development applications (VSCodium, GitHub Desktop, KeePassXC, Atom, Firefox,...): ✅

  • LXC container: ✅

I had only minor issues that sometimes apt update etc. hangs, a "retry" option of the scripts always helped.

@StephanStS Awesome, thanks for the many tests. On the failing Nextcloud reinstall, can you check the Redis service logs:

journalctl -u redis-server

grafik

@MichaIng MichaIng merged commit 898b5ec into dev Jan 30, 2023
@MichaIng MichaIng deleted the bookworm branch January 30, 2023 21:24
@MichaIng MichaIng requested a review from ravenclaw900 January 30, 2023 21:25
@lukaszsobala
Copy link
Contributor

My upgrade on rpi zero 2w went well. Now testing on raspberry pi 4 with more things installed.

One question - after the upgrade is successful, can we change the branch back to stable releases? Or is dev needed for PHP to work at all?

@Joulinar
Copy link
Collaborator

you can change back to master without issue

@lukaszsobala
Copy link
Contributor

lukaszsobala commented Mar 27, 2023

Thanks. The script worked fine for Raspberry Pi 4 too.

There's one thing that might have not been as you wished: I executed the script inside screen, detached it and logged out. In the meantime it completed. When I connected via ssh again, the autopurge was automatic and it happened before the reboot. I then did screen -r and rebooted (no problems ensued).

Also, nextcloud works, I just needed to run dietpi-letsencrypt to upgrade the certificate from rsa to the new standard. Then I could use the included updater to update it to version 26.

@Joulinar
Copy link
Collaborator

yes the package will get cleaned on next root login. Maybe @MichaIng has an idea if we need to verify if a reboot already happened or not. 🤔

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 27, 2023

Because on x86_64 systems (respectively if the Debian kernel package is used) the autoremoval would purge the currently loaded kernel as well, which isn't optimal if you do not reboot soon, since it is then impossible to load kernel modules. There may be other cases of packages which are currently used and would be purged. So it is generally saver to do autoremoval after a reboot.

That another login does autoremoval already is indeed unintended, but I have no suitable idea for assuring that it is done only after a reboot, without making it too complex. We just use a login script.

What do you think about doing the autoremoval immediately but enforcing the reboot instead? If someone does a distribution upgrade, it is unlikely that a reboot is a problem or unwanted, and in case anything important needs to be saved or so, another SSH session can be used before hitting Ok.

EDIT:

can we change the branch back to stable releases?

Do you mean DietPi or Debian?

The DietPi branch is not changed with the distro upgrade. Debian can only be changed back by restoring the backup. Downgrading a Bookworm system (meaning downgrading each upgraded DEB package) to Bullseye is practically impossible.

@lukaszsobala
Copy link
Contributor

lukaszsobala commented Mar 27, 2023

Do you mean DietPi or Debian?

Ah yes, I meant DietPi.

As for doing the autopurge after a reboot, I think there's an easy way.
At the beginning of the script you can get the last entry from
journalctl --list-boots

(actually, something like this: journalctl --list-boots |tail -n 1|awk -F ' ' '{print $2}')

And enforce the autopurge only if it's different. By default on dietpi there are no boots other than the current one in the journal, but the boot ID should still be different, no?

Cheers

@MichaIng
Copy link
Owner Author

Not a bad idea. The other option would be to just use /var/lib/dietpi/postboot.d. Downside is that it cannot be watched via SSH session but only on attached screen, if any. But I'm wondering whether its worth it or whether enforcing the reboot makes sense anyway.

@Joulinar
Copy link
Collaborator

question is how many people will run the update within unattended mode? I guess majority will do it online and reboot the system right after update. Personally, I would not go with an automated reboot. Maybe there are information people like to capture before reboot.?? Or we need to pass the whole update log into a file to have information available afterwards still.

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 27, 2023

Ah I didn't mean to do the reboot automatically, but to not give the choice to hit "Cancel". I'd change it into a read -rp ...text... so that one can easily scroll up and review the recent output and then reboot on return/enter. Hitting CTRL+C would still be possible to abort the script and hence skip the reboot, but I wouldn't print that as part of the text.

A completely automated upgrade is anyway not possible due to the read -rp that is done already after the package upgrades and before config/software migrations.

@lukaszsobala
Copy link
Contributor

@Joulinar I tend to execute high-risk stuff inside screen even if it's attended because the command will still run even if my ssh session gets disconnected. Had this happen a few times so I learned.

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 27, 2023

I think all three of us are running GNU Screen in SSH session by default 😉. But there is a difference between watching the screen the whole time or going for a coffee in between and check back by times if it has finished or input is needed. I think it is good to have those two required inputs to give time for/encourage users reviewing the output, especially before doing the reboot.

@lukaszsobala
Copy link
Contributor

lukaszsobala commented Mar 28, 2023

I also think that the archive.raspberrypi.org repository did not get updated to bookworm, is this by design? They have a bookworm release now.

Hit:1 https://download.docker.com/linux/debian bookworm InRelease
Hit:2 https://deb.debian.org/debian bookworm InRelease
Hit:3 https://archive.raspberrypi.org/debian bullseye InRelease
Hit:4 https://deb.debian.org/debian bookworm-updates InRelease
Hit:5 https://deb.debian.org/debian-security bookworm-security InRelease
Hit:6 https://deb.debian.org/debian bookworm-backports InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: https://archive.raspberrypi.org/debian/dists/bullseye/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details

@MichaIng
Copy link
Owner Author

They have a bookworm release now.

But it is empty 😉:

@churchofnoise
Copy link

churchofnoise commented Apr 13, 2023

As mentioned on the DietPi forum, ran the script after migrating to dev branch (from beta) on a x86-64 system running Home Assistant.

All is running very well (and even snappier than before), yet sudo reboot results in this:

Failed to set wall message, ignoring: Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists
Call to Reboot failed: Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists

(same message appeared at the end of running the script after I'd been asked if I wanted to reboot, which I confirmed). Any ideas?

@Joulinar
Copy link
Collaborator

Joulinar commented Apr 13, 2023

dbus messages a little bit as expected on Bookworm as we don't install dbus package by default. Something we still thinking of how to avoid that message. But your system is performing the reboot?

@MichaIng
Copy link
Owner Author

Yes it want's to de-register the session with systemd-logind which is not used by default on DietPi. Maybe we find a way that it tries this only if the service is actually active.

@churchofnoise
Copy link

Thanks for the info!
It does indeed reboot properly, so functionally all is well.

@kel-mo
Copy link

kel-mo commented May 11, 2023

Apt after the upgrade:

# apt update
Hit:1 https://download.docker.com/linux/debian bookworm InRelease
Hit:2 https://deb.debian.org/debian bookworm InRelease
Hit:3 https://deb.debian.org/debian bookworm-updates InRelease
Hit:4 https://deb.debian.org/debian-security bookworm-security InRelease
Hit:5 https://deb.debian.org/debian bookworm-backports InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
N: Repository 'Debian bookworm' changed its 'non-free component' value from 'non-free' to 'non-free non-free-firmware'
N: More information about this can be found online in the Release notes at: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.html#non-free-split

Required change:

# sed -i 's/non-free/non-free non-free-firmware/' /etc/apt/sources.list

@MichaIng
Copy link
Owner Author

MichaIng commented May 11, 2023

Good point! We do this already for fresh Bookworm images, when the APT mirror is changed on a Bookworm system or when a Bookworm system is upgraded from an older DietPi version: https://github.com/MichaIng/DietPi/blob/0423238/dietpi/func/dietpi-set_software#L135-L136

But indeed in this script it is missing. Will add it.
EDIT: 8d54e0e

@Trimble-tech
Copy link

After testing it virtually, I ran this script on my Bullseye system and it worked well; I am now using Bookworm and my apps are up and running. The only thing I noticed is the Nginx config file ( /etc/nginx/sites-available/default ) changed which disabled my self-signed certs. I pulled my old file from the backup and moved it in place, renaming the new file. Aside from this everything went off without a hitch. Thanks as always to the developers.

System Info:

  • Device: Raspberry Pi 4B 8GB
  • Dietpi Version: 8.21.-1 (manually changed from 8.21 before update)
  • Disks Used: 4TB Sata NAS HD (data), 1TB Sata SSD (boot) {both connected via USB3}
  • Logging: Full

Software Installed:

  • OpenSSH Client (0)
  • IPTraf (11)
  • Git (17)
  • Fail2Ban (73)
  • Nginx (85)
  • MariaDB (88)
  • PHP (89)
  • Redis (91)
  • Pi-Hole (93)
  • Logrotate (101)
  • Rsyslog (102)
  • OpenSSH Server (105)
  • Nextcloud (114)
  • Webmin (115)
  • PiVPN (117)
  • Python 3 (130)
  • Unbound (182)
  • Java JRE (196)
  • Homer (205)

Considering how many variables/software packages are on this system, I am impressed the update only needed one text file changed afterwards.

@MichaIng
Copy link
Owner Author

MichaIng commented Aug 8, 2023

Thanks for testing. Right, the Nginx installation is a little intrusive, overwriting /etc/nginx/nginx.conf and /etc/nginx/sites-available/default on every (re)install. We need to switch to using drop-in configs where possible and otherwise add or edit individual lines/blocks only.

However, generally I'd always advice to create an own file for each server block, like /etc/nginx/sites-available/ssl and then:

ln -s ../sites-available/ssl /etc/nginx/sites-enabled/ssl

@Smyl3
Copy link

Smyl3 commented Mar 23, 2024

After ran update script, system refused my SSH key with Putty. It turned out I had to update the Putty client that solved the issue.
It surprised that dietpi is still using the same old kernel with bookworm:
Linux zero2 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

@MichaIng
Copy link
Owner Author

The kernel is generally distro-version-agnostic. Implementing full support for the new set of kernel/firmware packages is in the works, but much to do. You can however migrate already: #6676

@Smyl3
Copy link

Smyl3 commented Mar 25, 2024

The kernel is generally distro-version-agnostic. Implementing full support for the new set of kernel/firmware packages is in the works, but much to do. You can however migrate already: #6676

Thanks. I see. It surprised me because I saw that for raspberry OS the new kernel is already available by apt upgrade if I right.
Since then I compiled a custom 6.6 kernel for Zero2W and bookworm with default enabled zswap, but I saw very heavy unresponsiveness regularly with wlan packet losses and dietpi-wifi-monitor.sh generated wlan reconnects which I see weird because I use 10s test timeout and 10 try attempts settings in dietpi-config. I tried to set swapiness to higher value than 1 and keep testing it.

@MichaIng
Copy link
Owner Author

The whole way where kernel and boot configs are stored, where the FAT partition is mounted, which graphics/camera drivers are supported etc have changed quite radically. You cannot just install the new APT packages over the old one, which is why we creates the migration script and give it some time for intense testing, as the process intrusive. Also a bunch of software options need to change or in cases be removed and the display and camera settings provided by our scripts reworked. This ia much work and we are a small team. This is by far the largest change RPi Ltd. has ever done to their kernel/firmware packages, so it is not just the kernel upgrade from 6.1 to 6.6 which would be trivial (and can be done with a custom build or rpi-update indeed, but leaving everything else at legacy setup).

Ia your RPi a mobile device moving from one AP to another? If it has just a little flaky WiFi connection but is otherwise stationary connected to the same AP, the WiFi monitor is not suitable. The connection would then usually be re-established much faster when just leaving it untouched. Also I cannot imagine this has anything to do with the kernel version.

@Smyl3
Copy link

Smyl3 commented Mar 28, 2024

Ia your RPi a mobile device moving from one AP to another? If it has just a little flaky WiFi connection but is otherwise stationary connected to the same AP, the WiFi monitor is not suitable. The connection would then usually be re-established much faster when just leaving it untouched. Also I cannot imagine this has anything to do with the kernel version.

Rpi is still at same location and on same 2.4GHz wifi network which is only one network, no repeater, nothing. Already tried to play with different wifi channels, reboot router, disable WMM etc.
It seems that the wifi connection will be a packet loss so DietPi-WiFi_Monitor service dropping the whole connection instantly without any tolerance in ping tests and init a reconnection. It can occur multiple times in few minutes even the ping times are low. I see that in logs with the stock 6.1.21-v8+ kernel and under bullseye either. So the connection test options in dietpi-config seems doesn't affect DietPi-WiFi_Monitor service itself.
I continue to test my router wifi stability either.
Edit: I didn't see any correlation with my other devices connection instability... I see nothing in logs, only DietPi-WiFi_Monitor service generated reconnects. Nor high cpu usage of any process at moment of connection drops.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants