Zone File System Moving

Zone file systems are a little confusing. This quick guide on moving a file system from one mount point to another should help explain a few of the details that can be used for other operations as well.

In the Local Zone make the new folder for the new file system mount location:
In the LOCAL ZONE

# mkdir /NewMountPoint

#Or you could do this in the global zone as “mkdir /zones/ZoneHostName/root/NewMountPoint”

Unmount the Zone mount and the Global File system mount on the Global zone:
(Do all of this from the global zone)

umount /zones/ZoneHostName/root/OldMountPoint
umount /zones/ZoneHostName_mounts/OldMountPoint

Now make the new folder in /zones/ZoneHostName_mounts to mount the file system in the gloal zone and remove the old one:

mkdir /zones/ZoneHostName_mounts/NewMountPoint
rmdir /zones/ZoneHostName_mounts/OldMountPoint

Now edit /etc/vfstab to change the reference to /OldMountPoint to /NewMountPoint
Do the same for /etc/zones/ZoneHostName.xml
#Note that the changes to the XML file will not be used until the next reboot, so be sure to get it right, otherwise you’ll have a boot failure and not know why

Now remount the file system on the global zone:

mount /zones/ZoneHostName_mounts/NewMountPoint

now, FROM THE GLOBAL ZONE remount the file system into the local zome (this is the tricky one):

mount -F lofs /zones/ZoneHostName_mounts/NewMountPoint /zones/ZoneHostName/root/NewMountPoint

Remove the old mount point from the local zone:

rmdir /zones/ZoneHostName/root/OldMountPoint

As you can see, the file system is actually mounted TWICE:
Once on the global zone in /zones/ZoneHostName_mounts/NewMountPoint as the file system type.
Then again, in the zone under /zones/ZoneHostName/root/NewMountPoint as a “loopback” (lofs) file system.
This makes thingsa little confusing. I think it might actually be less confusing if you did NOT use the same name in the …mounts/… folder as you did in the zone. YOu could actually mount it anywhere in the global zone.

There are other ways to do this too.
The file system can be mounted only in the local zone.
You can also use “lofs” to mount a subfolder from the global zone, which case the double mounting makes a little more sense.

Posted in Uncategorized | Leave a comment

pkgtrans

The easiest way to get at the guts of a package is with pkgtrans.

This will take a package file and make it into a pile of files in a folder under /tmp:

pkgtrans pkgname /tmp all

Note that not all packages have the .pkg extension. You can use the pkginfo command to see if it is a package:

pkginfo -d pkgname
Posted in Uncategorized | 1 Comment

Fixing /etc/group

/etc/group can have a few problems. The biggest one is when a line gets too long and then you cannot add more users to a group. The maximum line length for /etc/group in Solaris 10 is 2048 characters.

grpck will tell you if a line is too long. It will also help you find ways to shorten it, such as telling you if there are users in /etc/group that do not exist in /etc/passwd.

Here is some brief “magic” ideas to quickly clean up /etc/group:

grpck /etc/group
cp /etc/group /tmp/group

for i in $(grpck /tmp/group 2>&1|grep found|awk '{ print $1 }'|sort|uniq)
do perl -pi -e "s/$i//g" /tmp/group
done

perl -pi -e "s/,,/,/g" /tmp/group;grep ,, /tmp/group
grpck /tmp/group
#Null login name" output means there is a comma at the end of a line or at the beginning of a line. Fix it first!
vi /tmp/group
/,$
/:,
grpck /tmp/group
#Entries that are "duplicate" as in the appear in /etc/passwd already, should be dealt with by hand.
grpck /tmp/group
cp /etc/group /etc/group.OLD
ls -la /etc/group /tmp/group
cp /tmp/group /etc/group
chown root:root /etc/group
ls -la /etc/group /etc/group.OLD
grpck /etc/group

However, if that still leaves you with long lines, the “solution” is to split up your groups.
Make TWO lines with two group names with the SAME GID and split your users between them. Like:

group1::321:user1,user2,user3
group1a::321:user4,user5,user6

Now everything should work just fine as normal. The only drawback is that the OS tools like useradd and usermod will add user to BOTH lines, so you end up with:

group1::321:user1,user2,user3,user7
group1a::321:user4,user5,user6,user7

So you will run out of space again fast, but you can always clean things up again by deleting duplicates. grpck will tell you about these duplicates.

Posted in Uncategorized | Leave a comment

Large files (over 2 gigabyte) in VXFS

“Large File” support was not always default in VXFS. Old file systems may not support files over 2 gigabytes. They just “do not work” and commands like unzip don’t know why. They usually think the file system is full.

Use mount -p to find out if large files are supported:

BEFORE:

/dev/vx/dsk/appdg/vol01 - /app vxfs - no rw,suid,delaylog,nolargefiles,ioerror=mwdisable

You can use the “fsadm” command to change the setting on the fly:

/opt/VRTS/bin/fsadm -F vxfs -o largefiles /app

NOW:

/dev/vx/dsk/appdg/vol01 - /app vxfs - no rw,suid,delaylog,largefiles,ioerror=mwdisable
Posted in Veritas File System | Leave a comment

Local Zone Mounts

File systems in Local Zones are usually mounted from the global zone. If they need to be remounted you have to use the file system type “lofs”.

Like so:

