Mageia forum

Something else I discovered after upgrading from Mageia 1 to Mageia 2 is an enormous increase of time to boot and - even worse - to shutdown. I just measured both times while a single reboot:

shutdown: 5:45 minutes
boot: 3:45 minutes

Both was much quicker with Mageia 1. Unfortunately, I do not even get messages about what is going on during shutdown. While booting after 1:15 minutes the system hangs for 35 seconds after the message "Started Show Plymouth Boot Screen"! And when finally the graphical login starts (nvidia) the driver seems to assume a much bigger monitor because from "mageia" in the lower right corner I can read only "mag".

Per the Mageia 2 Errata:

Software Issues - Base System:
After installation or upgrade, dracut will generate a large, generic initrd. This is needed due to being unable to use udev to query for device information. After initial boot, you can recreate your initrd via "dracut -f" to get a more customized, smaller initrd.

I already created a smaller initrd but it does not affect the time required to boot. And the last time I tried to shutdown via reboot I decided to do a hardware reset after more than 10 minutes watching "mageia bubbles" to disappear. Three of them were still left...

I did have a similar problem at one time, and I ran 'rpm -qa | sort | xargs -n 1 -t rpm -V &> ~/Desktop/rpm-Va.txt | exit' in a konsole, and found several packages that were not correctly installed. I reinstalled the necessary packages (urpmi <package name> --replacepkgs) and all was well...... I am guessing there are some X packages that got messed up during install.

Once the rpm-Va.txt file is created, run 'Desktop/rpm-Va.txt | grep missing' and it will show what files/folders are missing. Then it's a matter of finding what packages have those files/folders.

I guess you meant

Code: Select all

cat ~/Desktop/rpm-Va.txt | grep missing

instead of

Code: Select all

/Desktop/rpm-Va.txt | grep missing

?

No files were missing.

Last resort is to do some investigative work and review logs. I would start with you dmesg log and prcsys.log file under /var/log. There has to be a logical explanation for the delay in booting and shutting down. Let me ask you this - what about within those times? Other than booting and shutting down, does your machine function normally? Or is there a general slowness in how the whole machine functions?

User7 - you are correct!! My bad!

Yes, there are some strange network delay/mounting problems with NFS: https://forums.mageia.org/en/viewtopic.php?f=7&t=2633

Also, there is a huge amount of "martian sources" on eth0 and eth1. But NFS is mounted via eth4.

What if you commented out the NFS mounts and tried booting without the NFS shares auto-mounted? I'm wondering because if you are continuing to have NFS issues, remove the cuprit to fix some of your other issues and later try fixing your MFS mounts/configuration. Of course, I also noticed that you have a heck of a lot of issues in all the threads and wondering if you should backup your data, wipe the drives and start a brand new installation.

sglafata wrote:I did have a similar problem at one time, and I ran 'rpm -qa | sort | xargs -n 1 -t rpm -V &> ~/Desktop/rpm-Va.txt | exit' in a konsole, and found several packages that were not correctly installed.

Too complicated, just do

Code: Select all

rpm -Va | grep missing

no need to save this into a file for that. Also pay attention to the fact that it's only called "missing" in english, in other locales this is localized, so to be sure, just use

Code: Select all

LC_ALL=C rpm -Va | grep missing

user7 wrote:I guess you meant

Code: Select all

cat ~/Desktop/rpm-Va.txt | grep missing

instead of

Code: Select all

/Desktop/rpm-Va.txt | grep missing

?

Well, actually both would be working if used properly, but both are a useless use of cat. Just do

Code: Select all

grep string /path/to/some/file

You may want to read http://partmaps.org/era/unix/award.html

sglafata wrote:What if you commented out the NFS mounts and tried booting without the NFS shares auto-mounted? I'm wondering because if you are continuing to have NFS issues, remove the cuprit to fix some of your other issues and later try fixing your MFS mounts/configuration. Of course, I also noticed that you have a heck of a lot of issues in all the threads and wondering if you should backup your data, wipe the drives and start a brand new installation.

I was lucky and could figure the biggest problem: On my system NFS shares use eth4 and Samba shares use eth3 with both networks having different IP segments. Both directories (/data1, /data2) are shared via NFS and Samba which works very well. The problem appeared only if a virtual machine (vmwareplayer) was used. This virtual machine used vmnet3 to connect to the same Samba shares with vmnet3 having an IP in the same segment like eth3. As long as vmnet3 is not enabled everything is OK.

So, in my very special case I had to change /etc/fstab as mentioned before and to remove the virtual vmnet3 adapter. I have changed the virtual machine to use a bridged network instead of a NAT network. And everything is fine. It also solves topic https://forums.mageia.org/en/viewtopic.php?f=7&t=2633

The configuration of my workstation is very special. That is why I did not like the idea to start a brand new installation. But it could have saved a lot of time if I decided to do so immediately. Maybe next time...