Mageia forum

Following the instructions in the Wiki for upgrading Mageia2 to Mageia3 as follows:

Code: Select all

su
urpmi.removemedia -a
urpmi.addmedia --distrib <mirror_url>  with two mirrors attempted one in Netherlands, the other in Germany
urpmi --replacefiles --auto-update --auto

The system successfully validates the repositories:

Code: Select all

medium "Core Release" is up-to-date
medium "Core Updates" is up-to-date
medium "Core Updates Testing" is up-to-date
medium "Core Backports" is up-to-date
medium "Core Backports Testing" is up-to-date
medium "Nonfree Release" is up-to-date
medium "Nonfree Updates" is up-to-date
medium "Nonfree Updates Testing" is up-to-date
medium "Nonfree Backports" is up-to-date
medium "Nonfree Backports Testing" is up-to-date
medium "Tainted Release" is up-to-date
medium "Tainted Updates" is up-to-date
medium "Tainted Updates Testing" is up-to-date
medium "Tainted Backports" is up-to-date
medium "Tainted Backports Testing" is up-to-date
medium "Core 32bit Release" is up-to-date
medium "Core 32bit Updates" is up-to-date
medium "Core 32bit Backports" is up-to-date


The system then attempts to install ~ 150 rpms.

The install fails with the following error message:

Code: Select all

installing aria2-1.16.3-1.mga3.x86_64.rpm from /var/cache/urpmi/rpms
Installation failed:    rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-2.1.9-20.mga3.x86_64
        perl-base >= 2:5.16.2 is needed by perl-MDV-Distribconf-4.02-7.mga3.noarch
        librpm.so.3()(64bit) is needed by deltarpm-3.5git-6.mga3.x86_64
        librpmio.so.3()(64bit) is needed by deltarpm-3.5git-6.mga3.x86_64
        libc.so.6(GLIBC_2.15)(64bit) is needed by aria2-1.16.3-1.mga3.x86_64
        libc.so.6(GLIBC_2.17)(64bit) is needed by aria2-1.16.3-1.mga3.x86_64

So it appears that, at the moment, something essential is missing in the repositories.

INDY

Which wiki page did you use?

First you have to install mageia-prepare-upgrade (+ dracut probably) from Core Updates Testing of Mageia 2. Then you have to reboot and choose from grub menu to prepare the system for upgrade. After that you can add back cauldron medias and run the upgrade.

You should use https://wiki.mageia.org/en/Feature:UsrM ... ease_Notes

You know? That is very nice!

Now, why doesn't someone change the directions given in the upgrade page from which the directions I followed(which are wrong) emanated?

Now, why doesn't someone, throw out with the bath water, this whole concept borrowed from Fedora, because while I got through this problem upgrading
with the aid of the DVD, I came smack against incompatibilities between the use of directories by Mg3 and BrlCad, and other programs.

While we are at it, keeping in mind that my relationship with UNIX/XENIX/SUNOS/BSD/LINUX goes back to Sys3 some 40 years ago.

It seems that you ladies and gentlemen have inventive minds. It seems that you have been looking to IMPROVE THINGS!

Improvement is generally a good thing, except when it ruins simple working fundamentals... . .

Take fstab for example: Back in the old days, we thought /dev/Yd# was pretty slick; it covered /dev/fd0 /dev/hd0 /dev/sdx /dev/srx etc.

We could unambiguously address any given device, and we could clone systems with the same architecture, no sweat.

But, being inventive, some nameless person decided to complicate things: with UUID=(lksjdf;sadflkjsa;klsdjf;asdlfkjsd;l) but if one builds a system
with several identically partitioned drives, one has multiple partitions with the same.... you guessed it.... UUID's !!

Then: we have the /etc/alternatives feature;

WIth Java alone, I count 4 back and forth symbolic links between /usr and /etc, just to define the default version of java in service!

Then: we have the urpmi/rpmDrake feature:
Numerous sym links between /usr and /var here.

The above obviates the utility of placing / /usr /var and /opt in separate partitions. There is no way one can bring back a working system unless
the totality is brought back.

Guess, backing up and restoring a Mgx system is not a priority????

How about putting your inventiveness into the following projects?

1. Separate the /usr /etc and /var systems by eliminating the symlinks
2. Create a utility for dummies that backs up and restores a working Mgx system. Make a command line version for us geeks. AND DOCUMENT IT!
NOT IN SOME OBSCURE FORUM POST BUT IN THE MAN PAGE!
3. Require that all applications be statically linked. Yep, statically linked. No dlls, period. Put each one of them in a sub directory of /usr/local.
Link the master routine to it's namesake in /usr/local/bin
4. The above means that the only things in /usr/bin are system utiities
5. /sys of course, is where you put the system things, don't you?