root@GZHost: grep redo /etc/zones/LZHost.xml

root@GZHost: mount -F lofs /zones/LZHost_mounts/oraredo/pkg1/fs02 /zones/LZHost/root/oraredo/pkg1/fs02

These file systems will then show up with “df” in the local zone.

Posted in Uncategorized | Leave a comment

M5000 locator LED

M5000 locator LED:
XSCF> showlocator
Locator LED status: Off
XSCF> setlocator -h
usage: setlocator blink|reset
setlocator -h
XSCF> setlocator blink
XSCF> showlocator
Locator LED status: Blinking

Posted in Uncategorized | Leave a comment

vxreattach

In Veritas sometimes disks come up as failed in vxdisk list, but they are not really failed or even gone. For instance, on a SAN array. How do you “recover” them though if there is nothing wrong?

Run:
/etc/vx/bin/vxreattach

Posted in Uncategorized | Leave a comment

fmadm faulty

After a system is set up for the first time I find there is sometimes “junk” in the “fmadm faulty” output.
I also find that after Oralce replaces hardware “fmadm faulty” still shows it as failed.

While “fmadm faulty” is not necessarily a place to look for system faults, I don’t see why it can’t be clear if you system has a clean bill of health.

This is how I clear faults there:

# fmadm faulty
————— ———————————— ————– ———
TIME EVENT-ID MSG-ID SEVERITY
————— ———————————— ————– ———
Aug 21 02:10:29 0134e653-9164-454e-fbd2-fd5270984ca8 SUN4U-8007-L3 Critical

Host : HOSTNAME
Platform : SUNW,Sun-Fire-V490 Chassis_id :

Fault class : fault.memory.dimm-ue-imminent 95%
Affects : mem:///unum=Slot,A:J3001
faulted but still in service
FRU : mem:///unum=Slot,A:J3001 95%
faulty
Serial ID. : 536588

Description : A pattern of correctable errors has been observed suggesting the
potential exists that an uncorrectable error may occur.
Refer to http://sun.com/msg/SUN4U-8007-L3 for more information.

Response : None at this time.

Impact : None at this time. However, the potential uncorrectable error
warrants proactive service action to avoid any unplanned system
outages.

Action : Schedule a repair procedure to replace the DIMM. Use fmadm faulty
to identify the DIMM to replace.

# fmdump -v -u 0134e653-9164-454e-fbd2-fd5270984ca8
TIME UUID SUNW-MSG-ID
Aug 21 2010 02:10:30 0134e653-9164-454e-fbd2-fd5270984ca8 SUN4U-8007-L3
95% fault.memory.dimm-ue-imminent

Problem in: –
Affects: mem:///unum=Slot,A:J3001
FRU: mem:///unum=Slot,A:J3001
Location: –

# fmadm repaired mem:///unum=Slot,A:J3001
fmadm: recorded repair to of mem:///unum=Slot,A:J3001
# fmadm faulty

There are also sometimes faults that fmadm does not know what to do with. In this case the easiest thing to do is to just “acquit” them. Again, make sure the hardware actually has been repaired. In my case these usually occurred during system setup.

# fmadm faulty
————— ———————————— ————– ———
TIME EVENT-ID MSG-ID SEVERITY
————— ———————————— ————– ———
Dec 01 22:20:20 ada1be8d-a35c-e5a5-b97b-9a535c91cce1 SUNOS-8000-FU Major

Host : fsprd130
Platform : SUNW,SPARC-Enterprise Chassis_id : BEF103075B

Fault class : defect.sunos.eft.undiag.fme

Description : The diagnosis engine encountered telemetry for which it was
unable to perform a diagnosis. Refer to
http://sun.com/msg/SUNOS-8000-FU for more information.

Response : Error reports have been logged for examination by Sun.

Impact : Automated diagnosis and response for these events will not occur.

Action : Ensure that the latest Solaris Kernel and Predictive Self-Healing
(PSH) patches are installed.

# fmadm acquit ada1be8d-a35c-e5a5-b97b-9a535c91cce1
fmadm: recorded acquital of ada1be8d-a35c-e5a5-b97b-9a535c91cce1

In some cases this will actual put out a service light, so be sure the problem as really been fixed!

If there are a lot of components contributing to the fault, and you are highly confident you can use something like this:
for i in $(fmdump -v -u 25c57158-68ed-c6e7-a623-aaea0df632ca|grep FRU:|awk ‘{ print $2 }’);do fmadm repaired $i;done

Posted in Uncategorized | Leave a comment

IPMP if_mpadm command

If you are going to move stuff around concerning IPMP interfaces, you need to let IPMP know before you unplumb and after you plumb the interfaces by running:

if_mpadm -d INTERFACE to detach
or
if_mpadm -r INTERFACE to reattach

See man for more details.

Posted in Network Settings | 2 Comments

Fault lights on SPARC system when there is no fault

Incorrect LEDs on front of system. It may be the ILOM (Service Controller) needs to be reset.

Go to the console, and use #. to drop to the ILOM prompt and run:
reset /SP

This only restarts the service controller, it does NOT reboot the system.
(It is a bit scarry, because the ILOM runs Linux I think, and you see the shutdown process start, but that isn’t Solaris. Keep an SSH connection open to verify.)

To return to the consol run:
start /SP/console

Posted in Uncategorized | Leave a comment