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.
This has literally just happened, so I’ve done no further investigation, but I thought it was worth putting out there in case anyone was about to start an OS update on something they cared about. 🙂
At this point I’m not discounting that I’ve screwed up somewhere. My next plan is to install three clean VMs (OL 5.6, 5.7 and 5.8) and check the output of scsi_id on each of them. If that turns out OK, then I’ve screwed something else and you can probably ignore this post. I might not get to try it out until tomorrow. Either way, I’ll update this post with the results of that test.
Update 1: It’s definitely changed. See the following.
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.6 (Tikanga) # /sbin/scsi_id -g -u -s /block/sda/sda1 SATA_VBOX_HARDDISK_VB54dff07f-931ce4d7_ # # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.7 (Tikanga) # /sbin/scsi_id -g -u -s /block/sda/sda1 SATA_VBOX_HARDDISK_VBx180d717-f896e661_ # # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.8 (Tikanga) # /sbin/scsi_id -g -u -s /block/sda/sda1 #
Update 2: As John Sobecki correctly pointed out in the comments, the title of the post is misleading. UDEV is not at fault here. The problem is the “/sbin/scsi_id” command is behaving differently, which is making my rules useless. The UDEV issue is the symptom, not the cause. The post is clearly focusing on the scsi_id issue, but I’ve picked a pretty bad title to go with it. 🙂
Update 3: John Sobecki pointed me at “[block] fail SCSI passthrough ioctls on partition devices CVE-2011-4127”, a mainline kernel security fix that seems to be the cause of this. It affects all new kernels which include this change (RHEL5/6, UEK etc). Oracle are testing the impact of this. Initially ASMLib and OCFS seem unaffected.
Update 4: MOS Note 1438604.1 (currently in review) contains more information about this issue. ASMLib and OCFS are unaffected by CVE-2011-4127, so ASMLib should probably be used in preference to UDEV with newer kernels.
Update 5: I’ve altered all the articles on my site to reference the parent (disk) device, rather than the partition device, which makes the UDEV rules work fine again. Thanks to Bryan Wood and Joachim for their suggestions.
17 thoughts on “Oracle Linux 5.8 and UDEV issues…”
Oracle Linux 5.8 and UDEV issues… | The ORACLE-BASE Blog http://t.co/UmNHU4Vq
Same is for OEL 6.0
Left it as it is
I use a different rule for OL6 and it works fine. Same rule does not work for 5.8 though. You can see what I did for pre5.8 and 6.x here:
It can be definitely done and made working. What is puzzling is the inconsistency…
Updated post. Behavior has definitely changed. http://t.co/UmNHU4Vq
That’s pretty sad!
But if you were using ASMlib it would still work? That won’t make the people that hate ASMlib very happy.
Andy: Good question. I’ll need to try it later. 🙂
@LenzGr You’re a Linux Guru. Any idea what’s going on with /scsi_id in OL5.8?
It’s not udev .. it’s the kernel, specifically kernels with CVE-2011-4127 (newer 5.7 errata, 5.8, and also Oracle UEK kernels at 2.6.32-300.4.1 and higher. That’s based on testing here in the lab today. Regards, John
Yes. The title is misleading. I have a UDEV issue because the test I’m using in the UDEV rule (/sbin/scsi_id) is now giving a different result.
The failure of my UDEV rules are a symptom, not the cause. 🙂
Oracle Linux 5.8 and scsi_id issues… http://t.co/BLqDbmM9
Oracle Linux 5.8 and UDEV issues… http://t.co/Yv6EVLAJ 通过 @AddThis
Here is a rule that works with 5.8:
KERNEL==”sd[c-z]1″, BUS==”scsi”, PROGRAM=”/sbin/scsi_id -g -u -s /block/%P”, RESULT==”3*”, NAME=”asm%c”, OWNER=”oracle”, GROUP=”dba”, MODE=”0660″
%P gives the parent device name of “sdc” which nicely works around the behavior change in scsi_id. By the way asmlib is no longer supported with OEL/RHEL6 (certification announced just this week), so its probably best to stick with udev rules. I never cared much for asmlib anyway.
Bryan: Yes. I was thinking of something similar myself. When testing on Fedora, partitions automatically return the SCSI ID of the parent device, so I think a change like this may be coming through the pipeline. Of course, it doesn’t help people who have multiple partitions per disk, but they don’t count. 🙂
Regarding the ASMLib support, it will be supported on the UEK kernel, since it is actually part of the kernel already. It will not be supported on the RHEL kernel (Oracle Linux or RHEL). That announcement was made over a year ago.
As far as I know, this is still the case. At last years OOW there was an announcement of some new functionality being included in ASMLib, making it a bit more appealing than it currently is, if you have the right storage.
Same observation where updating RHEL6 or OEL6 to a recent kernel.
Solution for me is a change in the UDEV Rule:
KERNEL==”sd*1″ SUBSYSTEM==”block”, PROGRAM=”/sbin/scsi_id -g -d /dev/$parent” (notice $parent).
This is nearly the same solution presented by Brian.
Here’s the rule which I wrote which works for setting up ASM LUNs with multiple partitions:
KERNEL==”sd?[0-9]”, BUS==”scsi”, PROGRAM==”/usr/bin/udevinfo -q name -p %p”, RESULT==”%k”, PROGRAM==”scsi_id -g -u -d /dev/$parent”, RESULT==”3600605b00489cc2017c25cc320a2c2b9″, NAME=”asm-disk1p%n”, OWNER=”grid”, GROUP=”asmadmin”, MODE=”0660″
brw-rw—- 1 grid asmadmin 8, 20 Oct 19 23:26 /dev/asm-disk1p4
brw-rw—- 1 grid asmadmin 8, 17 Oct 19 23:26 /dev/asm-disk1p1
brw-rw—- 1 grid asmadmin 8, 18 Oct 19 23:26 /dev/asm-disk1p2
brw-rw—- 1 grid asmadmin 8, 19 Oct 19 23:26 /dev/asm-disk1p3
Comments are closed.