Nuggets From AIX Documentation
Rob McNelly seeks answers, makes a quick confession and receives a timely reminder
Where do you go when you have questions and need help?
I’m not just talking about AIX, IBM Power Systems and other technical information, but in general. I’ve heard of people who post what they know to be incorrect information—the calculation being that others would eagerly jump in to reply and set them straight. It makes sense. After all, the world is full of folks who won’t go to bed knowing that someone, somewhere is wrong on the internet. It’s an interesting maneuver (my longtime editor, who’s a lifelong Minnesotan, is impressed by this level of passive-aggressiveness), and it apparently works.
Still, other options exist. Maybe you have friends and colleagues you hit up with a quick text or IM. As I’ve mentioned often over the years—and let’s get back into the technical area now—I believe that most answers can be found with a bit of web searching. A tech issue may be new to me, but most likely some if not multiple techies have previously run into and, even better, already resolved this problem and helpfully posted the solution. All I need to do is find their answers.
I’ll typically start with Google or some other search engine. As for specific sites, there’s the IBM community forums (by the way, this was an interesting discussion). The UNIX and Linux community is another option (and here’s another interesting discussion). Incidentally, this site appears to have evolved; if you prefer the original unix.com version, just click the All Categories option.
Of course, the internet doesn’t have all the answers. At what point do you give up your search and open a PMR with IBM Support? It’s a really bad day when you can stump the vendor.
The logshuffle Attribute
On that note, I have a quick confession. Recently I gave a wrong answer when asked for technical advice. A colleague asked if an INLINE log could be switched on an existing AIX filesystem. I said no, you must remove and recreate the filesystem, and cited this Q&A from IBM Support:
“Q: Can you convert a JFS2 filesystem with an outline log (i.e. external log logical volume) to one with an inline log?
A: No, JFS2 filesystems using one type of log cannot be changed to use another. If a filesystem is created to use a log logical volume, for example /dev/loglv00, it cannot be changed to use an inline log.
“In the same respect, a JFS2 filesystem using an inline log cannot be successfully changed to point to an outline log. While this may seem to work it will not survive exportvg/importvg.
“The chfs man page has this to say about inline and outline logs: For a file system using INLINE log, this option does not support switching logs between INLINE and OUTLINE log. Currently, to switch from inline log to outline log (or vice versa), the file system has to be removed and recreated.”
However, per IBM AIX documentation, the logshuffle attribute can be used to make the change:
-a logshuffle={INLINE | logdevicename}“Sets a file system to use the specified log. The specified log device must be in the same volume group as the current log device. If you specify logshuffle=INLINE, the logical volume will be extended to create an inline log device of the default size (0.4% of the file system, size up to 2047 MB) for the file system. Specifying an outline log device does not shrink the logical volume.”
Chris Gibson also covered this in his look at AIX 7.3 enhancements. While I read that article, I must have missed that nugget. It happens. Sometimes when I go over a list of changes, they do not seem to stick until I actually run into one of them in the wild. In fact, several times over the years I’ve even found answers in my own long forgotten write-ups. Luckily you can still (re)teach an old dog new tricks.
A Timely Reminder About System Licenses and Entitlements
Recently I saw this message following an LPAR boot:
"Welcome to AIX.
boot image timestamp: 21:08:43 08/08/2024
The current time and date: 21:09:09 08/08/2024
processor count: 4; memory size: 204800MB; kernel size: 58068187
boot device: /vdevice/vfc-client@300000c8/disk@3004022817164c43,1000000000000:2
“The AIX Update Access Key (UAK) does not exist or has expired and the AIX code level being booted appears to be out of compliance with AIX Software Maintenance (SWMA) for this server. To obtain a new AIX UAK for your server contact the server manufacturer*. To apply a new AIX UAK to your server, use the Capacity on Demand Enter CoD Code task on the Hardware Management Console (HMC).
“*For non-IBM branded servers contact your support provider.”
While this message doesn’t seem new, it was new to me—probably due to the fact that I typically boot AIX on systems with active AIX SWMA. In any event I appreciated the notification, since this customer’s system software licenses and entitlements needed to be brought into compliance.
Here’s an explanation that accompanies AIX 7.2 TL5 and AIX 7.3 (that is, pre-Power10) documentation:
“IBM POWER10, or later processor-based servers include an AIX update access key (UAK) that is checked when you update the AIX operating system. UAKs include an expiration date. Informational messages are generated when the release date for this AIX operating system has passed the expiration date of the UAK. Informational messages are also generated when the server boots or during the live partition mobility (LPM) operation and the current AIX operating system level has passed the expiration date of the UAK. Additionally, the server periodically checks and informs the administrator about UAKs that are about to expire, UAKs that have expired, or UAKs that are missing.”
Resolving a tcpdump Failure
Finally, this IBM Support Q&A explains how to resolve a tcpdump failure:
“Q: Why tcpdump fails with error “tcpdump: bpf_load: could not configure driver: Do not specify an existing file” on AIX and VIOS?
For example:
# tcpdump -i en3 port 22tcpdump: bpf_load: could not configure driver: Do not specify an existing file.
“A: The tcpdump uses bpf to capture the network packets. The error “bpf_load: could not configure driver: Do not specify an existing file” indicates that another application or driver is holding a lock on bpf that is reserved for tcpdump. To determine who is holding a lock on bpf, run the following steps as root.”
Click the link for a complete explanation.