on Freitag, 18. April 2008, jdd wrote:
Christian Boltz a écrit :
OK, I have to check some *.rpmnew or *.rpmorig
files after the
may be a central report with links to such file? I always wonder
where files where modified and where there was none. knowing when the
original file is backed up or when it's let alone and a sample file
written is also not obvious, so the use of a central log
There is even an initscript (/etc/init.d/rpmconfigcheck) which reports
them - but hidden behind the nice splash screen ;-)
Maybe the better solution would be a mail to root?
I would also like to propose moving this script to another place, for
example SuSEconfig. Running it at each boot is pointless.
usually appear if a config file was manually changed,
which means the user/admin hopefully knows what he is doing.
but may have done this in a hurry and forgot about that...
People will find the *.rpm* files as soon as some configuration differs
from what they have set up and expect *g*
installation / update work, at least for me ;-)
remember I can't boot a cd :-(. I can only reinstall a fresh 10.2
system and start again... or boot a rescue system
Booting with a grub entry could be a solution for you. The details are
somewhere in the wiki - or just ask for an example menu.list section.
one thing I don't understand: upgrade system say
it must be done from
booting a cd/dvd, but we can update kernels, so why? I can update and
I also wonder about this...
I even had a
copy of the system running in a chroot, so the
websites were available during the update ;-) (with a minor
downtime for rebooting, mounting everything and starting the
services in the chroot). 
?? an you chroot, install a new system (for example 11)? how?
I could install in virtualbox, but the power loss is high
It seems I should add more details, step by step ;-)
- recommended: have some spare partition(s) available. If none is
available, a directory with enough space will do also.
- mount this partition as /oldsys (and /oldsys/var etc. if you want to
use multiple partitions)
- create an fstab entry for /oldsys (and /oldsys/var etc.)
- copy most parts of the system into /oldsys. Leave out /srv and /home
and mount --bind it later.
mount --bind of /var/lib/mysql is a bit problematic in case the
rpm %post restarts mysql. The better solution is probably to copy it
to the new system after the end of the installation, before reboot.
- create a bootloader entry for the /oldsys partition - in case
something goes wrong, you can go back faster.
- also create a bootloader entry for network installation, and activate
it with grubonce.
- boot to the installation
- start YaST
- let it mount all partitions
- mount --bind /proc, /sys and /dev into /oldsys
- chroot /oldsys
- rcapache2 start :-)
- run the installation
- remember to copy /oldsys/var/lib/mysql to the new system
Disclaimer: No warranty for completeness (I just wrote this out of my
mind) - but people who run a rootserver should notice if something is
missing or wrong and be able to do it right ;-)
That said: The
easier way to go would be updating the running
system. Basically this means that "zypper dup" and its graphical
variant (which is now called "Factory update") should be officially
supported for distribution updates.
If I understand well, this is great!
I hope so ;-)
Can someone with enough technical knownledge comment about it, please?
In its default setup, Windows XP on the Internet amounts to a car parked
in a bad part of town, with the doors unlocked, the key in the ignition
and a Post-It note on the dashboard saying, "Please don't steal this".
[Washington Post, 23.8.2003]
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org