Upgrading

[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.

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.

[David W. Hodgins]

Post by William Unruh
Thre are three ways I can think of upgrading say from Mga7 to 8.
a) Wipe 7 and Install 8.

<snip>

Post by William Unruh
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>

Post by William Unruh
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.

Post by William Unruh
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.

Post by William Unruh
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

[William Unruh]

Post by David W. Hodgins

Post by William Unruh
Thre are three ways I can think of upgrading say from Mga7 to 8.
a) Wipe 7 and Install 8.

<snip>

Post by William Unruh
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>

Post by William Unruh
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

That web page or the method has a lacuuna. I run the test. Each time I
do so, it downloads all of the files again (more than 1 hr on my Gbit
fibre cable) making the test a real pain to use. It also does not say
that it has run out of room. It just says that the package needs 27MB to
install. And I have 3GB on / partition. I finally figured out that this
meant it had run out of room on the test run.
Then, when I finally made enough room ( I had 17GB hidden under the
mount point of my /local) and it said I could install, it seemed again
to go ahead and download all of files that it just downloaded-- a real
waste of time. I tried looking at the options for uprmi but could not
see anything which sid to just use the cached files in the cache
directory /newlocal/rpms (that was where I had to put the cache since /
was too full).

Ie, that web page really needs some editing to make it more idiot proof.
Eg, why in the world save the downloads if it is going to ignore them
anyway.

Post by David W. Hodgins
See that site in the wiki for the pros/cons of each

[Bit Twister]

Post by William Unruh

Post by David W. Hodgins

Post by William Unruh
Thre are three ways I can think of upgrading say from Mga7 to 8.
a) Wipe 7 and Install 8.

<snip>

Post by William Unruh
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>

Post by William Unruh
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

That web page or the method has a lacuuna. I run the test. Each time I
do so, it downloads all of the files again (more than 1 hr on my Gbit
fibre cable) making the test a real pain to use. It also does not say
that it has run out of room. It just says that the package needs 27MB to
install. And I have 3GB on / partition. I finally figured out that this
meant it had run out of room on the test run.
Then, when I finally made enough room ( I had 17GB hidden under the
mount point of my /local) and it said I could install, it seemed again
to go ahead and download all of files that it just downloaded-- a real
waste of time. I tried looking at the options for uprmi but could not
see anything which sid to just use the cached files in the cache
directory /newlocal/rpms (that was where I had to put the cache since /
was too full).

There is no time saved on test, or not, as far as download time is concerned.

I do have to disagree about using the downloaded files. My pull_updates
script checks the node and if not "wb" then rsync's the cached rpms from 'wb' then
do the urpmi to get sync*.cz and already sees the cached rpm files
and does not download them again.

[William Unruh]

Post by Bit Twister

Post by William Unruh

Post by David W. Hodgins

Post by William Unruh
Thre are three ways I can think of upgrading say from Mga7 to 8.
a) Wipe 7 and Install 8.

<snip>

Post by William Unruh
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>

Post by William Unruh
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

That web page or the method has a lacuuna. I run the test. Each time I
do so, it downloads all of the files again (more than 1 hr on my Gbit
fibre cable) making the test a real pain to use. It also does not say
that it has run out of room. It just says that the package needs 27MB to
install. And I have 3GB on / partition. I finally figured out that this
meant it had run out of room on the test run.
Then, when I finally made enough room ( I had 17GB hidden under the
mount point of my /local) and it said I could install, it seemed again
to go ahead and download all of files that it just downloaded-- a real
waste of time. I tried looking at the options for uprmi but could not
see anything which sid to just use the cached files in the cache
directory /newlocal/rpms (that was where I had to put the cache since /
was too full).

There is no time saved on test, or not, as far as download time is concerned.

Which is stupid. The files are all downloaded and tested that they will
(at least superficially) install. I have now downloaded about 50GB,
instead of 5 from princeton. That overloads their server, and is really
bad manners.

