-
-
Notifications
You must be signed in to change notification settings - Fork 502
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
Conversation
ok did some testing:
One point we need to consider, the
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? |
Some more test. My R5S was booting to fast leading to a conflict during login. Because on first login after upgrade, we force the
EDIT: |
Already done on
I added a patch in |
Two things to enhance:
|
b4bea39
to
3b438e5
Compare
actually it's failing right at the beginning
|
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:
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. |
ahh and I cancelled the install on the issue above. However the process continued
|
Ah I see the issue. |
some more issues along the way
and one more for a NC/Apache2 system
|
After the upgrade NC is not working/ running due to PHP8.2
|
Both issues fixed. One test I need to do:
|
@StephanStS journalctl -u redis-server |
tested NC/ Apache2 on RPi 64bit again. Except one issue, it's working fine.
|
Good catch. It's actually unnecessary to load |
btw, do we really need to print
Personally, the congratulations message would be fine for me. |
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. |
We can check with @StephanStS and Holger. At the end it is visual only, somewhere within the package update and reinstall phase. |
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. |
Did some tests with Proxmox-VMs:
I had only minor issues that sometimes apt update etc. hangs, a "retry" option of the scripts always helped.
|
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? |
you can change back to master without issue |
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 Also, nextcloud works, I just needed to run |
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. 🤔 |
Because on 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:
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. |
Ah yes, I meant DietPi. As for doing the autopurge after a reboot, I think there's an easy way. (actually, something like this: 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 |
Not a bad idea. The other option would be to just use |
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. |
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 A completely automated upgrade is anyway not possible due to the |
@Joulinar I tend to execute high-risk stuff inside |
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. |
I also think that the
|
But it is empty 😉: |
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:
(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? |
|
Yes it want's to de-register the session with |
Thanks for the info! |
Apt after the upgrade:
Required change:
|
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. |
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 ( System Info:
Software Installed:
Considering how many variables/software packages are on this system, I am impressed the update only needed one text file changed afterwards. |
Thanks for testing. Right, the Nginx installation is a little intrusive, overwriting However, generally I'd always advice to create an own file for each server block, like ln -s ../sites-available/ssl /etc/nginx/sites-enabled/ssl |
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. |
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. |
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 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. |
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/