[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-cvs] [477] Add specific items post-upgrade

From: bob
Subject: [Savannah-cvs] [477] Add specific items post-upgrade
Date: Mon, 11 Jul 2022 14:33:42 -0400 (EDT)

Revision: 477
Author:   rwp
Date:     2022-07-11 14:33:41 -0400 (Mon, 11 Jul 2022)
Log Message:
Add specific items post-upgrade

Must verify sshd_config.  Must verify cryptsetup-initramfs installed.

Modified Paths:

Modified: trunk/sviki/BobsGuideToSystemUpgrades.mdwn
--- trunk/sviki/BobsGuideToSystemUpgrades.mdwn  2022-06-25 22:36:47 UTC (rev 
+++ trunk/sviki/BobsGuideToSystemUpgrades.mdwn  2022-07-11 18:33:41 UTC (rev 
@@ -899,6 +899,10 @@
 Post Upgrade Clean-Up
+WARNING!  Do not reboot immediately!  There are a few items that need
+to be fixed up as soon as possible!  Definitely required before
 Since we have instructed dpkg to install the new conffiles and save
 the locally modifed ones to ".dpkg-old" everywhere the first thing we
 need to do is to merge in changes.  And specifically to the most
@@ -906,13 +910,69 @@
 undoubtedly using for the upgrade.
     ls -l /etc/ssh/sshd_config*
+    -rw-r--r-- 1 root root 3207 Dec 29  2021 /etc/ssh/sshd_config
+    -rw-r--r-- 1 root root 3207 Dec 29  2021 /etc/ssh/sshd_config.dpkg-old
     emacs /etc/ssh/sshd_config*
+    ...merge local customizations from the old file to the new...
     service ssh restart || systemctl restart ssh.service
-Examine the old file.  Merge in any local changes from there to the
-new sshd_config file.  Restart ssh.  Verify that login using it is
-still possible.
+Examine the old `sshd_config.dpkg-old` file.  Merge in any local
+changes from there to the new sshd_config file.  Restart ssh.  Verify
+that login using it is still possible by logging in from a different
+terminal.  This is not as scary as I make it sound now.  The sshd
+defaults are back to something less scary.  For a while it was
+PermitRootLogin=no which might lock you out from logging in but now
+the default is PermitRootLogin=prohibit-password which allows ssh
+keys.  That's standard operating procedure for most systems.  So not
+so critical now as it was for at least one release.  In any case there
+likely will be other configuration needed to be merged.
+A specific item that is needed for the FSF VMs for an upgrade from
+Trisquel 9 to Trisquel 10 is this package cryptsetup-initramfs which
+needs to be installed.
+    cryptsetup-initramfs
+Originally the required files were in cryptsetup but that package is
+now split and the new version does not "Depends" upon the
+`cryptsetup-initramfs` package likely leaving the system upgraded
+without it installed.  The new package cryptsetup-initramfs is a
+"Recommends" only and isn't guaranteed to get installed.  It's needed
+with the current VM setup (isn't needed on the older VMs) in order to
+boot.  If upgrading one must ensure that `cryptsetup-initramfs` gets
+And less important is that for whatever reason the kernel symlinks
+did not track to the new kernel package.  That's quite odd.  I don't
+know why.  These links.
+    lrwxrwxrwx   1 root root   34 Dec  7  2021 initrd.img -> 
+    lrwxrwxrwx   1 root root   31 Dec  7  2021 vmlinuz -> 
+They were still pointing to the old, in this case version 4, kernels.
+Ian ran this manually to fix them up.
+    linux-update-symlinks install 5.4.0-121-generic
+    /boot/vmlinuz-5.4.0-121-generic
+    lrwxrwxrwx   1 root root    33 Jul  8 18:34 initrd.img -> 
+    lrwxrwxrwx   1 root root    30 Jul  8 18:34 vmlinuz -> 
+I'll watch for the next kernel upgrade and verify that they update
+at that time or not.  The current config file says this.
+    root@frontend1:~# cat /etc/kernel-img.conf
+    do_symlinks = yes
+    do_initrd = Yes
+    silent_modules=yes
+    clobber_modules=yes
+    link_in_boot = no
+All of the Rest
     find /etc \( -name '*.dpkg-*' -o -name '*.ucf-*' \) -print
 Review and merge each of those files.  Some of those services will be
@@ -941,6 +1001,23 @@
 other problems.  These are all upgrade bugs.  File an appropriate bug
 report for the problems found.
+The `adequate` package.
+If you are a "go-getter" and want to help the project out then the
+"adequate" package is there to make finding these problems easier.
+This is something to install before going through other installation
+and upgrades.  The adequate package will examine each install and
+upgrade and run checks against the package.  It will complain,
+interactively requiring an OK to continue, about problems in the
+packages it finds.  These might be obsolete conffiles, might be
+dangling symlinks, might be unresolved library symbols, or might be
+other things.  These are all packaging bugs and in a perfect world a
+bug report would get filed for each of them and each of these bugs
+would get fixed.  Because adequate is interactive this is not
+appropriate for fully automated installs and upgrades.  But it is
+useful for interactive upgrades to find and notify of packaging
@@ -948,6 +1025,13 @@
 to boot in order to run the newly installed kernel.  After rebooting
 run the system regression test suite.  Any failures?  Fix failures.
+This first reboot is best done with one of the FSF admins around as a
+guardian angel.  Because if it needs rescuing then it can only be done
+from the KVM side of things.  That is not accessible to the mere
+mortals out in the field.  Think about their time.  Don't do this late
+on a Friday before a long weekend!  Coordinate a good time during
+daylight hours in Boston when they can help if needed.
 Savannah external test suite.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]