How to get the last update date of kernel in AIX & Solaris

Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I want to get the last update date of kernel in AIX & Solaris.
For Linux, the command is:
rpm -qa --last | grep kernel-`uname -r` | sed 's/^k.*ss//'
For this command I'm getting the output:
Wed 29 Nov 2017 03:26:48 PM EST
I need same replacement for AIX & Solaris as well.
I'm trying to execute this command for AIX, but it's not sophisticated proper output what I need:
lslpp -ha bos.adt.base | grep COMPLETE | sed 's/^k.*ss//'
Return Code: 0, 6.1.1.0 COMMIT COMPLETE 09/16/14 13:49:31
6.1.1.0 APPLY COMPLETE 09/16/14 13:49:31
6.1.8.16 COMMIT COMPLETE 09/16/14 13:59:18
6.1.8.16 APPLY COMPLETE 09/16/14 13:55:32
6.1.9.30 COMMIT COMPLETE 07/02/15 16:36:49
6.1.9.30 APPLY COMPLETE 07/02/15 16:33:22
6.1.9.45 COMMIT COMPLETE 09/04/15 15:45:19
6.1.9.45 APPLY COMPLETE 09/04/15 15:45:09
6.1.9.101 APPLY COMPLETE 09/14/17 16:44:44
6.1.1.0 COMMIT COMPLETE 09/16/14 13:49:36
6.1.1.0 APPLY COMPLETE 09/16/14 13:49:36
6.1.8.16 COMMIT COMPLETE 09/16/14 13:59:18
6.1.8.16 APPLY COMPLETE 09/16/14 13:55:32
6.1.9.30 COMMIT COMPLETE 07/02/15 16:36:49
6.1.9.30 APPLY COMPLETE 07/02/15 16:33:23
6.1.9.45 COMMIT COMPLETE 09/04/15 15:45:19
6.1.9.45 APPLY COMPLETE 09/04/15 15:45:10
6.1.9.101 APPLY COMPLETE 09/14/17 16:44:45
Or else I need only last line of above output.
kernel solaris aix
add a comment |Â
up vote
1
down vote
favorite
I want to get the last update date of kernel in AIX & Solaris.
For Linux, the command is:
rpm -qa --last | grep kernel-`uname -r` | sed 's/^k.*ss//'
For this command I'm getting the output:
Wed 29 Nov 2017 03:26:48 PM EST
I need same replacement for AIX & Solaris as well.
I'm trying to execute this command for AIX, but it's not sophisticated proper output what I need:
lslpp -ha bos.adt.base | grep COMPLETE | sed 's/^k.*ss//'
Return Code: 0, 6.1.1.0 COMMIT COMPLETE 09/16/14 13:49:31
6.1.1.0 APPLY COMPLETE 09/16/14 13:49:31
6.1.8.16 COMMIT COMPLETE 09/16/14 13:59:18
6.1.8.16 APPLY COMPLETE 09/16/14 13:55:32
6.1.9.30 COMMIT COMPLETE 07/02/15 16:36:49
6.1.9.30 APPLY COMPLETE 07/02/15 16:33:22
6.1.9.45 COMMIT COMPLETE 09/04/15 15:45:19
6.1.9.45 APPLY COMPLETE 09/04/15 15:45:09
6.1.9.101 APPLY COMPLETE 09/14/17 16:44:44
6.1.1.0 COMMIT COMPLETE 09/16/14 13:49:36
6.1.1.0 APPLY COMPLETE 09/16/14 13:49:36
6.1.8.16 COMMIT COMPLETE 09/16/14 13:59:18
6.1.8.16 APPLY COMPLETE 09/16/14 13:55:32
6.1.9.30 COMMIT COMPLETE 07/02/15 16:36:49
6.1.9.30 APPLY COMPLETE 07/02/15 16:33:23
6.1.9.45 COMMIT COMPLETE 09/04/15 15:45:19
6.1.9.45 APPLY COMPLETE 09/04/15 15:45:10
6.1.9.101 APPLY COMPLETE 09/14/17 16:44:45
Or else I need only last line of above output.
kernel solaris aix
What's the point of the last update date? Updating a 6-year-old kernel to a 5-year-old kernel last week doesn't mean the kernel is current. Either the version is up-to-date or it's not - when it was updated is irrelevant.
â Andrew Henle
Mar 7 at 10:56
1
@AndrewHenle not necessarily irrelevant. if the machine or an application running on it is crashing in obscure circumstances and your logs show it only started happening after the kernel was upgraded from an ancient version to a slightly less ancient version, that's a pretty good indicator that it might be the kernel at fault. If the crash was happening before and after the kernel upgrade, it's unlikely to be implicated.
â cas
Mar 7 at 11:21
@cas True, but if that's the reason for this question, it's on the way towards being an XY problem then, no? Hence the reasone I asked What's the point of the last update date?
â Andrew Henle
Mar 7 at 12:03
@AndrewHenle My point was that it doesn't matter WHY the OP wants this information, it's not up to us here to judge whether it's useful or not.
â cas
Mar 7 at 12:08
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I want to get the last update date of kernel in AIX & Solaris.
For Linux, the command is:
rpm -qa --last | grep kernel-`uname -r` | sed 's/^k.*ss//'
For this command I'm getting the output:
Wed 29 Nov 2017 03:26:48 PM EST
I need same replacement for AIX & Solaris as well.
I'm trying to execute this command for AIX, but it's not sophisticated proper output what I need:
lslpp -ha bos.adt.base | grep COMPLETE | sed 's/^k.*ss//'
Return Code: 0, 6.1.1.0 COMMIT COMPLETE 09/16/14 13:49:31
6.1.1.0 APPLY COMPLETE 09/16/14 13:49:31
6.1.8.16 COMMIT COMPLETE 09/16/14 13:59:18
6.1.8.16 APPLY COMPLETE 09/16/14 13:55:32
6.1.9.30 COMMIT COMPLETE 07/02/15 16:36:49
6.1.9.30 APPLY COMPLETE 07/02/15 16:33:22
6.1.9.45 COMMIT COMPLETE 09/04/15 15:45:19
6.1.9.45 APPLY COMPLETE 09/04/15 15:45:09
6.1.9.101 APPLY COMPLETE 09/14/17 16:44:44
6.1.1.0 COMMIT COMPLETE 09/16/14 13:49:36
6.1.1.0 APPLY COMPLETE 09/16/14 13:49:36
6.1.8.16 COMMIT COMPLETE 09/16/14 13:59:18
6.1.8.16 APPLY COMPLETE 09/16/14 13:55:32
6.1.9.30 COMMIT COMPLETE 07/02/15 16:36:49
6.1.9.30 APPLY COMPLETE 07/02/15 16:33:23
6.1.9.45 COMMIT COMPLETE 09/04/15 15:45:19
6.1.9.45 APPLY COMPLETE 09/04/15 15:45:10
6.1.9.101 APPLY COMPLETE 09/14/17 16:44:45
Or else I need only last line of above output.
kernel solaris aix
I want to get the last update date of kernel in AIX & Solaris.
For Linux, the command is:
rpm -qa --last | grep kernel-`uname -r` | sed 's/^k.*ss//'
For this command I'm getting the output:
Wed 29 Nov 2017 03:26:48 PM EST
I need same replacement for AIX & Solaris as well.
I'm trying to execute this command for AIX, but it's not sophisticated proper output what I need:
lslpp -ha bos.adt.base | grep COMPLETE | sed 's/^k.*ss//'
Return Code: 0, 6.1.1.0 COMMIT COMPLETE 09/16/14 13:49:31
6.1.1.0 APPLY COMPLETE 09/16/14 13:49:31
6.1.8.16 COMMIT COMPLETE 09/16/14 13:59:18
6.1.8.16 APPLY COMPLETE 09/16/14 13:55:32
6.1.9.30 COMMIT COMPLETE 07/02/15 16:36:49
6.1.9.30 APPLY COMPLETE 07/02/15 16:33:22
6.1.9.45 COMMIT COMPLETE 09/04/15 15:45:19
6.1.9.45 APPLY COMPLETE 09/04/15 15:45:09
6.1.9.101 APPLY COMPLETE 09/14/17 16:44:44
6.1.1.0 COMMIT COMPLETE 09/16/14 13:49:36
6.1.1.0 APPLY COMPLETE 09/16/14 13:49:36
6.1.8.16 COMMIT COMPLETE 09/16/14 13:59:18
6.1.8.16 APPLY COMPLETE 09/16/14 13:55:32
6.1.9.30 COMMIT COMPLETE 07/02/15 16:36:49
6.1.9.30 APPLY COMPLETE 07/02/15 16:33:23
6.1.9.45 COMMIT COMPLETE 09/04/15 15:45:19
6.1.9.45 APPLY COMPLETE 09/04/15 15:45:10
6.1.9.101 APPLY COMPLETE 09/14/17 16:44:45
Or else I need only last line of above output.
kernel solaris aix
edited Mar 7 at 15:20
Jeff Schaller
31.2k846105
31.2k846105
asked Mar 7 at 9:51
Rudraprasad Pradhan
112
112
What's the point of the last update date? Updating a 6-year-old kernel to a 5-year-old kernel last week doesn't mean the kernel is current. Either the version is up-to-date or it's not - when it was updated is irrelevant.
â Andrew Henle
Mar 7 at 10:56
1
@AndrewHenle not necessarily irrelevant. if the machine or an application running on it is crashing in obscure circumstances and your logs show it only started happening after the kernel was upgraded from an ancient version to a slightly less ancient version, that's a pretty good indicator that it might be the kernel at fault. If the crash was happening before and after the kernel upgrade, it's unlikely to be implicated.
â cas
Mar 7 at 11:21
@cas True, but if that's the reason for this question, it's on the way towards being an XY problem then, no? Hence the reasone I asked What's the point of the last update date?
â Andrew Henle
Mar 7 at 12:03
@AndrewHenle My point was that it doesn't matter WHY the OP wants this information, it's not up to us here to judge whether it's useful or not.
â cas
Mar 7 at 12:08
add a comment |Â
What's the point of the last update date? Updating a 6-year-old kernel to a 5-year-old kernel last week doesn't mean the kernel is current. Either the version is up-to-date or it's not - when it was updated is irrelevant.
â Andrew Henle
Mar 7 at 10:56
1
@AndrewHenle not necessarily irrelevant. if the machine or an application running on it is crashing in obscure circumstances and your logs show it only started happening after the kernel was upgraded from an ancient version to a slightly less ancient version, that's a pretty good indicator that it might be the kernel at fault. If the crash was happening before and after the kernel upgrade, it's unlikely to be implicated.
â cas
Mar 7 at 11:21
@cas True, but if that's the reason for this question, it's on the way towards being an XY problem then, no? Hence the reasone I asked What's the point of the last update date?
â Andrew Henle
Mar 7 at 12:03
@AndrewHenle My point was that it doesn't matter WHY the OP wants this information, it's not up to us here to judge whether it's useful or not.
â cas
Mar 7 at 12:08
What's the point of the last update date? Updating a 6-year-old kernel to a 5-year-old kernel last week doesn't mean the kernel is current. Either the version is up-to-date or it's not - when it was updated is irrelevant.
â Andrew Henle
Mar 7 at 10:56
What's the point of the last update date? Updating a 6-year-old kernel to a 5-year-old kernel last week doesn't mean the kernel is current. Either the version is up-to-date or it's not - when it was updated is irrelevant.
â Andrew Henle
Mar 7 at 10:56
1
1
@AndrewHenle not necessarily irrelevant. if the machine or an application running on it is crashing in obscure circumstances and your logs show it only started happening after the kernel was upgraded from an ancient version to a slightly less ancient version, that's a pretty good indicator that it might be the kernel at fault. If the crash was happening before and after the kernel upgrade, it's unlikely to be implicated.
â cas
Mar 7 at 11:21
@AndrewHenle not necessarily irrelevant. if the machine or an application running on it is crashing in obscure circumstances and your logs show it only started happening after the kernel was upgraded from an ancient version to a slightly less ancient version, that's a pretty good indicator that it might be the kernel at fault. If the crash was happening before and after the kernel upgrade, it's unlikely to be implicated.
â cas
Mar 7 at 11:21
@cas True, but if that's the reason for this question, it's on the way towards being an XY problem then, no? Hence the reasone I asked What's the point of the last update date?
â Andrew Henle
Mar 7 at 12:03
@cas True, but if that's the reason for this question, it's on the way towards being an XY problem then, no? Hence the reasone I asked What's the point of the last update date?
â Andrew Henle
Mar 7 at 12:03
@AndrewHenle My point was that it doesn't matter WHY the OP wants this information, it's not up to us here to judge whether it's useful or not.
â cas
Mar 7 at 12:08
@AndrewHenle My point was that it doesn't matter WHY the OP wants this information, it's not up to us here to judge whether it's useful or not.
â cas
Mar 7 at 12:08
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
2
down vote
For the AIX part, instead of hard-coding the bos.adt.base fileset, and instead of asking for all of the updates -- applies and commits -- but instead just the commits, I would ask for the history of the fileset that owns the /unix symlink (which points to the kernel):
lslpp -q -c -h -Or $(lslpp -q -c -w /unix | cut -d: -f2) | tail -1 | cut -d: -f7-8
In pieces, that's:
- -q -- don't print column headings
- -c -- print output colon-delimited (easier to parse)
- -h -- fileset history
- -w -- which fileset owns the given file
- -Or -- only need one set;
root orusr works here
From the inside out, we get the fileset name from lslpp ... -w and then ask for the history of that fileset; that's then piped to tail to get the last line (assumed to be the most recent), and then to cut to pull out the date and time fields.
For the Solaris part, perhaps the most recently applied patch to the kernel would suffice?
nawk -F: '/^PATCH_INFO/ sub(" From", ""); print $2":"$3":"$4; '
/var/sadm/pkg/SUNWckr/pkginfo |
sort -k6n | tail -1
add a comment |Â
up vote
1
down vote
On Solaris, you'll see the kernel patch installed by running:uname -v | awk -F_ 'print $2'
If you then run:ls -lat /var/sadm/patch |grep <patch>
You'll see the timestamp of when it was installed. There will also be logs in that directory if you want further information.
/var/sadm/patchwill only be present on Solaris 10 and earlier, on Solaris 11.x you'll need to usepkg info system/kernelinstead.
â alanc
Mar 8 at 16:50
add a comment |Â
up vote
0
down vote
You can get the last line of any output by piping it to tail -1. Try this:
lslpp -ha bos.adt.base | sed -n '/COMPLETE/ s/^k.*ss//p' | tail -1
I've also folded the grep command into the sed command - it wasn't doing anything that sed can't do itself.
NOTE: I'm not familiar with the AIX lslpp command, so I'm just assuming it's the right tool to use for this job, and that you've used the most appropriate options with it. It may be worth reading the man page to see if there are better ways of using it to get what you want.
btw, too bad about the weird MM/DD/YY date format. if it was ISO-8601 standard YYYY-MM-DD, it could easily be sorted.
â cas
Mar 7 at 12:19
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
For the AIX part, instead of hard-coding the bos.adt.base fileset, and instead of asking for all of the updates -- applies and commits -- but instead just the commits, I would ask for the history of the fileset that owns the /unix symlink (which points to the kernel):
lslpp -q -c -h -Or $(lslpp -q -c -w /unix | cut -d: -f2) | tail -1 | cut -d: -f7-8
In pieces, that's:
- -q -- don't print column headings
- -c -- print output colon-delimited (easier to parse)
- -h -- fileset history
- -w -- which fileset owns the given file
- -Or -- only need one set;
root orusr works here
From the inside out, we get the fileset name from lslpp ... -w and then ask for the history of that fileset; that's then piped to tail to get the last line (assumed to be the most recent), and then to cut to pull out the date and time fields.
For the Solaris part, perhaps the most recently applied patch to the kernel would suffice?
nawk -F: '/^PATCH_INFO/ sub(" From", ""); print $2":"$3":"$4; '
/var/sadm/pkg/SUNWckr/pkginfo |
sort -k6n | tail -1
add a comment |Â
up vote
2
down vote
For the AIX part, instead of hard-coding the bos.adt.base fileset, and instead of asking for all of the updates -- applies and commits -- but instead just the commits, I would ask for the history of the fileset that owns the /unix symlink (which points to the kernel):
lslpp -q -c -h -Or $(lslpp -q -c -w /unix | cut -d: -f2) | tail -1 | cut -d: -f7-8
In pieces, that's:
- -q -- don't print column headings
- -c -- print output colon-delimited (easier to parse)
- -h -- fileset history
- -w -- which fileset owns the given file
- -Or -- only need one set;
root orusr works here
From the inside out, we get the fileset name from lslpp ... -w and then ask for the history of that fileset; that's then piped to tail to get the last line (assumed to be the most recent), and then to cut to pull out the date and time fields.
For the Solaris part, perhaps the most recently applied patch to the kernel would suffice?
nawk -F: '/^PATCH_INFO/ sub(" From", ""); print $2":"$3":"$4; '
/var/sadm/pkg/SUNWckr/pkginfo |
sort -k6n | tail -1
add a comment |Â
up vote
2
down vote
up vote
2
down vote
For the AIX part, instead of hard-coding the bos.adt.base fileset, and instead of asking for all of the updates -- applies and commits -- but instead just the commits, I would ask for the history of the fileset that owns the /unix symlink (which points to the kernel):
lslpp -q -c -h -Or $(lslpp -q -c -w /unix | cut -d: -f2) | tail -1 | cut -d: -f7-8
In pieces, that's:
- -q -- don't print column headings
- -c -- print output colon-delimited (easier to parse)
- -h -- fileset history
- -w -- which fileset owns the given file
- -Or -- only need one set;
root orusr works here
From the inside out, we get the fileset name from lslpp ... -w and then ask for the history of that fileset; that's then piped to tail to get the last line (assumed to be the most recent), and then to cut to pull out the date and time fields.
For the Solaris part, perhaps the most recently applied patch to the kernel would suffice?
nawk -F: '/^PATCH_INFO/ sub(" From", ""); print $2":"$3":"$4; '
/var/sadm/pkg/SUNWckr/pkginfo |
sort -k6n | tail -1
For the AIX part, instead of hard-coding the bos.adt.base fileset, and instead of asking for all of the updates -- applies and commits -- but instead just the commits, I would ask for the history of the fileset that owns the /unix symlink (which points to the kernel):
lslpp -q -c -h -Or $(lslpp -q -c -w /unix | cut -d: -f2) | tail -1 | cut -d: -f7-8
In pieces, that's:
- -q -- don't print column headings
- -c -- print output colon-delimited (easier to parse)
- -h -- fileset history
- -w -- which fileset owns the given file
- -Or -- only need one set;
root orusr works here
From the inside out, we get the fileset name from lslpp ... -w and then ask for the history of that fileset; that's then piped to tail to get the last line (assumed to be the most recent), and then to cut to pull out the date and time fields.
For the Solaris part, perhaps the most recently applied patch to the kernel would suffice?
nawk -F: '/^PATCH_INFO/ sub(" From", ""); print $2":"$3":"$4; '
/var/sadm/pkg/SUNWckr/pkginfo |
sort -k6n | tail -1
answered Mar 7 at 15:08
Jeff Schaller
31.2k846105
31.2k846105
add a comment |Â
add a comment |Â
up vote
1
down vote
On Solaris, you'll see the kernel patch installed by running:uname -v | awk -F_ 'print $2'
If you then run:ls -lat /var/sadm/patch |grep <patch>
You'll see the timestamp of when it was installed. There will also be logs in that directory if you want further information.
/var/sadm/patchwill only be present on Solaris 10 and earlier, on Solaris 11.x you'll need to usepkg info system/kernelinstead.
â alanc
Mar 8 at 16:50
add a comment |Â
up vote
1
down vote
On Solaris, you'll see the kernel patch installed by running:uname -v | awk -F_ 'print $2'
If you then run:ls -lat /var/sadm/patch |grep <patch>
You'll see the timestamp of when it was installed. There will also be logs in that directory if you want further information.
/var/sadm/patchwill only be present on Solaris 10 and earlier, on Solaris 11.x you'll need to usepkg info system/kernelinstead.
â alanc
Mar 8 at 16:50
add a comment |Â
up vote
1
down vote
up vote
1
down vote
On Solaris, you'll see the kernel patch installed by running:uname -v | awk -F_ 'print $2'
If you then run:ls -lat /var/sadm/patch |grep <patch>
You'll see the timestamp of when it was installed. There will also be logs in that directory if you want further information.
On Solaris, you'll see the kernel patch installed by running:uname -v | awk -F_ 'print $2'
If you then run:ls -lat /var/sadm/patch |grep <patch>
You'll see the timestamp of when it was installed. There will also be logs in that directory if you want further information.
answered Mar 8 at 3:16
sleepyweasel
86319
86319
/var/sadm/patchwill only be present on Solaris 10 and earlier, on Solaris 11.x you'll need to usepkg info system/kernelinstead.
â alanc
Mar 8 at 16:50
add a comment |Â
/var/sadm/patchwill only be present on Solaris 10 and earlier, on Solaris 11.x you'll need to usepkg info system/kernelinstead.
â alanc
Mar 8 at 16:50
/var/sadm/patch will only be present on Solaris 10 and earlier, on Solaris 11.x you'll need to use pkg info system/kernel instead.â alanc
Mar 8 at 16:50
/var/sadm/patch will only be present on Solaris 10 and earlier, on Solaris 11.x you'll need to use pkg info system/kernel instead.â alanc
Mar 8 at 16:50
add a comment |Â
up vote
0
down vote
You can get the last line of any output by piping it to tail -1. Try this:
lslpp -ha bos.adt.base | sed -n '/COMPLETE/ s/^k.*ss//p' | tail -1
I've also folded the grep command into the sed command - it wasn't doing anything that sed can't do itself.
NOTE: I'm not familiar with the AIX lslpp command, so I'm just assuming it's the right tool to use for this job, and that you've used the most appropriate options with it. It may be worth reading the man page to see if there are better ways of using it to get what you want.
btw, too bad about the weird MM/DD/YY date format. if it was ISO-8601 standard YYYY-MM-DD, it could easily be sorted.
â cas
Mar 7 at 12:19
add a comment |Â
up vote
0
down vote
You can get the last line of any output by piping it to tail -1. Try this:
lslpp -ha bos.adt.base | sed -n '/COMPLETE/ s/^k.*ss//p' | tail -1
I've also folded the grep command into the sed command - it wasn't doing anything that sed can't do itself.
NOTE: I'm not familiar with the AIX lslpp command, so I'm just assuming it's the right tool to use for this job, and that you've used the most appropriate options with it. It may be worth reading the man page to see if there are better ways of using it to get what you want.
btw, too bad about the weird MM/DD/YY date format. if it was ISO-8601 standard YYYY-MM-DD, it could easily be sorted.
â cas
Mar 7 at 12:19
add a comment |Â
up vote
0
down vote
up vote
0
down vote
You can get the last line of any output by piping it to tail -1. Try this:
lslpp -ha bos.adt.base | sed -n '/COMPLETE/ s/^k.*ss//p' | tail -1
I've also folded the grep command into the sed command - it wasn't doing anything that sed can't do itself.
NOTE: I'm not familiar with the AIX lslpp command, so I'm just assuming it's the right tool to use for this job, and that you've used the most appropriate options with it. It may be worth reading the man page to see if there are better ways of using it to get what you want.
You can get the last line of any output by piping it to tail -1. Try this:
lslpp -ha bos.adt.base | sed -n '/COMPLETE/ s/^k.*ss//p' | tail -1
I've also folded the grep command into the sed command - it wasn't doing anything that sed can't do itself.
NOTE: I'm not familiar with the AIX lslpp command, so I'm just assuming it's the right tool to use for this job, and that you've used the most appropriate options with it. It may be worth reading the man page to see if there are better ways of using it to get what you want.
answered Mar 7 at 12:14
cas
37.6k44392
37.6k44392
btw, too bad about the weird MM/DD/YY date format. if it was ISO-8601 standard YYYY-MM-DD, it could easily be sorted.
â cas
Mar 7 at 12:19
add a comment |Â
btw, too bad about the weird MM/DD/YY date format. if it was ISO-8601 standard YYYY-MM-DD, it could easily be sorted.
â cas
Mar 7 at 12:19
btw, too bad about the weird MM/DD/YY date format. if it was ISO-8601 standard YYYY-MM-DD, it could easily be sorted.
â cas
Mar 7 at 12:19
btw, too bad about the weird MM/DD/YY date format. if it was ISO-8601 standard YYYY-MM-DD, it could easily be sorted.
â cas
Mar 7 at 12:19
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f428705%2fhow-to-get-the-last-update-date-of-kernel-in-aix-solaris%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
What's the point of the last update date? Updating a 6-year-old kernel to a 5-year-old kernel last week doesn't mean the kernel is current. Either the version is up-to-date or it's not - when it was updated is irrelevant.
â Andrew Henle
Mar 7 at 10:56
1
@AndrewHenle not necessarily irrelevant. if the machine or an application running on it is crashing in obscure circumstances and your logs show it only started happening after the kernel was upgraded from an ancient version to a slightly less ancient version, that's a pretty good indicator that it might be the kernel at fault. If the crash was happening before and after the kernel upgrade, it's unlikely to be implicated.
â cas
Mar 7 at 11:21
@cas True, but if that's the reason for this question, it's on the way towards being an XY problem then, no? Hence the reasone I asked What's the point of the last update date?
â Andrew Henle
Mar 7 at 12:03
@AndrewHenle My point was that it doesn't matter WHY the OP wants this information, it's not up to us here to judge whether it's useful or not.
â cas
Mar 7 at 12:08