Post by Bit Twister
I do have to disagree about using the downloaded files. My pull_updates
script checks the node and if not "wb" then rsync's the cached rpms from 'wb' then
do the urpmi to get sync*.cz and already sees the cached rpm files
and does not download them again.

I do agree rsync would be better, but the default is curl, and wget is
easy. But using rsync can be rather tricky getting the right path.
man urpmi.conf
gives no hint about how to use rsync. And rsync can be tricky.

Can I simply put downloader: rsync
into the first stanza and replace http:// with rsync://
in the URL? EG
rsync://mirror.math.princeton.edu/pub/mageia/distrib/7/x86_64/media/core/release
in /etc/urpmi/urpmi.conf?

[David W. Hodgins]

Post by William Unruh

Post by Bit Twister
There is no time saved on test, or not, as far as download time is concerned.

Which is stupid. The files are all downloaded and tested that they will
(at least superficially) install. I have now downloaded about 50GB,
instead of 5 from princeton. That overloads their server, and is really
bad manners.

There is no time saved by using the test option, compared to skipping the step with
the --test option. It doesn't download them again, if they are in
/var/cache/urpmi/rpms. Note if you get a corrupted download, you must manually delete
the corrupted file, or use urpmi --clean, which deletes all files in that directory.

Regards, Dave Hodgins

[Bit Twister]

On Sat, 9 Apr 2022 22:55:44 -0000 (UTC), William Unruh wrote:

<snip>

Post by William Unruh

Post by Bit Twister
There is no time saved on test, or not, as far as download time is concerned.

Which is stupid. The files are all downloaded and tested that they will
(at least superficially) install. I have now downloaded about 50GB,
instead of 5 from princeton. That overloads their server, and is really
bad manners.

Hmmm, Off hand I do not remember 50 gig downloads unless doing a new release.
If those are normal updates then I suggest you should be installing updates
more often. Just checked, third time today and just now updated four packages.

Post by William Unruh

Post by Bit Twister
I do have to disagree about using the downloaded files. My pull_updates
script checks the node and if not "wb" then rsync's the cached rpms from 'wb' then
do the urpmi to get sync*.cz and already sees the cached rpm files
and does not download them again.

I do agree rsync would be better, but the default is curl, and wget is
easy. But using rsync can be rather tricky getting the right path.
man urpmi.conf
gives no hint about how to use rsync. And rsync can be tricky.

My rsync is just between local nodes. wb being my web browsing node.
I use wget for pulling anything from mirrors/sites.

[William Unruh]

Post by David W. Hodgins
<snip>

Post by William Unruh

Post by Bit Twister
There is no time saved on test, or not, as far as download time is concerned.

Which is stupid. The files are all downloaded and tested that they will
(at least superficially) install. I have now downloaded about 50GB,
instead of 5 from princeton. That overloads their server, and is really
bad manners.

Hmmm, Off hand I do not remember 50 gig downloads unless doing a new release.
If those are normal updates then I suggest you should be installing updates
more often. Just checked, third time today and just now updated four packages.

Thus are multiple reloads of the same files (about 5G worth each time,
but many times)

Post by David W. Hodgins

Post by William Unruh

Post by Bit Twister
I do have to disagree about using the downloaded files. My pull_updates
script checks the node and if not "wb" then rsync's the cached rpms from 'wb' then
do the urpmi to get sync*.cz and already sees the cached rpm files
and does not download them again.

I do agree rsync would be better, but the default is curl, and wget is
easy. But using rsync can be rather tricky getting the right path.
man urpmi.conf
gives no hint about how to use rsync. And rsync can be tricky.

My rsync is just between local nodes. wb being my web browsing node.
I use wget for pulling anything from mirrors/sites.

I got it to work, more of less as I suggested. I changes http: in
urpmi.conf to rsync: , put in a "downloader: rsync" into the very first
{
}
section, (and for jameswhitby site, removed the "pub" as the first
sub-directory) Only jameswhitby and princeton seem to be high speed and
support rsync in N America.


Does anyone know where a source is for Mga6? The sites I have looked at
are all 7,8,cauldron only.

