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.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

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 ****************



--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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


SEEN-BY: 25/0 21 250/0 1 2 3 4 5 6 7 10 21 263/0 301/1

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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 =


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)

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 ****************

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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



--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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.


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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.


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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:
=20

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 =20

=20
Timeshift.

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

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

By default, it does not include /home =E2=80=94 the developer recommends us= ing
other tools for backing up /home =E2=80=94 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.

--=20
With respect,
=3D Aragorn =3D


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Thu, 31 Mar 2022 13:35:34 +1100, 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.

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.








--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 1/4/22 01:50, TJ wrote:

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.


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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 1/4/22 02:44, Bit Twister wrote:

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

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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2022-03-31, faeychild <faeychild@nomail.afraid.org> wrote:

On 1/4/22 02:44, Bit Twister wrote:

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.

regards

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2022-03-30, William Unruh <unruh@invalid.ca> wrote:

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.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Thu, 31 Mar 2022 21:56:59 -0400, William Unruh <unruh@invalid.ca> wrote:

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 1/4/22 12:43, William Unruh wrote:

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


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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 31/3/22 01:42, Aragorn wrote:

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 :-)


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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2022-04-01, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Thu, 31 Mar 2022 21:56:59 -0400, William Unruh <unruh@invalid.ca> wrote:

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.

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.

Regards, Dave Hodgins

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Fri, 1 Apr 2022 01:56:59 -0000 (UTC), William Unruh wrote:

On 2022-03-30, William Unruh <unruh@invalid.ca> wrote:

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.

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.

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/

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.

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.



--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Fri, 1 Apr 2022 08:58:03 +1100, faeychild wrote:

On 1/4/22 01:50, TJ wrote:

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.

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.

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.


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 01.04.2022 at 14:21, faeychild scribbled:

On 31/3/22 01:42, Aragorn wrote:
=20

Timeshift.

=20
I've had a quick look, Aragorn
=20
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 =E2=80=94 for _making_ backups
only, of course =E2=80=94 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 =E2=80=94 and it's important to know this =E2=80=94 the medium upo=
n which it
must store its backups is not set in the configuration as a directory/mountpoint, but as a _block device_ =E2=80=94 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.

should I read the man page :-)

Always. :p=20


--=20
With respect,
=3D Aragorn =3D


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)

On 3/31/22 18:27, faeychild wrote:

On 1/4/22 02:44, Bit Twister wrote:

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 1/4/22 16:05, Bit Twister wrote:

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

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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2/4/22 00:24, TJ wrote:

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

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.

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


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


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 4/1/22 15:38, faeychild wrote:

On 2/4/22 00:24, TJ wrote:

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.

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2022-03-30, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

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

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.

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

On 2022-03-30, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

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

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.


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 09 Apr 2022 18:06:48 -0400, William Unruh <unruh@invalid.ca> wrote:

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2022-04-09, Bit Twister <BitTwister@mouse-potato.com> wrote:

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

On 2022-03-30, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

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

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.

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?


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 09 Apr 2022 18:55:44 -0400, William Unruh <unruh@invalid.ca> wrote:

On 2022-04-09, Bit Twister <BitTwister@mouse-potato.com> wrote:

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

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

<snip>

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.

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.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2022-04-09, Bit Twister <BitTwister@mouse-potato.com> wrote:

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

<snip>

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)

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.



--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 09 Apr 2022 21:32:29 -0400, William Unruh <unruh@invalid.ca> wrote:

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

That is not my experience.

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2022-04-10, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Sat, 09 Apr 2022 21:32:29 -0400, William Unruh <unruh@invalid.ca> wrote:

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.

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 10 Apr 2022 01:32:29 -0000 (UTC), William Unruh wrote:

On 2022-04-09, Bit Twister <BitTwister@mouse-potato.com> wrote:

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

<snip>

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)

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.


--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 10 Apr 2022 07:33:59 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:

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

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)