Hello.
My laptop has a core i5 and have noted intel_pstate loaded the driver with the installation of opensuse 13.1. If however on my desktop pc I upgraded from opensuse 12.3 to 13.1, it has a quad core Q9450 and the loaded driver is acpi.
What use acpi and not intel_pstate because it was an upgrade and keeps the old configuration or processor that does not support intel_pstate?
Thanks.
Can anyone tell me the technical difference between an upgrade and a clean install?
If I upgrade the system, the previous setting is retained or innovations apply?
One of the main points of doing an upgrade instead of a fresh install is to retain the configuration, no? lol!
But actually it depends on the particular package whether a config file will be kept or replaced with the new one.
Normally, config files that have been changed by the administrator will be kept, and the new one will be installed as xxx.rpmnew. So the administrator can later compare the two and update the configuration if necessary.
In some cases, the existing config file is replaced unconditionally. If it has been changed, it will be backed up as xxx.rpmsave.
Unchanged files will get overwritten unconditionally IIANM without a backup.
You can run “rcrpmconfigcheck” to get a list of all those xxx.rpmnew and xxx.rpmsave files on your system, to get an overview what you should consider to look at.
And the user’s configuration (i.e. stuff in /home), is not touched at all by an upgrade.
I have no idea about your particular driver “problem”, but the drivers to load are normally determined by the kernel dynamically and are not configured anywhere.
Although at least some of them have to be in the initrd, so it might depend on how (and when) the initrd is created. There’s /etc/sysconfig/kernel for specifying particular modules to load/add to the initrd. (and no, this file is not changed during an upgrade normally)
So maybe compare this particular file between the two systems.
OTOH, as you compare two completely different systems with completely different hardware, it’s of course no surprise that different modules might be loaded.
Might not be related to the upgrade at all.
Example, if a version of opensuse loads the acpi driver to control the processor power and a new drivers intel_pstate more efficient than the previous is published with the new version of opensuse, that new drivers are applied to update the version opensuse or need a clean install to use it?
No.
There are absolutely no drivers “applied” during update and during clean installation neither.
All of the drivers (except some third party stuff) are included in the kernel package, and normally the kernel decides automatically during boot which modules to load, as I wrote already.
As already indicated, there are ways to tell the kernel explicitely which driver(s) to load/use, but this is not done by the installer normally AFAIK.
On 2014-10-26 13:06, wolfi323 wrote:
> You can run “rcrpmconfigcheck” to get a list of all those xxx.rpmnew and
> xxx.rpmsave files on your system, to get an overview what you should
> consider to look at.
It is FUNDAMENTAL to check that script output after an upgrade (and even
after updates).
The script should run automatically on boots, and you can read the
output on the file “/var/adm/rpmconfigcheck”.
(I modified the script so that it mails me)
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-10-27 14:26, jonatanpm wrote:
>
> Example, if a version of opensuse loads the acpi driver to control the
> processor power and a new drivers intel_pstate more efficient than the
> previous is published with the new version of opensuse, that new drivers
> are applied to update the version opensuse or need a clean install to
> use it?
Read the referred script output first, or paste it here, then we’ll comment.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
No it is not, at least not by default.
You would have to enable it manually.
On 2014-10-27 17:16, wolfi323 wrote:
>
> robin_listas;2671434 Wrote:
>> OThe script should run automatically on boots, and you can read the
>> output on the file “/var/adm/rpmconfigcheck”.
> No it is not, at least not by default.
> You would have to enable it manually.
Are you sure?
I have seen it running for many years. Probably more than a decade.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes. Definitely on fresh 13.1 and 13.2 installations, but I think already in at least a few earlier versions.
I remember disabling it manually years ago here because it seriously prolonged the boot process on my system.
But I’m not sure whether I enabled it manually first back then or not.
IOW, I cannot tell when this has changed, if it ever was enabled by default.
I have seen it running for many years. Probably more than a decade.
Well, it doesn’t get disabled automatically on upgrades I suppose.
So if it ever was enabled (either manually or because that was the default back then) it stays enabled, unless you manually disable it.
On 2014-10-27 18:56, wolfi323 wrote:
>
> robin_listas;2671462 Wrote:
>> Are you sure?
> Yes. Definitely on fresh 13.1 and 13.2 installations, but I think
> already in at least a few earlier versions.
Next install I do, I’ll check.
> I remember disabling it manually years ago here because it seriously
> prolonged the boot process on my system.
Trick:
/etc/init.d/rpmconfigcheck:
case "$1" in
start|restart|try-restart|reload|force-reload)
if test -s $packages -a \( ! -e $configcheckfile -o -s $configcheckfile -o ! $packages -ot $configcheckfile \) ; then
echo "CER: preloading database in cache"
cp /var/lib/rpm/Packages /dev/null
cp /var/lib/rpm/Basenames /dev/null
cp /var/lib/rpm/Providename /dev/null
cp /var/lib/rpm/Requirename /dev/null
echo -n "Searching for unresolved configuration files"
if test ! -e $configcheckfile -o ! $packages -ot $configcheckfile ; then
test -e $configcheckfile && mv -f $configcheckfile $configcheckfile.old
rpm -qalc | sort | perl -lne '-e "$_.rpmnew" and print "$_.rpmnew"; -e "$_.rpmorig" and print "$_.rpmorig"; -e "$_.rpmsave" and print "$_.rpmsave"' > $configcheckfile
else
It goes from a minute and a half to under 5 seconds total time, in my system.
There is a bugzilla about this.
> But I’m not sure whether I enabled it manually first back then or not.
> IOW, I cannot tell when this has changed, if it ever was enabled by
> default.
It was ‘on’ by default, I’m sure of that, because that’s how I discovered it.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I know. 
Haven’t tried that script you posted here, but that trick to speed up rpm -qa that was posted in the mailinglist thread back then did not make any difference on my system.
PS: tried the script now, but the cp commands just take as long as running the complete rpmconfigcheck without them.
So no advantage here, the actual rpmconfigcheck isn’t sped up either AFAICT, so actually a regression. But that was just a quick test now based on perception, I’ll have to time it as well tomorrow…
Might depend on the filesystem in use though (reiserfs here) and the hardware.
> But I’m not sure whether I enabled it manually first back then or not.
> IOW, I cannot tell when this has changed, if it ever was enabled by
> default.
It was ‘on’ by default, I’m sure of that, because that’s how I discovered it.
I supposed that, but I cannot say when it was last ‘on’ by default.
Maybe that changed with the switch to systemd? Although IIRC it was already off when I freshly installed some 11.x version.
On 2014-10-27 22:06, wolfi323 wrote:
> robin_listas;2671502 Wrote:
> Haven’t tried that script you posted here, but that trick to speed up
> rpm -qa that was posted in the mailinglist thread back then did not make
> any difference on my system.
Curious. Or are you using an SSD disk?
It is supposed to make a difference for machines where it is very slow,
and that have rotating disks. If it doesn’t take over, say, 12 seconds,
there will not be difference.
(What I posted is just a modification to the existing script)
> Might depend on the filesystem in use though (reiserfs here) and the
> hardware.
Ah, reiserfs? Dunno, perhaps it does.
Ah, I forgot: if you test the modification after having run the
unmodified script, there is no difference because it is already cached.
You have to empty the cache first.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
No.
An 11 years old 5400 RPM rotating disk.
It is supposed to make a difference for machines where it is very slow,
and that have rotating disks. If it doesn’t take over, say, 12 seconds,
there will not be difference.
It takes well over 12 seconds here.
(What I posted is just a modification to the existing script)
Yes, just the cp commands are added to “copy” the database files to the kernel buffers AIUI.
I measured it now, and it seems I was wrong. (I didn’t remember it taking that long :P)
The original:
amiga:/home/wolfi # time rcrpmconfigcheck
Searching for unresolved configuration files done
Please check the following files (see /var/adm/rpmconfigcheck):
/etc/localtime.rpmnew
/etc/xinetd.d/vnc.rpmnew
/usr/share/kde4/config/kdm/kdmrc.rpmnew
real 2m41.646s
user 0m9.934s
sys 0m2.882s
The modified version:
amiga:/home/wolfi # time rcrpmconfigcheck.new
CER: preloading database in cache
Searching for unresolved configuration files done
Please check the following files (see /var/adm/rpmconfigcheck):
/etc/localtime.rpmnew
/etc/xinetd.d/vnc.rpmnew
/usr/share/kde4/config/kdm/kdmrc.rpmnew
real 1m2.438s
user 0m5.574s
sys 0m2.547s
(both times run after a reboot, logging into KDE and waiting until everything has settled down)
So the modified version is actually more than twice at fast, but it’s still not something I would like to run on every boot.
Personally for me I don’t see a point anyway. I just run it manually from time to time, especially after upgrades (for standard updates it shouldn’t really be critical anyway, depending on your repos of course).
> Might depend on the filesystem in use though (reiserfs here) and the
> hardware.
Ah, reiserfs? Dunno, perhaps it does.
Ah, I forgot: if you test the modification after having run the
unmodified script, there is no difference because it is already cached.
You have to empty the cache first.
If you run it a second time, the script actually does nothing (it only shows the contents of /var/adm/rpmconfigcheck). It checks whether the RPM database has changed since the last run (the second “if” in the script snippet you posted).
And the speed-up also depends on how big your RPM database is and how fragmented the files are, I’d say.
On 2014-10-31 14:26, wolfi323 wrote:
> I measured it now, and it seems I was wrong. (I didn’t remember it
> taking that long :P)
LOL.
> The original:
> real 2m41.646s
> The modified version:
> real 1m2.438s
Takes half the time.
> (both times run after a reboot, logging into KDE and waiting until
> everything has settled down)
There is an echo something to somewhere in proc that erases the cache,
you do not need to reboot. I don’t remember it offhand, but it was
posted in that mail list thread.
>
> So the modified version is actually more than twice at fast, but it’s
> still not something I would like to run on every boot.
Understandable. It speeds of to 4 or 6 seconds here, total time. Maybe
you don’t have that much RAM?
> Personally for me I don’t see a point anyway. I just run it manually
> from time to time, especially after upgrades (for standard updates it
> shouldn’t really be critical anyway, depending on your repos of course).
I have it email me the changes, as a nagging reminder 
>>> Might depend on the filesystem in use though (reiserfs here) and the
>>> hardware.
>>
>> Ah, reiserfs? Dunno, perhaps it does.
>>
>> Ah, I forgot: if you test the modification after having run the
>> unmodified script, there is no difference because it is already cached.
>> You have to empty the cache first.
>>
> If you run it a second time, the script actually does nothing (it only
> shows the contents of /var/adm/rpmconfigcheck). It checks whether the
> RPM database has changed since the last run (the second “if” in the
> script snippet you posted).
Ah, true. In my tests I also erased the var file above 
> And the speed-up also depends on how big your RPM database is and how
> fragmented the files are, I’d say.
A bit. On small and not fragmented databases it runs faster without
doing anything.
File fragmentation doesn’t affect much, though. The issue is that the
database read is not linear, as it traverses field by field of the
database. It is the database engine that is not optimized for “heavy”
usage. It was designed when memory was scarce, I’d guess, so they did
not consider to cache it in ram first.
Traversing the systemd log in disk has the same issue. Or very similar.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)