[David W. Hodgins]

Post by William Unruh
Thus are multiple reloads of the same files (about 5G worth each time,
but many times)

That is not my experience.

Post by William Unruh
Does anyone know where a source is for Mga6? The sites I have looked at
are all 7,8,cauldron only.

https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia-archive/distrib/

There may be other mirrors that have the archive, but if so, I'm not aware of them.

Regards, Dave Hodgins

[William Unruh]

Post by David W. Hodgins

Post by William Unruh
Thus are multiple reloads of the same files (about 5G worth each time,
but many times)

That is not my experience.

I know. I was using an alternative cache (/newlocal/rpms) so that might
have made the difference. Your suggestion of linking
/var/cache/urpmi/rpms to that directory is probably good, but it occured
after the last, installation download of 3000 packages had finished (after many earlier
ones as I tried to get the test to pass) and the files were being
installed.

Post by David W. Hodgins

Post by William Unruh
Does anyone know where a source is for Mga6? The sites I have looked at
are all 7,8,cauldron only.

https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia-archive/distrib/
There may be other mirrors that have the archive, but if so, I'm not aware of them.
Regards, Dave Hodgins

[Bit Twister]

Post by William Unruh

Post by David W. Hodgins
<snip>

Post by William Unruh

Post by Bit Twister
There is no time saved on test, or not, as far as download time is concerned.

Which is stupid. The files are all downloaded and tested that they will
(at least superficially) install. I have now downloaded about 50GB,
instead of 5 from princeton. That overloads their server, and is really
bad manners.

Hmmm, Off hand I do not remember 50 gig downloads unless doing a new release.
If those are normal updates then I suggest you should be installing updates
more often. Just checked, third time today and just now updated four packages.

Thus are multiple reloads of the same files (about 5G worth each time,
but many times)

Post by David W. Hodgins

Post by William Unruh

Post by Bit Twister
I do have to disagree about using the downloaded files. My pull_updates
script checks the node and if not "wb" then rsync's the cached rpms from 'wb' then
do the urpmi to get sync*.cz and already sees the cached rpm files
and does not download them again.

I do agree rsync would be better, but the default is curl, and wget is
easy. But using rsync can be rather tricky getting the right path.
man urpmi.conf
gives no hint about how to use rsync. And rsync can be tricky.

My rsync is just between local nodes. wb being my web browsing node.
I use wget for pulling anything from mirrors/sites.

I got it to work, more of less as I suggested. I changes http: in
urpmi.conf to rsync: , put in a "downloader: rsync" into the very first
{
}
section, (and for jameswhitby site, removed the "pub" as the first
sub-directory) Only jameswhitby and princeton seem to be high speed and
support rsync in N America.
Does anyone know where a source is for Mga6? The sites I have looked at
are all 7,8,cauldron only.

I went to kernel.org and then it dawned on me that sometime last year I
remembered there was thread of removing old releases to ease the storage
requirements on all mirrors.


You might trying 'mageia/distrib/6/' in a search engine.

[David W. Hodgins]

Post by Bit Twister
I went to kernel.org and then it dawned on me that sometime last year I
remembered there was thread of removing old releases to ease the storage
requirements on all mirrors.
You might trying 'mageia/distrib/6/' in a search engine.

Already answered in this thread. It's Mageia-archive instead of just Mageia.
https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia-archive/

Regards, Dave Hodgins

[David W. Hodgins]

Post by William Unruh
Ie, that web page really needs some editing to make it more idiot proof.
Eg, why in the world save the downloads if it is going to ignore them
anyway.

The files in /var/cache/urpmi/rpms should only be deleted if they have actually
been installed (i.e. without the --test), or if "urpmi --clean" is run.

It should not download them again, and hasn't when I've tested it. If there isn't
enough room, in /var/cache/urpmi/rpms, and you're using a directory such as
/newlocal/rpms, then replace the directory /var/cache/urpmi/rpms with a symlink
to /newlocal/rpms.

