Re-configure your X using the below commands:
# Xorg -configure
# mv /root/xorg.conf.new /etc/X11/xorg.conf
After this switch to runlevel 5 and check if that works.
Re-configure your X using the below commands:
# Xorg -configure
# mv /root/xorg.conf.new /etc/X11/xorg.conf
After this switch to runlevel 5 and check if that works.
Vincent_5 wrote:Attach are the error from messages for your referrence, kindly help ??
That is a stack trace, so it looks like gdm is crashing.
Reading the stack trace from the bottom upwards: at #23 there is the main() function of gdm, where the gdm originally started. #22 - #20 seems to indicate that gdm was just about to set up the "greeter" (i.e. the GDM login prompt).
Lines #19 .. #11 are related to libgobject, so probably handling some Gnome internal stuff; however #15 tells us it's about the libgnomekbdui library and the gkbd_indicator_new() function, so it appears to have been doing something related to keyboard. #10 .. #8 confirm that: the execution has proceeded from the libgnomekbdui library to the libxklavier library, which is the library for X Keyboard Extension (XKB). That is the current way in the X11 protocol to query and/or set keyboard layouts.
Lines #7 ... #4 indicate that libxklavier is using libxml2 to apparently read and parse some XML file. It was running a string comparision in #4, when something bad happened and the gdm process received a signal (#3) that probably triggered the crash dump and death of gdm. The top lines (#2 .. #0) are probably related to the clean-up of a multi-threaded gdm process and not essential for the analysis.
So: it appears that gdm was about to do something related to keyboards or keyboard layouts, and was just trying to read some XML file related to that when it crashed. It might be some bad XML, but if that causes libxml2 to crash then it is a bug in libxml2. Or it might be that libxklavier passed a bad pointer to libxml2, in which case it might be a bug in libxklavier, or maybe even one of the other libraries if libxklavier just handed over a pointer it received from elsewhere.
The only XML files related to XKB I know of are located in /usr/share/X11/xkb/rules directory. You should probably use "rpm -V xkeyboard-config -v" to verify that all the files in the xkeyboard-config RPM are undamaged (i.e. all lines output by the rpm -V command should start with a sequence of 9 dots (".........").
The latest RHEL 6.x is now 6.9, so you might want to check if there are any updates for xkeyboard-config, gdm, libxml2, libxklavier or glib2 and try installing them. Alternatively, try configuring the system for the US keyboard layout: if that fixes the problem, there might be an error in the keyboard layout data or keyboard layout settings.... but it should not be causing gdm to crash, so you may have found a bug anyway,
Sorry for coming back to the topic after many years =)
Is there a way to ready those logs by ipmitool or any other similar way, the idea is I have too many servers and I want to collect the logs remotely.
Thanks a lot
for HP-UX there is Ignite/UX is there something simlilar for redhat
I've looked at mondo rescue and a few others.
But am looking for something very similar to IGNITE/UX
Being an HPE employee, I'll suggest the HPE offering, which would be Insight Control server provisioning. You can read about ICsp here: https://www.hpe.com/us/en/software/servers-insight-control.html.
Hello;
i went to the insight control server provisioning. I do realize with
HP(E) that alot of times
items you are looking for is not very direct (30yrs at HP)
with ICsp what part lets you create a current o/s image and boot from it
should a failure
happen
Ike Leong
Sr Systems AdministratorPrivate Info Erased
--
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use
by the addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
e-mail message, you are hereby notified that any dissemination,
distribution or copying of this e-mail message, and any attachments
thereto, is strictly prohibited. If you have received this e-mail message
in error, please immediately notify the sender and permanently delete the
original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT
INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform
Electronic Transactions Act or the applicability of any other law of
similar substance and effect, absent an express statement to the contrary
hereinabove, this e-mail message its contents, and any attachments hereto
are not intended to represent an offer or acceptance to enter into a
contract and are not otherwise intended to bind the sender, Sanmina
Corporation (or any of its subsidiaries), or any other person or entity.
Here's a link to the ICsp Admin Guide: http://h20566.www2.hpe.com/hpsc/doc/public/display?docId=c05303955. You should find all the scenarios there.
Yes, there are a lot of open-source tools available for the purpose of DR (disaster recovery) or Image creation or migration. Again, each would have their own advantages and uses, so usage depends on specific requirements and need.
I like Rear (Relax & Recover) an open-source disaster recovery and migration tool. Other open-source tools such as CloneZilla, Mondorescue etc,. are also good, but I see a lot of complexity involved in using those tools. I've tried to put some information/usage about Rear here in my blog, please take a look at this: Rear- Linux Disaster Recovery Solution
Hi,
We want to send multiple files as an attachment in single mail through SUSE Linux Script. But looks like there is no "m" option in SUSE Linux..
Please find the script which we are using in HP-UX as below but same is not working in SUSE Linux
TEMPFILE=/tmp/temp$RANDOM
if [ -a $TEMPFILE ]
then
rm $TEMPFILE
fi
FOLDERNAME=/logs
cd $FOLDERNAME
for file in `ls`
do
cat $file | ux2dos | uuencode $file >> $TEMPFILE
done
cat $TEMPFILE | mailx -m -s "Subject`hostname`" narendra.uttekar@xyz.com
rm $TEMPFILE
Thanks,
Narendra
> We want to send multiple files as an attachment [...]
Do you want to send multiple files as _an_ attachment, or multiple
files as _multiple_ attachments (in one message)?
Programs like Info-ZIP Zip or "tar" (usually used with gzip or bzip2
(or similar programs) for compression) can be used to package multiple
files into one, and then one attachment can carry the whole collection.
If you want multiple attachments in one message, then you should
probably look for a real MIME e-mail client program.
The -m option in HP-UX is described in the HP-UX mailx(1) man page as:
-m Do not add MIME header lines Mime Version, Content Type & Content Encoding to the header
information while sending mails.
Your script is using a legacy method of sending email attachments: the MIME standard for handling different character sets, attachments and other modern email features has existed since year 1993.
At least on a SuSE SLES 12 SP2 system I had available to me for testing, the SuSE mailx command always adds the MIME header lines and cannot be prevented from adding them. On the other hand, it has option -a for attaching files to messages.
The script is also using "ux2dos" which does not exist in SuSE: the equivalent would be "unix2dos".
Let me suggest an alternative script for you:
#!/bin/sh # script settings here FOLDERNAME=/logs
# create a list of "-a <filename>" options for SuSE mailx cd "$FOLDERNAME" for LOGFILE in * do ATTACHMENTS="$ATTACHMENTS -a $LOGFILE" done mailx $ATTACHMENTS -s "Subject $(hostname)" narendra.uttekar@xyz.com
Using the MIME attachments instead of legacy uuencoding allows the attachments to be opened successfully in both Windows and Unix/Linux systems alike: SuSE mailx is smart enough to detect that the files you're attaching are text files, so it automatically uses the text/plain MIME type to attach them. Then, the receiving email program can automatically convert the line endings if necessary for the destination system, just like it already does for the regular email text, so running the attachments through unix2dos should no longer be necessary.
> [...] so running the attachments through unix2dos should no longer be
> necessary.
Info-ZIP Zip and UnZip also offer options to adjust line endings
(Zip: -l, -ll; UnZip: -a, -aa), so you could probably shed
ux2dos/unix2dos with that method, too.
As usual, many things are possible, and it may help to begin with
your actual requirements, rather than asking how to implement a
particular "solution" to a problem.
Hi,
I have installed the rear and trying to configure the same for OS backup. We have OS - SUSE Linux Enterprise Server 11 SP4.
I was not able to find the sample conf file for SLES 11.4 but there was SLE11-ext3-example.conf and SLE12-btrfs-example.conf and we are using btrfs for ROOT filesystem.
I have modified the local.conf file accordingly but please confirm which one is correct or need any correction our main objective is just in case OS gets crashed/corrupt and need to recover the OS from backup.
cat local.conf based on sample SLE11-ext3-example.conf
OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://10.10.9.13/rear/backup
NETFS_KEEP_OLD_BACKUP_COPY=yes
cat local.conf based on sample SLE12-btrfs-example.conf
OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://10.10.9.13/rear/backup
NETFS_KEEP_OLD_BACKUP_COPY=yes
BACKUP_PROG_INCLUDE=( '/home/*' '/var/tmp/*' '/var/spool/*' '/var/opt/*' '/var/log/*' '/var/lib/pgsql/*' '/var/lib/mailman/*' '/var/lib/named/*' '/usr/local/*' '/tmp/*' '/srv/*' '/boot/grub2/x86_64-efi/*' '/opt/*' '/boot/grub2/i386-pc/*' )
And also how we can access this image without burning this ISO image to a DVD or CD . How we can use a network boot via PXE as this is VM system and if needed how we can boot this VM to recover the system using ReaR backup? Or any other alternate solution?
Thanks,
Narendra
Since it's a VM system (which virtualization platform, by the way? VMware? SuSE virtualization with KVM? Something else?), it should be possible to present/unpresent additional virtual disks to the VMs as needed.
So, do you even need PXE netboot functionality for recovery? Just present an additional virtual disk to some VM, run "rear format /dev/<whatever>" to it, and that will be your recovery virtual disk. Verify that it contains all the tools needed to check, recover, recreate and mount btrfs filesystems. Unpresent it from the VM but don't destroy it. Think of it as a virtual USB stick with the recovery software installed.
When you need to recover a VM system disk, present this recovery virtual disk to that VM and set the VM to boot from it rather than its original system disk, but make sure the system still sees the original system disk too. Then boot the VM, run the recovery to the original system disk, then unpresent the recovery virtual disk and revert the VM configuration to what it was (i.e. boot from the restored system disk). That's it, your VM system disk (and optionally any other disks at the same time) is recovered.
Obviously, you should test this procedure to verify that it's possible for your virtualization platform, and possibly even script it so that the necessary VM configuration changes can be done automatically.
Note that Linux can use a command like "mount -o loop,ro /some/where/image.iso /mnt" to directly mount any files that contain a filesystem image. It's not limited to ISO images - any non-network filesystem type should work. ReaR probably handles all this automatically for you, but it's good to know in case you need to recover just one specific file from ReaR backups manually. (By the way, if you need to mount a disk image that includes a partition table and several partitions, you should learn about commands "losetup" and "kpartx" - with them, it's really easy to access partitioned disk images.)
Your local.conf examples are identical, except that the second one has a BACKUP_PROG_INCLUDE setting and the first one hasn't. The value of BACKUP_PROG_INCLUDE should be set to match how the filesystems are configured in your VMs; you should probably create your own BACKUP_PROG_INCLUDE value using a command line like the one described in https://github.com/rear/rear/issues/1330 :
findmnt -n -r -t btrfs | cut -d ' ' -f 1 | grep -v '^/$' | egrep -v 'snapshots|crash' | sed -e "s/$/\/*'/" -e "s/^/'/" | tr '\n' ' '
Run this command in your VM, and it should display a suggested BACKUP_PROG_INCLUDE value for you. Consider it as a starting point: for example, if you have PostgreSQL databases which are already backed up using a backup method that is more appropriate for them, it might not be necessary to back up all of /var/lib/pgsql/* using ReaR. (Filesystem-level backups from databases taken when the database is active are not likely to be useable, as the state of the database can change while the backup is being created, causing the backup of the database to be internally inconsistent.)
Yes, good information provided by Matti. You really don't need "BACKUP_OPTIONS" unless there is a nfs version change between rear server (backup) and client end systems. You may consider adding "BACKUP_PROG_EXCLUDE" to exclude un-wanted data such as /var/crash, /media which may not be required which otherwise endup in creating a huge backup image dump.
The command "rear -d -v mkbackup" when run after configuring rear backup file "/etc/rear/local.conf" with correct parameters would generate necessary files and copy files over NFS to the destination rear backup server. There would be a directory created with hostname on the remote rear backup server which would show up a file with .iso extenstion, this is usually in the format of "rear-<hostname>.iso" which can be used as a bootable image file to recover system or even could be used to create a new system. This would fetch necessary backup files from the rear backup server.
By default these backup files would gets created under "/var/lib/rear/output/" and then would be moved over to nfs server.
After booting the iso file you could just select "automatic recovery" or select "recovery <hostname> option. I've made a small writeup on this in my blog: http://simplylinuxfaq.blogspot.in/2016/11/rear-linux-disaster-recovery-solution.html review it. This may help.
All the best!
Hi Matt,
Yes good option but unfortunately we don't have enough space to add another virtual disk for backup. We are going to upgrade the storage but it will happen in next year. So in mean time I am looking for some network solution so that we can boot the VM and can restore the ReaR backup from network location.
And we are using VMware 6.0 for virtualization platform.
And also I have run the command as below on our SLES 11.4,
test193:~ # findmnt -n -r -t btrfs | cut -d ' ' -f 1 | grep -v '^/$' | egrep -v 'snapshots|crash' | sed -e "s/$/\/*'/" -e "s/^/'/" | tr '\n' ' ' '/srv/*' '/opt/*' '/tmp/*' '/var/spool/*' '/var/run/*' '/var/log/*' '/var/tmp/*'
We need just only OS backup if system is not booting and need to restore then we can use that backup to restore from network location.
Thanks,
Narendra
If you are having problem with hpsmh on linux where it is not showing any information this might help.
In your /etc/snmp/snmpd.conf add this line to the top: dlmod cmaX /usr/lib54/libcmaX64.so
restart snmp and the hp-snmp-agents
This line is needed for hpsmh to retrive the information from the agents it appears.
There is a command line configuration tool that will add it for you, but for the life of me I can't remember where it is nor can I find any documentation for it.
Hope this helps.
Hi All,
I have getting error in CentOS 6.7 in verites.
Any one help in finx the issue.
# vxprint
VxVM vxprint ERROR V-5-1-684 IPC failure: Configuration daemon is not accessible
verites version :-VRTS_SF_Basic_6.0_Linux
Thanx in advance.
The error indicating that your vxvm configuration daemon is not running. In this situation your vxvm related commands (vxdisk list, vxdisk -o alldgs list) will not work. Was it working earlier? If it is fiirst time & not working you will need to inialise your vxvm. In HP-UX we use "vxinstall" to initialise the vxvm.
Best Regards
Ranveer