Search

Top 60 Oracle Blogs

Recent comments

problem

Oracle Enterprise Manager Cloud Control 12.1 – Agent Installation, Issues and Solutions

Currently busy for a client to install and configure Oracle Enterprise Manager 12c for database and more administration across the globe. These environments were configured and setup by a different 3rd party so not always follow our wishes and administration guidelines. You can imagine that such environments are also a neat environments regarding learning curves

Read More…

scsi_id and UDEV issues (update)…

Last month I wrote about a problem I saw with scsi_id and UDEV in  OL5.8. As it screwed up all my UDEV rules is was a pretty important issue for me. It turned out this was due to a mainline security fix (CVE-2011-4127) affecting the latest kernels of both RHEL/OL5 and RHEL/OL6. The comments on the previous post show a couple of workarounds.

Over the weekend I started to update a couple of articles that mentioned UDEV rules (here and here) and noticed the problem had dissapeared. I updated two VMs (OL5.8 and OL6.2) with the latest changes, including the UEK updates and ran the tests again and here’s what I got.

Oracle Linux 5.8 and UDEV issues…

I just did an update from Oracle Linux 5.7 to 5.8 on one of my VirtualBox RAC installations and things are not looking to clever at the moment. After a reboot, the ASM instances and therefore the database instances wouldn’t restart. A quick look showed the ASM disks were not visible. On this installation I was using UDEV, rather than ASMLib. In checking the UDEV rules I noticed the scsi_id command on OL5.8 doesn’t report an ID for partitions on disks, only the disks themselves. For example, on OL5.7 I get this,

# /sbin/scsi_id -g -u -s /block/sdb/sdb1
SATA_VBOX_HARDDISK_VBd306dbe0-df3367e3_
#

On OL5.8 I get this,

# /sbin/scsi_id -g -u -s /block/sdb/sdb1
#

If I run it against the disk, rather than the partition it works fine.

Fedora 15: First big problem…

Yesterday I hit a pretty major problem with Fedora 15. I did a reboot and the login screen came up fine, but when I tried to log in I got a message saying,

failed to load session ‘gnome’

No options or alternatives. Just back to the login screen. ??

I started the machine up in “Full multiuser mode” by hitting the “a” key during boot and adding “3″ on to the boot parameters. Once at the login prompt I could now log in as root. Since it looked like it might be a GNOME problem I uninstalled and reinstalled GNOME.

yum -y groupremove "GNOME Desktop Environment"
yum -y groupinstall "GNOME Desktop Environment"

No change!

My next thought was to install KDE, so at least I would have a desktop. I did this using,

yum -y groupinstall kde

I made KDE the default window manager by editing the “/etc/sysconfig/desktop” file to contain.

DISPLAYMANAGER=KDE

The machine now rebooted and I got KDM as the display manager. This allowed me to start KDE, but surprisingly, also allowed me to start GNOME as my window manager.

Now I figured it was probably an issue with GDM, not GNOME itself, so I reinstalled GDM.

yum -y remove gdm
yum -y install gdm
yum -y install gdm-plugin-fingerprint

Bingo. I was now able to switch back to GDM as my display manager by editing the “/etc/sysconfig/desktop” file to contain.

DISPLAYMANAGER=GNOME

I have no idea what happened to cause this problem in the first place. Googling for a solution wasn’t much help because most posts are really old and the new ones just said reinstall.

If anyone else has misfortune to run into this issue, you now know how I got out of it.

Incidentally, my brief time on KDE did not fill me with a desire to switch. I think I prefer GNOME. I am however a little nervous about the stability of Fedora 15 after this incident. Maybe I did something dumb to cause it, but if I did, I have no idea what it was. I’m just running a browser and VirtualBox VMs for the most part.

Cheers

Tim…