I've added a note to https://wiki.mageia.org/en/How_to_choose_the_right_Mageia_upgrade_method#How_to_do_a_simple_upgrade_in_text_mode

Regards, Dave Hodgins

[Herman Viaene]

Post by 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

Post by William Unruh
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.

[Bit Twister]

Post by 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

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.

Post by William Unruh
to /etc/ssh/*

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

Post by William Unruh
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.

Post by William Unruh
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)

Post by William Unruh
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

Post by William Unruh
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 ****************

[William Unruh]

Post by Bit Twister

Post by 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

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.

Post by William Unruh
to /etc/ssh/*

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

Post by William Unruh
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.

Post by Bit Twister

Post by William Unruh
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)

Post by William Unruh
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".

Post by Bit Twister

Post by William Unruh
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
scipt -c "new_install" new_install.log

I agree it helps. However it is not really a panacea.

Post by Bit Twister
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 ****************

[William Unruh]

Post by William Unruh
Thre are three ways I can think of upgrading say from Mga7 to 8.

....

Post by William Unruh
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

[David W. Hodgins]

Post by William Unruh
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
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

[William Unruh]

Post by David W. Hodgins

Post by William Unruh
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
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.

[David W. Hodgins]

Post by William Unruh
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
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

[William Unruh]

Post by William Unruh
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
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.

[David W. Hodgins]

Post by William Unruh

Post by William Unruh
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
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

[Bit Twister]

Post by William Unruh

Post by William Unruh
Thre are three ways I can think of upgrading say from Mga7 to 8.

....

Post by William Unruh
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.

Post by William Unruh
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.

Post by William Unruh
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.

[David W. Hodgins]

Post by Bit Twister
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

[Bit Twister]

Post by David W. Hodgins

Post by Bit Twister
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.

[Bit Twister]

Post by William Unruh

Post by Bit Twister

Post by William Unruh
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.

Post by William Unruh
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.

Post by Bit Twister
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.

Post by William Unruh
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

[Vincent Coen]

Hello William!

Post by William Unruh
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

[Bit Twister]

Post by Vincent Coen
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

[Aragorn]

Post by Vincent Coen
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.

[faeychild]

Post by Aragorn

Post by Vincent Coen
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

[Aragorn]

Post by faeychild

Post by Aragorn

Post by Vincent Coen
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.

[faeychild]

Post by Aragorn
Timeshift.

I've had a quick look, Aragorn

Does it run independently or does it backup the live system

should I read the man page :-)

[Aragorn]

Post by faeychild

Post by Aragorn
Timeshift.

I've had a quick look, Aragorn
Does it run independently or does it backup the live system

It can be used as a GTK-based GUI application from within the running
system, or as a command-line tool, and if it's present on the live
USB/DVD, then you can even restore your backups from there, in case
your installed system is completely b0rk3n.

You can opt to have it periodically run — for _making_ backups
only, of course — via cron, or to start it manually from within your
system menu (or from the command line). It is however polkit-aware and
will ask you for a password, so it runs with root privileges.

Mind you — and it's important to know this — the medium upon which it
must store its backups is not set in the configuration as a
directory/mountpoint, but as a _block device_ — e.g. /dev/sdb2. It will
automatically mount said block device (if needed) to
/run/timeshift/backup, even if it's already mounted somewhere else in
the tree. The backups themselves are stored under a directory called
"timeshift" in the root directory of the volume that it is set to back
up to.

Post by faeychild
should I read the man page :-)

Always. :p

[David W. Hodgins]

Post by Vincent Coen
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.

Post by Vincent Coen
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.

Post by Vincent Coen
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.

Post by Vincent Coen
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.

Post by Vincent Coen
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

[faeychild]

Post by David W. Hodgins
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.

[TJ]

Post by faeychild

Post by David W. Hodgins
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

[faeychild]

Post by TJ
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

I suspect it's me

Brother provides a script which downloads and installs all the drivers.

This all seems terrific until the last bit when the script will ask if a
test print is required.

This doesn't work because the printer is yet to be installed.
This is silly and irritating

The printer is then installed with MCC or cups, usually OK.

The scanner must not be installed by MCC or everything is fubar.
The scanner must be installed by xsane or it does for me.

My printer installs with MCC demands such information as "Device URI"

Which I discovered to be "socket://192.168.20.2:9100" This is an IP
address and a port. So why call it "URI"


Something else that you were clearly expected to know beforehand.

This does not result in a calm experience. But maybe I am doing it backwards

Fortunately I have taken notes and I expect Mageia 9 to go a little
better. Like all thing, it's easy when you know how.

[Bit Twister]

Post by faeychild
Brother provides a script which downloads and installs all the drivers.

Yep, and lots of other stuff is also done. Spent a few hours getting
my install_printer to install all the Mageia packages for scanner and
whatnot, remove previous Brother install rpms and whatnot.
All that work is because all my scripts have a remove argument to remove
or reset back to day one condition.

I have the Advanced Intrusion Detection Environment​ (aide) rpm ]installed.
Run the aidecheck --init prior to install and aide.check --check afterwards
to find everything that changed.

Post by faeychild
This all seems terrific until the last bit when the script will ask if a
test print is required.
This doesn't work because the printer is yet to be installed.
This is silly and irritating

Hmmmm, the few times I forgot to answer N to print test page worked for me.

Post by faeychild
The printer is then installed with MCC or cups, usually OK.
The scanner must not be installed by MCC or everything is fubar.
The scanner must be installed by xsane or it does for me.

I have
$ grep urpmi install_printer
x_urpmi simple-scan ! Simple scanning utility​
x_urpmi sane-frontends ! Graphical frontend to SANE​
x_urpmi gocr ! OCR Optical Character Recognition program​
x_urpmi xsane ! Frontend for the SANE scanner interface​
x_urpmi saned ! local and remote scanner, digital, video device access
x_urpmi xsane-gimp ! GIMP plug-in which provides the SANE scanner interface​
x_urpmi psutils ! PostScript utilities​
x_urpmi cups-common ! Common Unix Printing System - Common stuff​
x_urpmi cups ! Common Unix Printing System - Server package​
rpms installed.

FYI: x_urpmi is a wrapper around urpmi. It checks if rpm is already
installed and skips if so.

[faeychild]

Post by Bit Twister

Post by faeychild
This all seems terrific until the last bit when the script will ask if a
test print is required.
This doesn't work because the printer is yet to be installed.
This is silly and irritating

Hmmmm, the few times I forgot to answer N to print test page worked for me.

OK I am in error somewhere

And looking forward to mageia 9
Oh Wow

regards

[Bit Twister]

Post by faeychild

Post by David W. Hodgins
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.

IIRC you have a Brother MFC-9340CDW

To create an install script you just create/paste the commands you
enter at the terminal.

It should be no problem for you to write a script to do 90% of the install.
Use wget to pull down the Brother install script, un zip it, install the
Mageia scanner rpms, run the Brother printer script start cups and httpd,
and use xmessage to pop up cups commands for printer setup in cups admin,
add printer ip to /etc/hosts.

FYI, you can use 'expect' to answer Brother console questions to further
automate the process.

I can post my expect script if you like. Your script would have
autoexpect bash linux-brprinter-installer $_printer
which would automagically answer all the installer questions.

Any time you want to automate your install you can start a new thread
and I can help you code a script.

[faeychild]

Post by Bit Twister
I can post my expect script if you like. Your script would have
autoexpect bash linux-brprinter-installer $_printer
which would automagically answer all the installer questions.
Any time you want to automate your install you can start a new thread
and I can help you code a script.

It presently "aint broke" and it wont change until Mageia 9.
Then we may be up for it again. But I have my notes and the magic URI
entry. Which is just an IP address and port number: but if you don't
know it, you're stuffed. Maybe it's fully automated and can be left
blank. I don't think I ever tried that,

I just sat there and yelled at MCC " What's a fscking URI you son of a
bitch"

One day when I'm feeling invincible I will trash the printer install and
play about with it. A learning experience. But not to be taken on during
the heat of a new release

regards

[William Unruh]

Post by faeychild

Post by Bit Twister
I can post my expect script if you like. Your script would have
autoexpect bash linux-brprinter-installer $_printer
which would automagically answer all the installer questions.
Any time you want to automate your install you can start a new thread
and I can help you code a script.

It presently "aint broke" and it wont change until Mageia 9.
Then we may be up for it again. But I have my notes and the magic URI
entry. Which is just an IP address and port number: but if you don't
know it, you're stuffed. Maybe it's fully automated and can be left
blank. I don't think I ever tried that,
I just sat there and yelled at MCC " What's a fscking URI you son of a
bitch"
One day when I'm feeling invincible I will trash the printer install and
play about with it. A learning experience. But not to be taken on during
the heat of a new release

Which is clearly why you should get the notes and script up and running
well before the heat of a new release arrives.

Post by faeychild
regards

[faeychild]

Post by William Unruh
Which is clearly why you should get the notes and script up and running
well before the heat of a new release arrives.

The wisdom of hindsight and the arrogance of pigheaded all clash to the
determent of me.

I've done it before and I'll do it again - lazy and stupid

regards

[TJ]

Post by faeychild

Post by Bit Twister
I can post my expect script if you like. Your script would have
         autoexpect bash linux-brprinter-installer $_printer
which would automagically answer all the installer questions.
Any time you want to automate your install you can start a new thread
and I can help you code a script.

It presently "aint broke" and it wont change until Mageia 9.
Then we may be up for it again. But I have my notes and the magic URI
entry. Which is just an IP address and port number: but if you don't
know it, you're stuffed. Maybe it's fully automated and can be left
blank. I don't think I ever tried that,
I just sat there and yelled at MCC " What's a fscking URI you son of a
bitch"
One day when I'm feeling invincible I will trash the printer install and
play about with it. A learning experience. But not to be taken on during
the heat of a new release
regards

Yelling at MCC never works. Trust me on this. Don't ask how I know, just
trust me.

More than you wanted to know about "URI:"

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

This was a month ago, but as I remember it the procedure I used for my
HP printer was this:

1) Used the printer's front panel menu/functions to establish a
connection to my network on my Linksys wireless router.
2) Booted into Mageia, ran MCC and from there asked to configure a
printer. This installed system-config-printer, which has
task-printing-hp as one of its dependencies.
3) When system-config-printer came up, clicked on "Add." The printer was
detected automatically. I clicked on it, then said to use the hplip
driver. Any needed information was gathered for me, and the system
installed both printer and scanner.

I used an alternative method on another machine where
system-config-printer and task-printing-hp had already been installed:

As root, I ran "hp-setup <network IP of the printer>" Again, I did not
have to provide any further information that I recall now, and both
printer and scanner were installed.

Easy-peasy.

TJ

[faeychild]

Post by TJ
Yelling at MCC never works. Trust me on this. Don't ask how I know, just
trust me.

I have noticed this. Is it hard of hearing or just uncaring

Post by TJ
More than you wanted to know about "URI:"
https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
This was a month ago, but as I remember it the procedure I used for my
1) Used the printer's front panel menu/functions to establish a
connection to my network on my Linksys wireless router.
2) Booted into Mageia, ran MCC and from there asked to configure a
printer. This installed system-config-printer, which has
task-printing-hp as one of its dependencies.
3) When system-config-printer came up, clicked on "Add." The printer was
detected automatically. I clicked on it, then said to use the hplip
driver. Any needed information was gathered for me, and the system
installed both printer and scanner.
I used an alternative method on another machine where
As root, I ran "hp-setup <network IP of the printer>" Again, I did not
have to provide any further information that I recall now, and both
printer and scanner were installed.

So you already knew of the secret guild code to run "hp-setup". You were
lucky. :-)
The hp task printing stuff must installed by default and I have Brother
printer

[TJ]

Post by faeychild

Post by TJ
As root, I ran "hp-setup <network IP of the printer>" Again, I did not
have to provide any further information that I recall now, and both
printer and scanner were installed.

So you already knew of the secret guild code to run "hp-setup". You were
lucky. :-)

Well, no. I just did my homework first. DuckDuckGo is my friend.

Post by faeychild
The hp task printing stuff must installed by default and I have  Brother
printer

Yes, in Mageia, task-printing-hp is a dependency of
system-config-printer. The reason has something to do with
auto-detecting HP printers. See
https://bugs.mageia.org/show_bug.cgi?id=9902
for a lively discussion about whether this should be necessary if one
doesn't own an HP printer.

TJ

[TJ]

Post by Vincent Coen
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

[faeychild]

Post by William Unruh
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. :-)

[William Unruh]

Post by William Unruh
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.

OK, I did c) and the system ran, until I rebooted. Then I got dumped
into the systemd error bin. Of course no explanation of why. Just ^D to
continue ( which just got my error again) or give password for root, and
look at journalctl. Nothing there to indicate what it was that caused
the problem, except scattered through the boot log were errors saying
that various directories could not be mounted. They were all nfs, and
trying to ping I discovered that the network had not come up. Now, the
system was all on the local machine, so why in the world would inability
to mount nfs crash the system? I finally went into /etc/fstab, commented
out all the nfs entries, and sure enough the boot finished. Logged in as
root, and the network now seemed to be up (why would the system try to
mount nfs files when the network was not up?)

So now I have to figure out how to harden the system Commenting out all
the nfs mounts is not an option, since they are needed for that computer
to carry out its job. I am now putting in noauto option into those nfs
mounts, but of course that means after the reboot I will have to by hand
mount all of those nfs mounts one by one, since noauto means that mount
-a does not work for those mounts. (would a clean install have been
better? No. because I would then have to recreate the /etc/fstab file
from scratch.)

Why in the world is the system not smart enough to ignore errors in nfs
mounted files, or set up the system to finish its boot and then try to
run mount -a after the network has come up?

It is things like that that make upgrading the horror that it is, and
make people very gun-shy about upgrading.

[David W. Hodgins]

Post by William Unruh
root, and the network now seemed to be up (why would the system try to
mount nfs files when the network was not up?)

Because the system has no way of knowing which mounts are critical from the
user's point of view.

Instead of commenting out the fstab entries, add the nofail option to every
entry that isn't critical. For example, I have a file system used for backups.
I don't want the system to drop to the recovery shell if it fails to mount, so
in fstab I have ...
LABEL=aback /aback ext4 defaults,noatime,nofail 1 2

It still gets mounted, but if it fails for any reason, it doesn't stop the boot.

And just fyi, this is not a new option. It was the same in Mageia 7. The only
difference is that now the network failed to come on that system.

Regards, Dave Hodgins

[William Unruh]

Post by David W. Hodgins

Post by William Unruh
root, and the network now seemed to be up (why would the system try to
mount nfs files when the network was not up?)

Because the system has no way of knowing which mounts are critical from the
user's point of view.
Instead of commenting out the fstab entries, add the nofail option to every
entry that isn't critical. For example, I have a file system used for backups.
I don't want the system to drop to the recovery shell if it fails to mount, so
in fstab I have ...
LABEL=aback /aback ext4 defaults,noatime,nofail 1 2

Hm. Every mount had nofail. Unfortunately on looking more closely two of
the entries had
.... nofail,nfs async,rw,rsize=8192,wsize=8192,soft,bg,intr 0 0

and
.... nofail,nfs rw,soft 0 0

Not quite the right place to put that option I guess.

Post by David W. Hodgins
It still gets mounted, but if it fails for any reason, it doesn't stop the boot.
And just fyi, this is not a new option. It was the same in Mageia 7. The only
difference is that now the network failed to come on that system.

Yes, which is why I had nofail already in the file. Doesn't help if you
do not put it in the right place.

Thanks for making me look again.

Post by David W. Hodgins
Regards, Dave Hodgins

[Bit Twister]

Post by William Unruh

Post by William Unruh
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.

OK, I did c) and the system ran, until I rebooted.

PS: I had a mysql update which clobbered my MythTV database.
My install_updates scripts now checks for any mysql updates and
stops mysqld if so.

Post by William Unruh
Then I got dumped
into the systemd error bin. Of course no explanation of why. Just ^D to
continue ( which just got my error again) or give password for root, and
look at journalctl. Nothing there to indicate what it was that caused
the problem, except scattered through the boot log were errors saying
that various directories could not be mounted. They were all nfs, and
trying to ping I discovered that the network had not come up.

Yep, been there done that, have the hat and T-shirt.

That is why having automated install scripts save time in the long run.
I have 4 major top level scripts that call all the other scripts.

At one time if the network failed systemd would consume a VERY large
amount of cpu trying to bring the network back up. It was so bad there
would be several seconds for each keyboard entry to echo at the root terminal.

I now run my ck_network script at the start and end of my top level scripts.
I also run in via hourly cron. Saves time wondering some network app is
no longer working.

That really came in handy when I was getting my network change scripts
working since I have configured my systems to use systemd-networkd service.

Post by William Unruh
Now, the
system was all on the local machine, so why in the world would inability
to mount nfs crash the system? I finally went into /etc/fstab, commented
out all the nfs entries, and sure enough the boot finished. Logged in as
root, and the network now seemed to be up (why would the system try to
mount nfs files when the network was not up?)
So now I have to figure out how to harden the system Commenting out all
the nfs mounts is not an option, since they are needed for that computer
to carry out its job. I am now putting in noauto option into those nfs
mounts, but of course that means after the reboot I will have to by hand
mount all of those nfs mounts one by one, since noauto means that mount
-a does not work for those mounts. (would a clean install have been
better? No. because I would then have to recreate the /etc/fstab file
from scratch.)

Hehehe, yup. I have a fix_fstab script to change the uuid to label and
add all partitions with labels. I use lsblk to get desired information
to populate fstab. Look at this snippet

$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT,SIZE,FSAVAIL,FSUSED,LABEL,PARTLABEL

sda disk 931.5G
├─sda2 part ext4 / 42G 23.1G 15.8G mga8 mga8
├─sda3 part ext4 40.8G mga7 mga7
├─sda4 part ext4 40.4G cauldron cauldron

sdb disk 931.5G
├─sdb1 part swap [SWAP] 8G swap swap
├─sdb2 part ext4 20G bk_up bk_up

]$ grep -E "mga8|swap|bk_up|ga7|cauldron" /etc/fstab
LABEL=mga8 / ext4 relatime,acl 1 1
PARTLABEL=swap swap swap defaults,nofail 0 0
LABEL=cauldron /cauldron ext4 users,noauto,relatime,acl 1 2
LABEL=bk_up /bk_up ext4 users,noauto,relatime,acl 1 2
LABEL=cauldron_bkup /cauldron_bkup ext4 users,noauto,relatime,acl 1 2


I use the label as the mount point. For any lurkers I used gparted to
set LABEL and PARTLABEL. gparted will not let you change/set values if
partition is mounted. Helps to have a rescue cd handy to work on a system
that is or needs to be offline. I user one from https://www.system-rescue.org/

Post by William Unruh
Why in the world is the system not smart enough to ignore errors in nfs
mounted files, or set up the system to finish its boot and then try to
run mount -a after the network has come up?

Careful about you want/ask for. Sounds like you need a custom systemd service.

Target node may not be up and you would still fail to boot.
Better to have a ck_mount script to do the mount -a and check for failures.

Post by William Unruh
It is things like that that make upgrading the horror that it is, and
make people very gun-shy about upgrading.

People doing upgrades better have a working fallback method just in case
the upgrade is no good or fails.

I do clean installs in a new partition. Worse comes to worse I can boot
previous release/install. Also is handy for comparing config files between
releases for changes.