Jim,
I found using sym links to be a pain in the butt with sles. I found that it was much easier to just use persistent storage device minor numbers and make nodes that point to those devices like so:
cd /dev/mapper
ll
lrwxrwxrwx 1 root root 16 2009-06-29 09:27 control -> ../device-mapper
brw------- 1 root root 253, 4 2009-06-29 09:27 InformixMirror-IDSdbs
brw------- 1 root root 253, 3 2009-06-29 09:27 InformixMirror-IDSRoot
brw------- 1 root root 253, 2 2009-06-29 09:27 InformixPrimary-IDSdbs
brw------- 1 root root 253, 0 2009-06-29 09:27 InformixPrimary-IDSRoot
brw------- 1 root root 253, 1 2009-06-29 09:27 InformixPrimary-IDSTemp
lvchange -M y --major 253 --minor 100 "/dev/mapper/InformixPrimary-IDSRoot"
lvchange -M y --major 253 --minor 101 "/dev/mapper/InformixPrimary-IDSdbs"
lvchange -M y --major 253 --minor 102 "/dev/mapper/InformixPrimary-IDSTemp"
lvchange -M y --major 253 --minor 110 "/dev/mapper/InformixMirror-IDSRoot"
lvchange -M y --major 253 --minor 111 "/dev/mapper/InformixMirror-IDSdbs"
cd /opt/informix
mkdir dev
cd dev
mknod dbs1.1 b 253 101
mknod dbs1.1m b 253 111
mknod dbsroot1.1 b 253 100
mknod dbsroot1.1m b 253 110
mknod dbstemp b 253 102
chown informix:informix *
chmod 660 *
ll /opt/informix/dev
total 0
brw-rw---- 1 informix informix 253, 101 Jun 21 13:45 dbs1.1
brw-rw---- 1 informix informix 253, 111 Jun 21 13:45 dbs1.1m
brw-rw---- 1 informix informix 253, 100 Jun 21 13:49 dbsroot1.1
brw-rw---- 1 informix informix 253, 110 Jun 21 13:49 dbsroot1.1m
brw-rw---- 1 informix informix 253, 103 Jun 21 13:48 dbstemp
Just a thought.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-807-SQL5(7755)
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
===============================
SLES 11x64 & IDS 11.50.FC6
JICS 7.4.1 & Cognos 8
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel
Sent: Tuesday, June 21, 2011 1:14 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24103]
Thanks Jim. Your pain will be everyone's gain.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
On Tue, Jun 21, 2011 at 1:06 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Art, and anyone who wants to install IDS on Enterprise SuSE 11, please
> read on:
>
> The permissions and ownership of the sym links pointing to the logical
> volume device files for my IDS Chunks was not causing the problem and
> errno 2 that happened when trying to start up IDS.
>
> It turns out that I had the sym links that I created pointing at the
> sym links created by the Device Mapper feature of Enterprise SuSE 11.
> The Mapper's sym links in turn point at the actual device files for
> the Logical Volumes which live in /dev/mapper.
> Apparently this does not work. The sym links that I create must point
> directly to the device files in /dev/mapper.
>
> This probably sounds a bit nebulous and anyone installing IDS on a
> Linux system using Device Mapper should know what to do, so I will
> give an example of what I mean:
>
> For my rootdbs, I created a Logical Volume using the SuSE 11
> "Partitioner" and called it "vol01".
>
> Instead of finding the device file for it, that the LVM created, in
> /dev/<volume_group_name> with the name "vol01", I found it in the dir
> /etc/mapper with the name "<volume_group_name>-vol01".
>
> In /dev/<volume_group_name> I found a symbolic link created by either
> the LVM or Device Mapper called "vol01" that points to the actual
> device file /etc/mapper/<vol_grp_name>-vol01.
>
> 1) for my rootdbs chunk, I created the symbolic link /dev/rootdbs:
>
> ls -l /dev listing shows:
>
> lrwxrwxrwx 1 root root 26 Jun 20 15:20 rootdbs ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev listing shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 rootdbs
>
> 2) Originally, I had my link from (1) pointing straight to the device
> file shown in (3), as the
>
> "ls -l" in (1) shows. After rebooting the system and discovering that
> all of the links that
>
> I created in /dev were removed by the reboot and that the reboot had
> also undone the
>
> permissions and ownership changes that I gave the device files in (3).
>
> So, when I recreated my sym links that I use with onspaces to create
> the IDS Chunks, I was
>
> not sure what was going on so I tried pointing the links that I
> created in (1) at the links
>
> in (2), which in turn point to the device files. Note that the "ls -lL"
> listing in (1) even
>
> shows the correct permissions and ownership of the link's target which
> is accessed via a
>
> double-link hop.
>
> BUT THIS DOES NOT WORK.
>
> ls -l /dev/VolGrp01 shows:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev/VolGrp01 shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 vol01
>
> 3) THE SYBMOLIC LINKS CREATED BY THE DBA FOR USE WITH onspaces MUST
> POINT DIRECTLY TO THESE OBJECTS:
>
> ls -l /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> ls -lL /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> What is really irritating is that the nowhere in the IDS 11
> Information Center, IDS Installation Guide, Administrator Manuals,
> Release Notes for the 11.70.xC1 IDS Version, and Machine Notes for the
> port was there any mention or warning about symbolic links in /dev
> being removed & permissions and ownership customizations of logical
> volume device files used as chunks being undone when the system is
> rebooted, or how to deal with it. In fact, when I called it in to
> Informix Tech Support under my contract, the engineer had apparently
> never heard about this scenario that occurs when installing IDS on
> some flavors of Linux.
>
> What is doubly annoying is that, apparently, when using IDS on Linux,
> the DBA needs to refer to manuals or notes in manuals that are
> specific for "Unix", as opposed to Windows, and there is no
> documentation or notes in documentation regarding Linux-specific
> issues such as what happened to me. Certainly there are many more
> Linux-specific instructions, notes, etc. that would not apply to the
> commercial Unix systems.
>
> Regards,
>
> Jim
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: Thursday, June 16, 2011 5:59 PM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24068]
>
> Errno 2 is permissions (EPERM). Make sure that all of the low level
> chunk devices are informix:informix with 0660 privileges and make sure
> that the links themselves are 777 (owner of the links doesn't really
> matter, but I usually make them informix:informix also).
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own
> opinions and
>
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other organization with which I am associated either explicitly,
> implicitly, or by
>
> inference. Neither do those opinions reflect those of other
> individuals affiliated with any entity with which I am affiliated nor
> those of the entities themselves.
>
> On Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Hi Art,
> >
> > Well, no doubt about it, you are THE MAN! I *almost* have the server
> > back up (see below). Good news and bad news.
> >
> > Thanks very much for the clever way of recreating lost symbolic
> > links used originally to create chunks and pointing these links at
> > the actual chunk device file paths/names. This method is based upon
> > your expert knowledge of chunk storage internals.
> >
> > I used your method to get the chunk number for each chunk/block
> > device file (using RAW chunks), looked for that number in the oncfg
> > file's "Chunks" section, got the name of the symbolic link used to
> > create the chunk from that line in the file, and created a script to
> > recreate the symbolic links/pathnames that had been used in the
> > onspaces commands that created the chunks.
> >
> > The server begins to start with the "oninit" command, but it ABORTS.
> > According to the online.log file, it gets quite a ways through
> > startup but finds something wrong, Errno 2 (missing file or
> > directory?) with chunk 1, my rootdbs. I have included the tail end
> > of the log file, starting just before the warning about chunk 1, continuing to the end.
> >
> > Any ideas? It seems like perhaps I made a mistake with the creation
> > of the symbolic link for rootdbs, but it looks OK I think. The "ls
> > -l" of it
> > produces:
> >
> > lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> > /dev/VolGrp01/vol01
> >
> > and the rootdbs link points to another link, and ls -l on that link
> > produces:
> >
> > lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> > /dev/mapper/VolGrp01-vol01
> >
> > and ls -l on the target of that link, the block device file for the
> > LV
> that
> > I used to create Chunk 1 with, produces:
> >
> > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
> > /dev/mapper/VolGrp01-vol01
> >
> > The "ls -lL /dev/rootdbs" command produces:
> >
> > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
> >
> > I am new to Linux (SUSE 11 SLES) and trying to migrate IDS from HPUX
> > to
> it.
> > I
> > do not really understand the "device-mapper" Linux functionality
> > that is creating symbolic links instead of Logical Volume device
> > files in the traditional directory created for the Volume Group that
> > the LVs belong to, and pointing those links in the VG dir to
> > /dev/mapper, where the device files for the LV actually reside.
> >
> > So, due to my lack of knowledge of mapper, the following might be
> > the problem and I would appreciate your opinion on it.
> >
> > Originally I created the sym links in /dev to point straight at the
> device
>
> > file
> > in /dev/mapper. For example, the rootdbs was created with:
> >
> > ln -s /dev/mapper/VolGrp01-vol01b /dev/rootdbs
> >
> > However, due to some discussions with our Linux Sys Admins here, I
> > have recreated the links in /dev to point to the sym links in the
> > /dev/vgxx dir, which then point to the actual device files that I
> > have set the ownershiip and permissions on
> >
> > correctly.
> >
> > The rootdbs was created with the path /dev/rootdbs, and the "ls -lL" on
> > that
> > sym link/path
> > shows the target of this double-linking to be:
> >
> > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
> >
> > which looks OK permissions and ownership-wise, but perhaps the double
> > linking is the problem?
> >
> > What do you think? Sorry this is so long. Thanks for bearing with me.
> >
> > Jim
> >
> > 15:30:20 Event notification facility epoll enabled.
> > 15:30:20 IBM Informix Dynamic Server Version 11.70.FC1GE Software Serial
> > Number AAA#B000000
> > 15:30:20 Warning: stat() failed for chunk file /dev/rootdbs
> > 15:30:22 IBM Informix Dynamic Server Initialized -- Shared Memory
> > Initialized.
> >
> > 15:30:22 Started 1 B-tree scanners.
> > 15:30:22 B-tree scanner threshold set at 5000.
> > 15:30:22 B-tree scanner range scan size set to -1.
> > 15:30:22 B-tree scanner ALICE mode set to 6.
> > 15:30:22 B-tree scanner index compression level set to med.
> > 15:30:22 Physical Recovery Started at Page (2:131643).
> > 15:30:23 Physical Recovery Complete: 8 Pages Examined, 8 Pages Restored.
> > 15:30:23 Logical Recovery Started.
> > 15:30:23 Dynamically allocated new virtual shared memory segment (size
> > 8192KB)
> > 15:30:23 Memory sizes:resident:192512 KB, virtual:253840 KB,
> > SHMTOTAL:16777216 KB
> > 15:30:23 10 recovery worker threads will be started.
> > 15:30:23 Assert Warning: I/O read chunk 1, pagenum 6641, pagecnt 1 -->
> > errno = 2
> > 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> > 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
> >
> > Thread(29, xchg_1.2, 502519a8, 3)
> >
> > File: rsbuff.c Line: 6302
> > 15:30:23 Action: Please notify IBM Informix Technical Support.
> > 15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
> > 15:30:23 See Also: /opt/db/ids/tmp/af.40567de
> > 15:30:23 I/O read chunk 1, pagenum 6641, pagecnt 1 --> errno = 2
> > 15:30:23 Rollforward of log record failed. iserrno = 126
> > 15:30:23 Log Record: log = 27, pos = 0x3ef8518, type =
> OLDRSAM:HINSERT(40),
> > trans = 26
> > 15:30:23 Assert Failed: INFORMIX-OnLine Must ABORT
> >
> > Critical media failure.
> > 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> > 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
> >
> > Thread(29, xchg_1.2, 502519a8, 3)
> >
> > File: rsmirror.c Line: 1734
> > 15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
> > 15:30:23 See Also: /opt/db/ids/tmp/af.40567de, shmem.40567de.0
> > 15:30:28 Starting crash time check of:
> > 15:30:28 1. memory block headers
> > 15:30:28 2. stacks
> > 15:30:28 Crash time checking found no problems
> > 15:30:28 rsmirror.c, line 1734, thread 29, proc id 12822, INFORMIX-OnLine
> > Must ABORT
> >
> > Critical media failure..
> > 15:30:29 Fatal error in ADM VP at mt.c:14250
> > 15:30:29 Unexpected virtual processor termination, pid = 12822, exit =
> > 0x100
> >
> > 15:30:29 PANIC: Attempting to bring system down
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art
> > Kagel
> > Sent: Thursday, June 16, 2011 1:34 PM
> > To: ids@iiug.org
> > Subject: Re: is there a way to find out the physical de.... [24060]
> >
> > Unfortunately, no. Informix only stored the links you provide, it does
> not
>
> > follow the links to their core names at all, it depends on the OS to
> > maintain and promote the links.
> >
> > HOWEVER, there is one way. Use dd piped to od -x to read the first few
> > pages (so 2K each if you used the default pagesize or whatever the
> pagesize
> > of the dbspaces were) of each chunk's physical device. The first six
> bytes
>
> > of each page have the chunk number encoded. So on my server for chunk #1:
> >
> > $ dd if=/opt/informix/infmx.11.70.FC1B7/dbspaces/rootdb.1.chunk bs=2k
> > count=2|od -x
> > 2+0 records in
> > 2+0 records out
> > 4096 bytes (4.1 kB) copied, 0.00441886 s, 927 kB/s
> > 0000000 *0000 0000 0001* 9600 0003 1800 0130 06c0
> > 0000020 0000 0000 0000 0000 4249 204d 6e49 6f66
> >
> > For chunk #6:
> >
> > $ dd if=/opt/informix/infmx.11.70.FC1B7/dbspaces/tempdbs1.1.chunk bs=2k
> > count=1|od -x
> > 1+0 records in
> > 1+0 records out
> > 2048 bytes (2.0 kB) copied, 7.7661e-05 s, 26.4 MB/s
> > 0000000 *0000 0000 0006* 492e 0000 1800 0018 07e4
> > 0000020 0000 0000 0000 0000 0000 0000 0000 0000
> >
> > Armed with the chunk numbers you should be able to recreate the links.
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and
> >
> > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other
>
> > organization with which I am associated either explicitly, implicitly, or
> > by
> >
> > inference. Neither do those opinions reflect those of other individuals
> > affiliated with any entity with which I am affiliated nor those of the
> > entities themselves.
> >
> > On Thu, Jun 16, 2011 at 2:23 PM, jim-cramer@uiowa.edu
> > <jim-cramer@uiowa.edu>wrote:
> >
> > > Help!
> > >
> > > 11.70.FC1 on Linux SUSE 11 SLES
> > >
> > > After setting up a 11.7 IDS instance and creating a bunch
> > > of Logical Volumes, creating Symbolic Links in /dev that
> > > pointed to the block device files that the LV Manager created,
> > > changing the ownership and permission on these device files
> > > appropriately, creating dbspaces from the chunks *using the
> > > Symbolic Link pathnames* to the chunk device files,
> > > I found out that when the Linux system was rebooted all
> > > of the Symbolic Links for my Informix Chunks were deleted
> > > from /dev (and also that the ownership and permissions for the
> > > chunk devices files had reverted to my pre-configured state).
> > >
> > > I need to re-create the symbolic links for the chunks, in
> > > some non-system directory I assume.
> > >
> > > The names of the symbolic links that I created indicated
> > > what dbspace the each chunk belonged to. I have those link names in
> > > my $INFORMIXDIR/etc/oncfg_servername.0 file as the pathname
> > > to each Chunks.
> > >
> > > UNFORTUNATELY, the names that I gave the Logical
> > > Volumes, and hence the names of the devices files created
> > > for the LVs/Chunks, did not indicate which Chunk/DBSpace
> > > each was created for (i.e.: I used a systematic pattern vol01,
> > > vol02, vol02,...)
> > >
> > > So, I need a way to find out the physical device file pathname
> > > that each of the symbolic links had pointed to, so that I
> > > can recreate the links correctly.
> > >
> > > OR
> > >
> > > since those links have been blown away by the OS and the instance
> > > is down, is there a file somewhere where I would find this info?
> > >
> > > Or
> > >
> > > is there an Informix Utility that can be run against a down instance
> > > that would list out the chunks that had been created for that instance
> > > along with the physical device file pathname for each?
> > >
> > > Any information or ideas would be appreciated.
> > >
> > > Thanks,
> > >
> > > Jim Cramer
> > > Univ of Iowa
> > >
> > >
> > >
> > >
> >
> >
>
> ****************************************************************************
>
> > ***
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --bcaec5016349fe9e0304a5d882f3
> >
> >
> >
>
> ****************************************************************************
>
> > ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
> ****************************************************************************
> ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --bcaec51a7e3ed80ad604a5dc379a
>
>
> ****************************************************************************
> ***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--bcaec501c4462c7d0804a63bfb0a
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
