Thre are three ways I can think of upgrading say from Mga7 to 8.

a) Wipe 7 and Install 8.
Avantage-- the system is liable to uniform, and bugs resulting from
mixes of 7 programs which did not get upgraded and 8 programs is
reduced
Disadvantage: Suddenly all of the configuration choices that were
made in 7 to get it to run as you want it (from crucial things like
/etc/passwrd and /etc/shadow to /etc/ssh/* or /etc/postfix choices,
to thousands of other programs) are not longer there. It has
typically taken me about a month of unproductive work to get the
system back to a useable state.

b) Upgrade in place from the cdrom/usb stick.
Advantage: most of the configurations remain in place, but sometimes
new programs dislike old configurations
Disadvantage: You still have to take down the machine in person to
install the new system. Ie, it cannot be done remotely.

c) Update by transfering a Mga8 /etc/urpmi/urpmi.cfg in, running
urpmi.update -a, and then urpmi --auto-select
Advantage: Again preserving configurations. But again the worry that
some names have changed sufficiently to not be updated (eg gimp
renamed to gimp2 and thus the update is invisible to the system)
It can be done remotely.

What are the other disadvnatages of the three choices? Any advice?

What about upgrading from Mga6 to 8. That lets out b) since Mageia
strongly advises not to do this. One could do b) (or c) from 6 to 7 and
then from 7 to 8. What would happen if one did c) for 6 to 8 directly?

I tried b) on one system, (about 4000 packages replaced) but an
frighted to start looking for the problems.

On Wed, 30 Mar 2022 00:07:19 -0400, William Unruh <unruh@invalid.ca> wrote:
> Thre are three ways I can think of upgrading say from Mga7 to 8.
> a) Wipe 7 and Install 8.
<snip>
> b) Upgrade in place from the cdrom/usb stick.
> c) Update by transfering a Mga8 /etc/urpmi/urpmi.cfg in, running
> urpmi.update -a, and then urpmi --auto-select
<snip>
> What are the other disadvnatages of the three choices? Any advice?

This is overlooking the most common method, initiating the upgrade using mgaapplet.
It's like option c above, but done without having to manually alter the urpmi.cfg
file.

There's also "urpmi.removemedia -a", followed by adding the media. That can be done
using urpmi.addmedia, as per
https://wiki.mageia.org/en/How_to_choose_the_right_Mageia_upgrade_method#How_to_do_a_simple_upgrade_in_text_mode

See that site in the wiki for the pros/cons of each.

> What about upgrading from Mga6 to 8. That lets out b) since Mageia
> strongly advises not to do this. One could do b) (or c) from 6 to 7 and
> then from 7 to 8. What would happen if one did c) for 6 to 8 directly?

The problem is that in an upgrade from 6 to 7 the packages in 7 have specific
obsoletes tags or other settings needed for that upgrade, and since the package
that's been obsoleted is no longer present in 7, then the packages in Mageia 8 is
unlikely to still have that obsoletes tag.

It may work, but it's highly unlikely to.

> I tried b) on one system, (about 4000 packages replaced) but an
> frighted to start looking for the problems.

The main thing that needs to be done after an upgrade, is picking out what changes
to allow/disallow in the rpmsave and rpmnew files in /etc/ or it's subdirectories.
Usually the upgrade makes the right choices, but each user may want different
choices.

Regards, Dave Hodgins

Op Wed, 30 Mar 2022 04:07:19 +0000, schreef William Unruh:

> Thre are three ways I can think of upgrading say from Mga7 to 8.
>
> a) Wipe 7 and Install 8.
> Avantage-- the system is liable to uniform, and bugs resulting from
> mixes of 7 programs which did not get upgraded and 8 programs is
> reduced Disadvantage: Suddenly all of the configuration choices that
> were made in 7 to get it to run as you want it (from crucial things
> like /etc/passwrd and /etc/shadow to /etc/ssh/* or /etc/postfix
> choices, to thousands of other programs) are not longer there. It has
> typically taken me about a month of unproductive work to get the
> system back to a useable state.

"Suddenly all of the configuration choices that
were made in 7 to get it to run as you want it (from crucial things
like /etc/passwrd and /etc/shadow to /etc/ssh/* or /etc/postfix
choices, to thousands of other programs) are not longer there"

That is true for system-wide configurations, like apache and passwords
and dns-server e.a. But "thousands of other programs" have user-level
configurations and these are not impacted by a clean installation,
provided you have /home on a separate partition. In some cases
configuration settings of a particular program are not 100% compatible
from version X to version X+1, but that might happen as well in a regular
package update within a MGA-version.

Regards

Herman Viaene

> b) Upgrade in place from the cdrom/usb stick.
> Advantage: most of the configurations remain in place, but sometimes
> new programs dislike old configurations Disadvantage: You still have
> to take down the machine in person to install the new system. Ie, it
> cannot be done remotely.
>
> c) Update by transfering a Mga8 /etc/urpmi/urpmi.cfg in, running
> urpmi.update -a, and then urpmi --auto-select
> Advantage: Again preserving configurations. But again the worry that
> some names have changed sufficiently to not be updated (eg gimp
> renamed to gimp2 and thus the update is invisible to the system)
> It can be done remotely.
>
> What are the other disadvnatages of the three choices? Any advice?
>
> What about upgrading from Mga6 to 8. That lets out b) since Mageia
> strongly advises not to do this. One could do b) (or c) from 6 to 7 and
> then from 7 to 8. What would happen if one did c) for 6 to 8 directly?
>
> I tried b) on one system, (about 4000 packages replaced) but an frighted
> to start looking for the problems.

On Wed, 30 Mar 2022 04:07:19 -0000 (UTC), William Unruh wrote:
> Thre are three ways I can think of upgrading say from Mga7 to 8.
>
> a) Wipe 7 and Install 8.
> Avantage-- the system is liable to uniform, and bugs resulting from
> mixes of 7 programs which did not get upgraded and 8 programs is
> reduced
> Disadvantage: Suddenly all of the configuration choices that were
> made in 7 to get it to run as you want it (from crucial things like
> /etc/passwrd and /etc/shadow

Yup, my passwd_changes script pulls all ids greater than 1499 to get
user id and passwords and cli commands to make other additional changes.

> to /etc/ssh/*

Yep, saw some keyword changes and had to modify my script based on version.

> or /etc/postfix choices,
> to thousands of other programs) are not longer there. It has
> typically taken me about a month of unproductive work to get the
> system back to a useable state.

Easily solved using configuration scripts and easy enough to code/debug/test
in a virtualbox guest.

> b) Upgrade in place from the cdrom/usb stick.
> Advantage: most of the configurations remain in place, but sometimes
> new programs dislike old configurations
> Disadvantage: You still have to take down the machine in person to
> install the new system. Ie, it cannot be done remotely.

Then c) would be better than b)

> c) Update by transfering a Mga8 /etc/urpmi/urpmi.cfg in, running
> urpmi.update -a, and then urpmi --auto-select
> Advantage: Again preserving configurations. But again the worry that
> some names have changed sufficiently to not be updated (eg gimp
> renamed to gimp2 and thus the update is invisible to the system)
> It can be done remotely.
>
> What are the other disadvnatages of the three choices? Any advice?

Create custom install/change scripts to run after clean installs.
$ dir install_* | wc -l
50

$ dir *_changes | wc -l
191

> What about upgrading from Mga6 to 8. That lets out b) since Mageia
> strongly advises not to do this. One could do b) (or c) from 6 to 7 and
> then from 7 to 8. What would happen if one did c) for 6 to 8 directly?
>
> I tried b) on one system, (about 4000 packages replaced) but an
> frighted to start looking for the problems.

That is where automating install helps. I have a change counter in
my scripts and if count is incorrect I can look at the script log and
config files to see what did not happen. I use the "script" command to
log script activity. Example:
scipt -c "new_install" new_install.log

Trust me, push redundant code into functions. build boiler plate/skeleton
scripts and it becomes dead easy to copy one into new change/install file
and start hacking away.

My current boiler plate/skeletons
$ ls *skel*
bash_skeleton skel_changes skeleton_sb_drop_in_changes
install_skeleton skeleton_changes skeleton_service_changes

Function includes in install_skeleton
. /local/bin/functions_path_app # set PATH and other common variables
. /local/bin/functions_xmsg # wrapper around xmessage
. /local/bin/functions_install # install functions
. /local/bin/functions_change # change functions.

$ grep function functions_install | grep -v '#'
function x_args ()
function x_urpmi ()
function x_urpme ()
function mount_rst ()
function umount_rst ()

$ grep function functions_change | grep -v '#'
function set_facl ()
function save_facl ()
function save_perms ()
function set_perms ()
function ck_vorig_dir()
function ck_vsave_dir()
function ck_rpmnew()
function cp_vsave_vinstal()
function cp_vinstall()
function cp_vorig()
function mv_vorig()
function restore_vinstall()
function restore_vorig()
function null_fn ()
function chg_check ()

I can recommend a change script for each file for a given app.
For postfix I have the different changes.

$ ls *post*
ck_postfix postfix_main_cf_changes
create_postfix_db postfix_make_changes
Makefile_postfix postfix_sasl_changes
post_conf postfix_sasl_passwd_bittwister
postfix_aa_init_changes postfix_sasl_passwd_grannys_account
postfix_aliases_changes postfix_sender_relay_changes
postfix_changes postfix_tls_policy_changes
postfix_cleanup postfix_transport_changes
postfix_generic_changes postfix_z_cleanup_changes
postfix_local_changes postfix_z_make_changes

postfix_changes snippet run all the change scripts
#*****************************************
#* main code start here
#*****************************************

progress "\n\t # Running $_exe "$_action"\n"

cd /etc/postfix

parse_cmd_line

#************************
#* run all change scripts
#************************

while read -r line ; do
$line "$_action"
done < <(ls -1 /local/bin/postfix_*_changes*)

systemctl stop postfix
sleep 2
systemctl start postfix

rm --force $_tmp_fn

progress "# Completed $_exe "$_action""

#***************** end postfix_changes ********************************

I have System configuration environment files used by scripts needing
system information. Example names are for managing different nodes on my
network and my neighbor's system. network local setup uses static addresses
and whatever ISP currently using.

$ ls /var/local/*env
/var/local/bittwister_frontier_static.env /var/local/localhost.env
/var/local/bittwister_spectrum_static.env /var/local/mtv.env
/var/local/cls_bittwister.env /var/local/printer.env
/var/local/cls.env /var/local/scanner.env
/var/local/install.env /var/local/tb.env
/var/local/ir_tuner.env /var/local/tuner.env
/var/local/isp.env /var/local/vb.env
/var/local/isp_router.env /var/local/voip.env
/var/local/lan.env /var/local/wb4.env
/var/local/lan_router.env /var/local/wb.env
/var/local/local.env /var/local/webcam.env

Example wb node info
$ cat /var/local/wb.env
#***************************************************
# # /var/local/wb.env
# Created by /local/bin/create_sys_env Fri 18 Mar 05:32 2022
# in gen_node_env
# # if you changes this file update
# /local/bin/create_sys_env
# #***************************************************
# n_seg_wan0="192.168.50"
n_seg_enp0="192.168.50"
n_gw="192.168.50.1"
n_desc_enp0="LAN_NIC"
n_domain_enp0="home.test"
n_enp0="enp3s0"
n_hosts_enp0="192.168.50.132 wb.home.test wb"
n_ip_enp0="192.168.50.132"
n_mac_enp0="a0:f3:c1:00:3c:1e"
n_onboot_enp0=yes
n_seg_enp1="192.168.15"
n_desc_enp1="VOIP_NIC"
n_domain_enp1="voip.test"
n_enp1="enp4s0"
n_hosts_enp1="192.168.15.135 voip.voip.test voip-wb-gateway"
n_ip_enp1="192.168.15.135"
n_mac_enp1="d4:85:64:0d:ef:a4"
n_onboot_enp1=no
n_desc_wlp0="WIFI"
n_wlp0="wlp2s0"
n_onboot_wlp0=no
n_onboot_wlp1=no
n_webpg="file:///local/doc/bittwister.html"
#****** end gen_node_env /var/local/wb.env ****************

Hello William!

Wednesday March 30 2022 05:07, William Unruh wrote to All:

> c) Update by transfering a Mga8 /etc/urpmi/urpmi.cfg in, running
> urpmi.update -a, and then urpmi --auto-select
> Advantage: Again preserving configurations. But again the worry
> that
> some names have changed sufficiently to not be updated (eg gimp
> renamed to gimp2 and thus the update is invisible to the system)
> It can be done remotely.

> What are the other disadvnatages of the three choices? Any advice?

> What about upgrading from Mga6 to 8. That lets out b) since Mageia
> strongly advises not to do this. One could do b) (or c) from 6 to 7
> and then from 7 to 8. What would happen if one did c) for 6 to 8
> directly?

I would recommend upgrading from 6 by install / upgrade to 7 reboot and do
a quick check etc before then upgrading to 8.

Testing in done going from current to next release and not by jumping more
than one as that has enough possible issues.

What is really needed is that Mageia follows they way that other distro's
work in providing a LTS with around a five year life followed by an upgrade
to the next LTS service.

Going from one release to the next "should" be safe as the standards
products that are or could be installed on that release must be known so
the scripts should be written to take all that in to account.

In practice, this is not fully tested for and it has been known to go pear
shaped.

What would help is a selectable automatic tool that backs up the existing
system so that it can be reverted back witch is fully testing when using a
different partition to save to and my experience of using rsync does not
cut it at all.
In fact, so far I have not found anything that does

Best recommendation is never but never do an update until it has been in
the field for 6 months to allow time for it to be well tested with new
updates to it as needed first.

Well that's my 5 pence worth.

Vincent

On Wed, 30 Mar 2022 14:54:39 +0100, Vincent Coen wrote:

>
> What would help is a selectable automatic tool that backs up the existing
> system so that it can be reverted back witch is fully testing when using a
> different partition to save to and my experience of using rsync does not
> cut it at all.
> In fact, so far I have not found anything that does

Hmmmmm, I use rsync all the time without problem.
Then again I never backup a running system. Usually boot previous install
and run my backup script. Sounds like you do not use a good set of
rsync arguments. Snippet from script:

_cmd="rsync -aAHSXxv --exclude "\'$_exclude_list\'" --delete /$_src/ /$_dest"
echo running $_cmd
$_cmd

On 30.03.2022 at 14:54, Vincent Coen scribbled:

> What would help is a selectable automatic tool that backs up the
> existing system so that it can be reverted back witch is fully
> testing when using a different partition to save to and my experience
> of using rsync does not cut it at all.
> In fact, so far I have not found anything that does

Timeshift.

--
With respect,
= Aragorn =

On 2022-03-30, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Wed, 30 Mar 2022 04:07:19 -0000 (UTC), William Unruh wrote:
>> Thre are three ways I can think of upgrading say from Mga7 to 8.
>>
>> a) Wipe 7 and Install 8.
>> Avantage-- the system is liable to uniform, and bugs resulting from
>> mixes of 7 programs which did not get upgraded and 8 programs is
>> reduced
>> Disadvantage: Suddenly all of the configuration choices that were
>> made in 7 to get it to run as you want it (from crucial things like
>> /etc/passwrd and /etc/shadow
>
> Yup, my passwd_changes script pulls all ids greater than 1499 to get
> user id and passwords and cli commands to make other additional changes.
>
>> to /etc/ssh/*
>
> Yep, saw some keyword changes and had to modify my script based on version.
>
>> or /etc/postfix choices,
>> to thousands of other programs) are not longer there. It has
>> typically taken me about a month of unproductive work to get the
>> system back to a useable state.
>
> Easily solved using configuration scripts and easy enough to code/debug/test
> in a virtualbox guest.

Which means that I have to spend weeks writing and debugging etc those
config script, only to have crucial pieces change on the next upgrade,
and not have to alter both the system itself AND the config scripts.
Yes, they are helpful ( and I have done that for some things, like
always changeing the tex config files to use Letter rather than A4 and
some other things) but they sure are not a final solution.

>
>
>> b) Upgrade in place from the cdrom/usb stick.
>> Advantage: most of the configurations remain in place, but sometimes
>> new programs dislike old configurations
>> Disadvantage: You still have to take down the machine in person to
>> install the new system. Ie, it cannot be done remotely.
>
> Then c) would be better than b)
>
>> c) Update by transfering a Mga8 /etc/urpmi/urpmi.cfg in, running
>> urpmi.update -a, and then urpmi --auto-select
>> Advantage: Again preserving configurations. But again the worry that
>> some names have changed sufficiently to not be updated (eg gimp
>> renamed to gimp2 and thus the update is invisible to the system)
>> It can be done remotely.
>>
>> What are the other disadvnatages of the three choices? Any advice?
>
> Create custom install/change scripts to run after clean installs.
> $ dir install_* | wc -l
> 50
>
> $ dir *_changes | wc -l
> 191

That's 250 scripts I have to write, to debug and to change each and
every time I do an upgrade, since "things have changed".
>
>> What about upgrading from Mga6 to 8. That lets out b) since Mageia
>> strongly advises not to do this. One could do b) (or c) from 6 to 7 and
>> then from 7 to 8. What would happen if one did c) for 6 to 8 directly?
>>
>> I tried b) on one system, (about 4000 packages replaced) but an
>> frighted to start looking for the problems.
>
>
> That is where automating install helps. I have a change counter in
> my scripts and if count is incorrect I can look at the script log and
> config files to see what did not happen. I use the "script" command to
> log script activity. Example:
> scipt -c "new_install" new_install.log

I agree it helps. However it is not really a panacea.
>
>
> Trust me, push redundant code into functions. build boiler plate/skeleton
> scripts and it becomes dead easy to copy one into new change/install file
> and start hacking away.
>
> My current boiler plate/skeletons
> $ ls *skel*
> bash_skeleton skel_changes skeleton_sb_drop_in_changes
> install_skeleton skeleton_changes skeleton_service_changes
>
> Function includes in install_skeleton
> . /local/bin/functions_path_app # set PATH and other common variables
> . /local/bin/functions_xmsg # wrapper around xmessage
> . /local/bin/functions_install # install functions
> . /local/bin/functions_change # change functions.
>
>
> $ grep function functions_install | grep -v '#'
> function x_args ()
> function x_urpmi ()
> function x_urpme ()
> function mount_rst ()
> function umount_rst ()
>
> $ grep function functions_change | grep -v '#'
> function set_facl ()
> function save_facl ()
> function save_perms ()
> function set_perms ()
> function ck_vorig_dir()
> function ck_vsave_dir()
> function ck_rpmnew()
> function cp_vsave_vinstal()
> function cp_vinstall()
> function cp_vorig()
> function mv_vorig()
> function restore_vinstall()
> function restore_vorig()
> function null_fn ()
> function chg_check ()
>
> I can recommend a change script for each file for a given app.
> For postfix I have the different changes.
>
> $ ls *post*
> ck_postfix postfix_main_cf_changes
> create_postfix_db postfix_make_changes
> Makefile_postfix postfix_sasl_changes
> post_conf postfix_sasl_passwd_bittwister
> postfix_aa_init_changes postfix_sasl_passwd_grannys_account
> postfix_aliases_changes postfix_sender_relay_changes
> postfix_changes postfix_tls_policy_changes
> postfix_cleanup postfix_transport_changes
> postfix_generic_changes postfix_z_cleanup_changes
> postfix_local_changes postfix_z_make_changes
>
> postfix_changes snippet run all the change scripts
> #*****************************************
> #* main code start here
> #*****************************************
>
>
> progress "\n\t # Running $_exe "$_action"\n"
>
> cd /etc/postfix
>
> parse_cmd_line
>
> #************************
> #* run all change scripts
> #************************
>
> while read -r line ; do
> $line "$_action"
> done < <(ls -1 /local/bin/postfix_*_changes*)
>
>
> systemctl stop postfix
> sleep 2
> systemctl start postfix
>
> rm --force $_tmp_fn
>
> progress "# Completed $_exe "$_action""
>
> #***************** end postfix_changes ********************************
>
> I have System configuration environment files used by scripts needing
> system information. Example names are for managing different nodes on my
> network and my neighbor's system. network local setup uses static addresses
> and whatever ISP currently using.
>
> $ ls /var/local/*env
> /var/local/bittwister_frontier_static.env /var/local/localhost.env
> /var/local/bittwister_spectrum_static.env /var/local/mtv.env
> /var/local/cls_bittwister.env /var/local/printer.env
> /var/local/cls.env /var/local/scanner.env
> /var/local/install.env /var/local/tb.env
> /var/local/ir_tuner.env /var/local/tuner.env
> /var/local/isp.env /var/local/vb.env
> /var/local/isp_router.env /var/local/voip.env
> /var/local/lan.env /var/local/wb4.env
> /var/local/lan_router.env /var/local/wb.env
> /var/local/local.env /var/local/webcam.env
>
> Example wb node info
> $ cat /var/local/wb.env
> #***************************************************
> #
> # /var/local/wb.env
> # Created by /local/bin/create_sys_env Fri 18 Mar 05:32 2022
> # in gen_node_env
> #
> # if you changes this file update
> # /local/bin/create_sys_env
> #
> #***************************************************
> #
> n_seg_wan0="192.168.50"
> n_seg_enp0="192.168.50"
> n_gw="192.168.50.1"
> n_desc_enp0="LAN_NIC"
> n_domain_enp0="home.test"
> n_enp0="enp3s0"
> n_hosts_enp0="192.168.50.132 wb.home.test wb"
> n_ip_enp0="192.168.50.132"
> n_mac_enp0="a0:f3:c1:00:3c:1e"
> n_onboot_enp0=yes
> n_seg_enp1="192.168.15"
> n_desc_enp1="VOIP_NIC"
> n_domain_enp1="voip.test"
> n_enp1="enp4s0"
> n_hosts_enp1="192.168.15.135 voip.voip.test voip-wb-gateway"
> n_ip_enp1="192.168.15.135"
> n_mac_enp1="d4:85:64:0d:ef:a4"
> n_onboot_enp1=no
> n_desc_wlp0="WIFI"
> n_wlp0="wlp2s0"
> n_onboot_wlp0=no
> n_onboot_wlp1=no
> n_webpg="file:///local/doc/bittwister.html"
> #****** end gen_node_env /var/local/wb.env ****************
>
>

On Wed, 30 Mar 2022 09:54:39 -0400, Vincent Coen <VBCoen@gmail.com> wrote:
> I would recommend upgrading from 6 by install / upgrade to 7 reboot and do
> a quick check etc before then upgrading to 8.

That, I agree with.

> Testing in done going from current to next release and not by jumping more
> than one as that has enough possible issues.
> What is really needed is that Mageia follows they way that other distro's
> work in providing a LTS with around a five year life followed by an upgrade
> to the next LTS service.

The problem with a LTS service, other then volunteer power to actually implement
and support it, is that features may stop being supported, by any update. With
stable releases we do not allow changes in versions of a package (with exceptions),
mainly to avoid cases where something stops working because it's no longer
supported.

While a LTS does avoid the problem of having to upgrade from release to release,
it also means the system administrator must be much more careful about installing
each and every update, and be ok with some features no longer working.

> Going from one release to the next "should" be safe as the standards
> products that are or could be installed on that release must be known so
> the scripts should be written to take all that in to account.
>
> In practice, this is not fully tested for and it has been known to go pear
> shaped.

Upgrading from release to release+1 is tested to the best of our ability. We can't
test every combination of hardware, partitioning choices, software combinations,
but do the best we can. Third party software may also cause problems.

> What would help is a selectable automatic tool that backs up the existing
> system so that it can be reverted back witch is fully testing when using a
> different partition to save to and my experience of using rsync does not
> cut it at all.
> In fact, so far I have not found anything that does

Any backup system should not be used to back up or restore the currently running
system. Used properly, rsync does work well, but care must be taken. The backup is
not bootable (using just the backup) without altering fstab, and all other partition
references, after which it's not suitable for restore.

> Best recommendation is never but never do an update until it has been in
> the field for 6 months to allow time for it to be well tested with new
> updates to it as needed first.
> Well that's my 5 pence worth.

I disagree with that. The new release is released when the qa iso testers group
has finished testing new installs and upgrades from the prior release.

Any update released after that may introduce new conflicts that will cause problems
in upgrading. We don't re-test upgrading for each update. The longer the period
between the release and the upgrade, the more likely there will be new problems,
that did not exist when qa tested upgrading.

It's safest to upgrade within the first month or so after a new release.

Do follow the wiki recommendations. Make a backup. Uninstall any third party
software (it can be reinstalled after the upgrade). Check the errata for any
known problems and their work arounds.
https://wiki.mageia.org/en/How_to_choose_the_right_Mageia_upgrade_method#Preparations
https://wiki.mageia.org/en/Mageia_8_Release_Notes
https://wiki.mageia.org/en/Mageia_8_Errata

Regards, Dave Hodgins

On 2022-03-30, William Unruh <unruh@invalid.ca> wrote:
> On 2022-03-30, Bit Twister <BitTwister@mouse-potato.com> wrote:
>> On Wed, 30 Mar 2022 04:07:19 -0000 (UTC), William Unruh wrote:
>>> Thre are three ways I can think of upgrading say from Mga7 to 8.
.....

>>> c) Update by transfering a Mga8 /etc/urpmi/urpmi.cfg in, running
>>> urpmi.update -a, and then urpmi --auto-select
>>> Advantage: Again preserving configurations. But again the worry that
>>> some names have changed sufficiently to not be updated (eg gimp
>>> renamed to gimp2 and thus the update is invisible to the system)
>>> It can be done remotely.
>>>

WEll I tried c) on one system. The mirror was princeton. But something
weird happened. On my first try I kept getting wget/curl timeouts (well
maby 5 or 6 of the first 200 packages out of 4000) I would just say
"continue. But then urpmi seems to have goten itself into a weird state.
It would say that it was installing some list of 50 or so packages,
would download them, and would then not install anything, and go on to
the next batch. I finally did ^C, reran urpmi.update -a and urpmi
--auto-select. (this was before I saw the recommendation to use the
upgrade app). This time things seemed to go much better, it still got
about 3 inabilities to download. but the upgrade finished. I reran
urpmi and it installed a couple of the missed ones, but one absoluteluy
refused to install I would rerun urpmi (sometimes with auto-select,
sometimes with the name of the package directly on the urpmi line) but
after 5 tries it never did install that package. Now the curl/wget
failure I attribute to some problem with the princton mirror. But the
refusal to install seems to be a bug in urpmi.
The final bug was the package icedtea-web which consistantly refused to
install (with no error message, just urpmi finishing without installing)

boson:10.0[root]>urpmi --auto-select
To satisfy dependencies, the following package is going to be installed:
Package Version Release Arch
(medium "Core Release")
icedtea-web 1.8.2 2.mga8 x86_64
19KB of additional disk space will be used.
1.9MB of packages will be retrieved.
Proceed with the installation of one package? (Y/n)

boson:10.0[root]>
boson:10.0[root]>rpm -qa|grep icedtea
icedtea-web-1.8-2.1.mga7

On Wed, 30 Mar 2022 15:42:57 -0400, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

> On Wed, 30 Mar 2022 15:15:39 -0400, William Unruh <unruh@invalid.ca> wrote:
>> The final bug was the package icedtea-web which consistantly refused to
>> install (with no error message, just urpmi finishing without installing)
>
>> boson:10.0[root]>urpmi --auto-select
>> To satisfy dependencies, the following package is going to be installed:
>> Package Version Release Arch
>> (medium "Core Release")
>> icedtea-web 1.8.2 2.mga8 x86_64
>> 19KB of additional disk space will be used.
>> 1.9MB of packages will be retrieved.
>> Proceed with the installation of one package? (Y/n)
> Try ...
> # urpme icedtea-web
> # urpmi --clean
> # urpmi icedtea-web

Also, double check "urpmq --list-media active" to make sure the repos for both
release and updates are being used, for core, and if enabled, nonfree and tainted.

Regards, Dave Hodgins

On Wed, 30 Mar 2022 15:15:39 -0400, William Unruh <unruh@invalid.ca> wrote:
> The final bug was the package icedtea-web which consistantly refused to
> install (with no error message, just urpmi finishing without installing)

> boson:10.0[root]>urpmi --auto-select
> To satisfy dependencies, the following package is going to be installed:
> Package Version Release Arch
> (medium "Core Release")
> icedtea-web 1.8.2 2.mga8 x86_64
> 19KB of additional disk space will be used.
> 1.9MB of packages will be retrieved.
> Proceed with the installation of one package? (Y/n)
Try ...
# urpme icedtea-web
# urpmi --clean
# urpmi icedtea-web

Regards, Dave Hodgins

On 30/3/22 15:07, William Unruh wrote:
> Thre are three ways I can think of upgrading say from Mga7 to 8.
>

I do a clean install not an upgrade because of all the config struggle.

I resist mightily until the current release is no longer supported and
Firefox starts to whine.

Then it's an afternoon or two or three of config and customizing,
cursing and raging.
It's a bullet one has to bite. Although I would dearly prefer to fire it
at someone. :-)

--
faeychild
Running plasmashell 5.20.4 on 5.15.32-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 31/3/22 01:42, Aragorn wrote:
> On 30.03.2022 at 14:54, Vincent Coen scribbled:
>
>> What would help is a selectable automatic tool that backs up the
>> existing system so that it can be reverted back witch is fully
>> testing when using a different partition to save to and my experience
>> of using rsync does not cut it at all.
>> In fact, so far I have not found anything that does
>
> Timeshift.
>

that does look interesting, Aragorn. It may be better than a battle with
rysnc

--
faeychild
Running plasmashell 5.20.4 on 5.15.32-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 2022-03-30, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Wed, 30 Mar 2022 15:15:39 -0400, William Unruh <unruh@invalid.ca> wrote:
>> The final bug was the package icedtea-web which consistantly refused to
>> install (with no error message, just urpmi finishing without installing)
>
>> boson:10.0[root]>urpmi --auto-select
>> To satisfy dependencies, the following package is going to be installed:
>> Package Version Release Arch
>> (medium "Core Release")
>> icedtea-web 1.8.2 2.mga8 x86_64
>> 19KB of additional disk space will be used.
>> 1.9MB of packages will be retrieved.
>> Proceed with the installation of one package? (Y/n)
> Try ...
> # urpme icedtea-web
> # urpmi --clean
> # urpmi icedtea-web

OK, that worked.
Thanks

Whatever got messed up in the cache, urpmi should have given me some
sort of error message, and not simply crapped out.

On 2022-03-30, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Wed, 30 Mar 2022 15:42:57 -0400, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>
>> On Wed, 30 Mar 2022 15:15:39 -0400, William Unruh <unruh@invalid.ca> wrote:
>>> The final bug was the package icedtea-web which consistantly refused to
>>> install (with no error message, just urpmi finishing without installing)
>>
>>> boson:10.0[root]>urpmi --auto-select
>>> To satisfy dependencies, the following package is going to be installed:
>>> Package Version Release Arch
>>> (medium "Core Release")
>>> icedtea-web 1.8.2 2.mga8 x86_64
>>> 19KB of additional disk space will be used.
>>> 1.9MB of packages will be retrieved.
>>> Proceed with the installation of one package? (Y/n)
>> Try ...
>> # urpme icedtea-web
>> # urpmi --clean
>> # urpmi icedtea-web
>
> Also, double check "urpmq --list-media active" to make sure the repos for both
> release and updates are being used, for core, and if enabled, nonfree and tainted.

Yes, that is fine.

On Wed, 30 Mar 2022 15:33:17 -0000 (UTC), William Unruh wrote:
> On 2022-03-30, Bit Twister <BitTwister@mouse-potato.com> wrote:

>>> or /etc/postfix choices,
>>> to thousands of other programs) are not longer there. It has
>>> typically taken me about a month of unproductive work to get the
>>> system back to a useable state.
>>
>> Easily solved using configuration scripts and easy enough to code/debug/test
>> in a virtualbox guest.
>
> Which means that I have to spend weeks writing and debugging etc those
> config script, only to have crucial pieces change on the next upgrade,
> and not have to alter both the system itself AND the config scripts.

My experience is not that much change needs maintenance work.

> Yes, they are helpful ( and I have done that for some things, like
> always changeing the tex config files to use Letter rather than A4 and
> some other things) but they sure are not a final solution.

>> Create custom install/change scripts to run after clean installs.
>> $ dir install_* | wc -l
>> 50
>>
>> $ dir *_changes | wc -l
>> 191
>
> That's 250 scripts I have to write, to debug and to change each and

Ah, but it is normally a one time activity. If you have a well designed
skeleton/boiler plate script it is dead easy to change/maintain.

> every time I do an upgrade, since "things have changed".

That time is there regardless of methodology. If the script does a change
check you do not have to verify any key word changes. Much time saved there.

As for testing new releases it is more efficient and much less stressful
for me to do a clean cauldron install, and check install script logs
than doing it on a "Production" machine.

Bottom of major install scripts checks logs and displays all the failures.

Since I added code to report about the install I can see the time for
install on different nodes/releases. Example:
$ grep Elapsed *mga8*install_addons.rpt*
mtv_mga8_8_o0_install_addons.rpt_001:Elapsed: 0 00:09:25 for 148 packages
wb4_mga8_8_o0_install_addons.rpt_001:Elapsed: 0 00:12:38 for 60 packages
wb_mga8_8_o0_install_addons.rpt_001:Elapsed: 0 00:13:01 for 154 packages

On Wed, 30 Mar 2022 17:11:26 -0400, William Unruh <unruh@invalid.ca> wrote:

> On 2022-03-30, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>> On Wed, 30 Mar 2022 15:15:39 -0400, William Unruh <unruh@invalid.ca> wrote:
>>> The final bug was the package icedtea-web which consistantly refused to
>>> install (with no error message, just urpmi finishing without installing)
>>
>>> boson:10.0[root]>urpmi --auto-select
>>> To satisfy dependencies, the following package is going to be installed:
>>> Package Version Release Arch
>>> (medium "Core Release")
>>> icedtea-web 1.8.2 2.mga8 x86_64
>>> 19KB of additional disk space will be used.
>>> 1.9MB of packages will be retrieved.
>>> Proceed with the installation of one package? (Y/n)
>> Try ...
>> # urpme icedtea-web
>> # urpmi --clean
>> # urpmi icedtea-web
>
> OK, that worked.
> Thanks
>
> Whatever got messed up in the cache, urpmi should have given me some
> sort of error message, and not simply crapped out.

That I agree with, however figuring out why it didn't is now past being possible.
File corruption can have weird impacts.

I'd also check the setting in /etc/urpmi/urpmi.cfg for the global options at the
top of the file. I recommend ...
{ downloader: wget
resume: 1
verify-rpm: 1
xml-info: always
}

Those can also be set using rpmdrake, selecting Options, Media manager, then in
the media manager window, Options, Global Options.

Regards, Dave Hodgins

On Wed, 30 Mar 2022 19:15:39 -0000 (UTC), William Unruh wrote:
> On 2022-03-30, William Unruh <unruh@invalid.ca> wrote:
>> On 2022-03-30, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>> On Wed, 30 Mar 2022 04:07:19 -0000 (UTC), William Unruh wrote:
>>>> Thre are three ways I can think of upgrading say from Mga7 to 8.
> ....
>
>>>> c) Update by transfering a Mga8 /etc/urpmi/urpmi.cfg in, running
>>>> urpmi.update -a, and then urpmi --auto-select
>>>> Advantage: Again preserving configurations. But again the worry that
>>>> some names have changed sufficiently to not be updated (eg gimp
>>>> renamed to gimp2 and thus the update is invisible to the system)
>>>> It can be done remotely.
>>>>
>
> WEll I tried c) on one system. The mirror was princeton. But something
> weird happened. On my first try I kept getting wget/curl timeouts (well
> maby 5 or 6 of the first 200 packages out of 4000) I would just say
> "continue.

Yup, seen princetion acting up for the first time about a month ago and
only use wget as downloader.

> But then urpmi seems to have goten itself into a weird state.
> It would say that it was installing some list of 50 or so packages,
> would download them, and would then not install anything, and go on to
> the next batch. I finally did ^C, reran urpmi.update -a and urpmi
> --auto-select. (this was before I saw the recommendation to use the
> upgrade app).

My pull_updates script checks that the mirror is up and not stale prior
to getting packages. I also find it helps to use --test prior to doing
the actual install to get all rpms on site and get the install should
work message.

> This time things seemed to go much better, it still got
> about 3 inabilities to download. but the upgrade finished. I reran
> urpmi and it installed a couple of the missed ones, but one absoluteluy
> refused to install I would rerun urpmi (sometimes with auto-select,
> sometimes with the name of the package directly on the urpmi line) but
> after 5 tries it never did install that package. Now the curl/wget
> failure I attribute to some problem with the princton mirror. But the
> refusal to install seems to be a bug in urpmi.
> The final bug was the package icedtea-web which consistantly refused to
> install (with no error message, just urpmi finishing without installing)

Weird, Can only guess mirror was in middle of syncing from up stream mirror.
All/most of my problems are a bad rpm download throwing a checksum error.
Delete the rpm from cache and retry solves the problem.

On Wed, 30 Mar 2022 17:42:43 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:
> Yup, seen princetion acting up for the first time about a month ago and
> only use wget as downloader.

One factor that has been a problem at times, is that someone has been launching
ddos attacts against princeton. Not all the time, but every so often. I'm not sure
if that's why curl and aria2c fail more often or not.
Regards, Dave Hodgins

On Wed, 30 Mar 2022 18:14:10 -0400, David W. Hodgins wrote:
> On Wed, 30 Mar 2022 17:42:43 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:
>> Yup, seen princetion acting up for the first time about a month ago and
>> only use wget as downloader.
>
> One factor that has been a problem at times, is that someone has been launching
> ddos attacts against princeton. Not all the time, but every so often. I'm not sure
> if that's why curl and aria2c fail more often or not.

Some mirrors have limits on number of concurrent connections by user
and time of day or system load. That is why I only use wget instead of
those multi-connect loaders.

I also hard code/chose desired mirror instead of using $MIRRORLIST.

On 31/3/22 04:04, David W. Hodgins wrote:

> Upgrading from release to release+1 is tested to the best of our
> ability. We can't
> test every combination of hardware, partitioning choices, software
> combinations,
> but do the best we can. Third party software may also cause problems.

Yep

Each release invites me to install my printer/scanner driver
I know that I should have taken notes but by the time I've banged my
head on the keyboard all evening I am just glad to have it FINALLY working

And, of course, I'll remember next time, wont I?

AND AND the previous time for M8 I decided to network the printer

Got real close to the edge of madness there.

--
faeychild
Running plasmashell 5.20.4 on 5.15.32-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso

On 31.03.2022 at 08:05, faeychild scribbled:

> On 31/3/22 01:42, Aragorn wrote:
> > On 30.03.2022 at 14:54, Vincent Coen scribbled:
> >
> >> What would help is a selectable automatic tool that backs up the
> >> existing system so that it can be reverted back witch is fully
> >> testing when using a different partition to save to and my
> >> experience of using rsync does not cut it at all.
> >> In fact, so far I have not found anything that does
> >
> > Timeshift.
>
> that does look interesting, Aragorn. It may be better than a battle
> with rysnc

It uses rsync for backups to another block device — it does not support
bavking up across a network, though — and it can also use btrfs
snapshots, if you use btrfs. These are of course not equivalent,
because btrfs snapshots aren't backups.

By default, it does not include /home — the developer recommends using
other tools for backing up /home — but you can tell it to include or
exclude directories. It's pretty flexible, and it can be used both via
its GUI and from the command line.

You can even retrieve individual files from your backups if you know
how to navigate the tree.

I've been using it for now almost three years, and I've never had a
problem with it.

--
With respect,
= Aragorn

On 3/30/22 22:35, faeychild wrote:
> On 31/3/22 04:04, David W. Hodgins wrote:
>
>
>> Upgrading from release to release+1 is tested to the best of our
>> ability. We can't
>> test every combination of hardware, partitioning choices, software
>> combinations,
>> but do the best we can. Third party software may also cause problems.
>
> Yep
>
> Each release invites me to install my printer/scanner driver
> I know that I should have taken notes but  by the time I've banged my
> head on the keyboard all evening I am just glad to have it FINALLY working
>
> And, of course, I'll remember next time, wont I?
>
> AND AND the previous time for M8 I decided to network the printer
>
> Got real close to the edge of madness there.
>
>
>
Interesting. I have three printers, all HP. The oldest is a Deskjet
5650, almost 20 years old, but it still works. Newest is a 2018 Envy
Photo 7858, purchased as refurbished to replace an Officejet that went
belly up. I needed the scanner, not the printer, but all-in-ones are a
LOT easier to find, and cheaper, than stand-alone scanners. In between
is an old color Laserjet, a gift my nephew rescued when it was cast off
by the office where he worked.

Easy to install with MCC, only a few minutes each. The newest one is the
only one that's wireless, so I used it to test the networking setup of
the recent hplip update. The printer set itself up with my router, so
MCC again had no problems configuring it as a network printer on a
couple of my other computers.

TJ

On 3/30/22 09:54, Vincent Coen wrote:

>
> Best recommendation is never but never do an update until it has been in
> the field for 6 months to allow time for it to be well tested with new
> updates to it as needed first.
>
I disagree. Those wanting to do an upgrade install should not wait that
long, at least not with Mageia.

When a new release becomes official, the previous Mageia release is
supported for at least an additional three months. Part of that support
is trying to make sure that new updates to the official release do not
break the upgrade path.

But after that previous release reaches End-Of-Support, checking that
upgrade path is no longer done by QA. It probably won't happen right
away, but the farther you get from that EOS date, the more likely it is
that some update or another will break the upgrade path.

For my part as a member of QA, by the time we hit the Official release
of a new version, I've already been using it on a daily basis as a
production install, looking for problems that would block that release.
So, I have NO problem switching anything to the new release on the date
it is declared Official. I keep a couple of the old systems around for
testing purposes, but don't use any of them for production, and once the
old release reaches EOS they are all switched over to the new release,
usually by clean install, just to be sure all the debris from those old
tests is cleared out.

TJ