Someone, out there, is going to scream about memory constraints. Really? I just bought 4 1Tb 7200rpm HGST HDDs for $89 ea. 8Gb Ram for $60, DDR3 - 1333 no less.

You need and want fast clean, tight code? Use C! Forget C#, C++, use C, K & R vanilla C! Need memory? That's what malloc and free are for!
Don't forget the garbage collection!

You want to think, great thoughts, build great things, without the drudgery of C and X11? Back in the 80s, we had CASE and GUI tools that took
designs directly to code! They came on Floppy! They, in the hands of the knowledgeable, built great small tight GUI apps, easily debugged because we
had the design specifics, like call structure, argument lists (we used to require all data be passed in the arg list, including tables), functionality, etc.

Now, how do I get rid of UUIDs?

INDY

goprisko wrote:Now, why doesn't someone change the directions given in the upgrade page from which the directions I followed(which are wrong) emanated?

Well, why don't you ask beforehand? Also, which directions on the wiki did you follow?
Apart from that, it's a wiki, so anybody with an account can edit or improve pages ...


For alternatives, just use the tool instead of manually changing the symlinks. The tool is alternatives or update-alternatives,
and gives an easy selection if there are multiple choices for one facility. Just select another, e.g. with update-alternatives --config java
and be done with it.

As pointed out, better ask beforehand instead of just complaining for the additional work, if you don't know how to do it the proper way.

For your backup question, use something like redobackup, easy ...

For the statically linked applications, that's just insane. For security updates, instead of just updating a shared library which e.g. dozens of programs use,
we would need to rebuild those dozens of applications instead of just one library. Please provide some factual advantages what statical linked programs
would achieve.


And for /sys, that really made me laugh. It's a pseudo-filesystem, representing internal kernel information and settings via sysfs.
You may have to update your unix skills, or at least learn some more recent linux additions.
Check e.g. http://en.wikipedia.org/wiki/Sysfs

Also, on some unices what you complain about (symlinks from /bin, /sbin, and /lib or /lib64 to /usr/...) this already exists since years.

goprisko wrote:Now, how do I get rid of UUIDs?

You don't get rid of them. They are really useful. That doesn't mean you have to use them,
you can still use device names or volume labels as you wish. Sorry, but i don't comprehend what your actual problem is.
Out of curiosity, please show an example if you partition a drive where you got the same UUIDs.

The same UUIDs are to be found across several cloned drives. Specifically where PartImage was used to backup data.
Regarding Security holes and statically linked packages, I don't buy it. If things were done the UNIX way with small tight utilities linked
into more powerful systems, and if the system was read only, with encrypted checksums on all files, the kernel could match the checksum against what is running on a periodic basis, and replace the errant file from ROM.

INDY

If you want to make Mageia more powerful and secure, patches are always welcome ...

Apart from this, this has nothing more to do with the initial topic. Please only one problem per thread. If you want to discuss
stuff abouth god and and the world and why unix is so much better, please use another subforum for that: viewforum.php?f=5

goprisko wrote:The same UUIDs are to be found across several cloned drives.

If you cloned your drives then you should just change the UUID. For ext3/4 partitions it should work like this: tune2fs /dev/sdXY -U $(uuidgen). After that you can see the new UUID with blkid /dev/sdXY.

I found a better way:

I removed all references to UUIDs in boot & grub & fstab, replacing them with LABEL=yyyysssssxxxxx

Now, I have a solid way to reference partitions in my 5 drive system, with identifiers immediately and obviously connected to specific partitions.
AND
The system boots properly and fast.

Now, to other upgrading issues:

Earlier, I was forced to go outside the Mageia repositories for applications critical to my needs:
CAD, Scanning of slides and film, processing RAW Image Files, Color Correcting Images, Office software

LibreOffice 4 is a case in point. The Mg2 upgrade to LO.3.5 involves pulling packages including rpm and many system libraries.
Yet, when one goes to the LO repository, fetches the package, and installs it, no such changes to the basic system are necessary.
This tells me that, in bringing Linux to the functional level Mg2 represents, the UNIX client - server model was not maintained. Instead the Microsoft monolithic model was introduced.
It was well known to us in the Systems Engineering Community, that Microsoft's model was drastically inferior to the UNIX client-server model.
In the UNIX model, all applications use system services for printing, input, output, memory management, backup, restore, and other purposes.
Applications do not, and are not allowed to access system level functions except through the API. Applications are assigned their own address space by the
kernel, and those which violate this, are memfaulted, and terminated.

Earlier, I specifically mentioned that applications should be statically linked. This was denigrated in favor of the Microsoft model. In the UNIX model
applications can and often are broken into multiple executables, with VueScan being a case in point. Yes, it is 12 Mb, vs Xsane at 0.6 Mb, but that's
only the tip of this iceberg:
bash-4.2|bash
desktop-common-data|desktop-common-data-2012.0
glibc-2.16.90|glibc
lib64glib2.0_0-2.34.1|lib64glib2.0_0
lib64gobject2.0_0-2.34.1|lib64glib2.0_0
lib64gtk+-x11-2.0_0|lib64gtk+2.0_0-2.24.13
lib64jpeg8-1.2.1|lib64jpeg8
lib64lcms1|lib64lcms1-1.19
lib64png15_15|lib64png15-1.5.12
lib64sane1|lib64sane1-1.0.23
lib64tiff5-4.0.2|lib64tiff5
lib64z1-1.2.7|lib64uClibc-zlib1|lib64zlib1
xsane

Of no small matter is the fact that Vuescan does a much better job of scanning slides and film than xsane, unless one is willing to spend days adjusting parameters.

Of no other small matter is the fact that Vuescan can be placed in it's own directory in /opt and obviously linked to /usr/local/lib.

Since the /opt links are obvious, it is not a problem to police them following a restore from backup media.

Since the app is monolithic, if there is something wrong with it, one need only upgrade it, not the whole system. Likewise, if the system needs upgrading
the apps don't. As long as the API remains intact, the apps work. I, for example have migrated Vuescan from Mdk2008 -> Mg2 by simply installing the
bin in /opt and linking it to /usr/local/bin and updating the Kde menu system each time.

To summarize:
My post directly concerns issues with updating Mg2 -> Mg3. My issues concern the architecture of the system, which affect it's maintainability, and
robustness. My issues no longer are concerned with functionality. Mg2 solved the functionality issues of Linux, hands down. It's functional to the point
it is a direct and complete replacement on the desktop for any Microsoft OS.

My issue specifically is that in progressing to this point, a house that jack built has been created, and gerrymandered as it is, errors cascade through it,
making debugging a formidable task. I have been, and below will use specific examples of this. The solution is to return to the UNIX client-server model
for applications, and to enforce applications using system resources through the API, and only the API, and to enforce boundaries around each application, so any given app in totality can be contained within it's own bin, which is linked to /usr/local/bin. That's right /usr/local/bin. Only system binaries belong
in /usr/bin. Specifically Xsane is an app. LibreOffice is a suite of apps. cp, dd, tar, dar, etc; are system utilities. Apps in /usr/local/bin Utilities in /usr/bin
Apps call utilities through the API. If you have a security problem in any given utility, you fix that, and load the new version without causing cascade replacement of hundreds of other binaries.

Once you implement this discipline, you will find your job of debugging much easier.

Now to the last example: /etc/alternatives & Java:

When /etc was created it was a catchall of items required by system binaries at various times. Fstab is a case in point. Fstab is used during boot to
tell the kernel where to find the drives, and is used during operation to grant/deny mounting permissions to users, and to specify mounting attributes. It is a table, originally hand built, later built with system utilities. Were alternatives embodied in such a table, I'd have no issues here. But alternatives was
implemented via symlinks, as follows:

Directory Sym Link
/etc/alternatives/java -> /usr/lib/jvm/default/
/usr/lib/jvm/default -> /etc/alternatives/default -> /usr/java/default -> /usr/java/latest -> /usr/java/jre1.7.0_21
/usr/lib/jvm/java -> /etc/alternatives/java_sdk/
Now, it is really nice that a utility maintains this, but: This utility doesn't have the job of maintaining the system, including restoring it in the event of disaster. I do.

Since the alternatives are alternatives for applications such as java, and utilities such as gcc, I'd prefer /usr/alternatives. This way, the symlinks are in one file system and restoring that filesystem restores the links.

Java could look like this:
/usr/alternatives/java/default -> /usr/java/jre1.7.0_21
/usr/alternatives/java/java_sdk_1.6.0 -> /usr/java/java-1.6.0-openjdk.x86_64/

Much clearer. Easier to debug. Easier to maintain.

INDY

Topic closed by moderator.

Goprisko, i would strongly advise differentiating your topics.
Pulling in more and more input works deviating in this case.

Thank you!!!