Ghost software updates for Lubuntu 14.04?

[barbaz]

OK so just a few minutes ago Software Update told me that the computer needs restart to finish installing updates... yet I *don't* have automatic updating enabled - and as far as I can tell there were NO updates installed. I tried actually installing updates for my computer to see what was available, & none of them would require a restart. Installed them in case it would make a difference, & the updater still thinks I need restart.

The last thing I was doing (which is not something I normally do), is install a few OpenBox themes only in my own user account. No form of sudo type stuff, not asked for my password.

Log files uninformative.

What's going on here?
Any packages known to cause this?
Have I been hacked somehow?
Anyone else seen this?
Unfortunately I can't just not restart the computer How do I investigate it?

(Internet searching is unhelpful.)

[Thrawn]

Can't say I tend to see that, no...unless you did an update previously, and it forgot to ask you at the time? Eg if you upgraded from the command line?

[barbaz]

No, no updates were done by me in any way since the last time the computer was restarted.
I've checked in Ubuntu Software Center (which logs all package changes no matter what) & the last change it reported was when I installing gnome-system-log earlier that day.

Now that I've rebooted I'm not seeing any "odd" processes in gnome-system-monitor... then again, one of the existing executables could have been replaced...

[barbaz]

In case it helps, this is a MacBook Pro 9,1 with broadcom & nvidia proprietary drivers installed.

What I did learn from my Internet searching though is that whatever happened (if anything) would almost certainly involve the kernel in some way.
So, lsmod output (which looks normal enough to me):

Code: Select all

Module                  Size  Used by
xt_tcpudp              12884  3 
iptable_filter         12810  1 
ip_tables              27239  1 iptable_filter
x_tables               34059  3 ip_tables,xt_tcpudp,iptable_filter
pci_stub               12622  1 
vboxpci                23273  0 
vboxnetadp             25670  0 
vboxnetflt             27880  0 
vboxdrv               446742  3 vboxnetadp,vboxnetflt,vboxpci
bnep                   19624  2 
rfcomm                 69160  8 
nls_iso8859_1          12713  1 
snd_hda_codec_hdmi     46368  1 
snd_hda_codec_cirrus    18855  1 
uvcvideo               80885  0 
videobuf2_vmalloc      13216  1 uvcvideo
bcm5974                17589  0 
videobuf2_memops       13362  1 videobuf2_vmalloc
videobuf2_core         40664  1 uvcvideo
btusb                  32412  0 
videodev              134688  2 uvcvideo,videobuf2_core
bluetooth             391136  22 bnep,btusb,rfcomm
hid_appleir            13010  0 
joydev                 17381  0 
intel_rapl             18773  0 
x86_pkg_temp_thermal    14205  0 
intel_powerclamp       14705  0 
coretemp               13435  0 
kvm_intel             143187  0 
kvm                   455843  1 kvm_intel
crct10dif_pclmul       14289  0 
crc32_pclmul           13113  0 
ghash_clmulni_intel    13216  0 
applesmc               19308  0 
input_polldev          13896  1 applesmc
aesni_intel            55624  0 
aes_x86_64             17131  1 aesni_intel
lrw                    13286  1 aesni_intel
gf128mul               14951  1 lrw
glue_helper            13990  1 aesni_intel
ablk_helper            13597  1 aesni_intel
cryptd                 20359  3 ghash_clmulni_intel,aesni_intel,ablk_helper
snd_seq_midi           13324  0 
snd_seq_midi_event     14899  1 snd_seq_midi
snd_hda_intel          56531  7 
wl                   6367819  0 
snd_rawmidi            30144  1 snd_seq_midi
snd_hda_codec         193017  3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_cirrus
cfg80211              484040  1 wl
snd_hwdep              13602  1 snd_hda_codec
snd_pcm               102099  4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
lpc_ich                21080  0 
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
snd_seq                61560  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              29482  2 snd_pcm,snd_seq
mei_me                 18627  0 
mei                    82276  1 mei_me
snd                    69322  24 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_hda_codec_cirrus,snd_seq_midi
nvidia               8379750  0 
i915                  788212  2 
soundcore              12680  1 snd
apple_gmux             13665  0 
drm_kms_helper         55071  1 i915
video                  19476  2 i915,apple_gmux
drm                   303102  4 i915,drm_kms_helper,nvidia
apple_bl               13993  1 apple_gmux
i2c_algo_bit           13413  1 i915
mac_hid                13205  0 
shpchp                 37032  0 
parport_pc             32701  0 
ppdev                  17671  0 
lp                     17759  0 
parport                42348  3 lp,ppdev,parport_pc
hid_apple              13386  0 
hid_generic            12548  0 
usbhid                 52659  0 
hid                   106148  4 hid_generic,usbhid,hid_appleir,hid_apple
tg3                   166478  0 
sdhci_pci              23172  0 
ptp                    18933  1 tg3
ahci                   34091  4 
libahci                32716  1 ahci
sdhci                  43015  1 sdhci_pci
pps_core               19382  1 ptp

[barbaz]

OK so I decided to do a full backup of my system as it is now, to see exactly what changed in the "non-dynamic" parts of the filesystem... apparently what changed is not anything to do with my kernel that has changed, rather something modified my initramfs:

Code: Select all

/boot/initrd.img-3.13.0-62-generic
/boot/grub/grubenv

Then again rsync only looks at name, file size, & date modified... I should see if the checksum of the backup's kernel matches that of the kernel on my machine.
(Now off to search around to see where the kernel is stored...)
EDIT Yes it matches. So my kernel really hadn't been changed.

All other changes are not unexpected.

So far this is not looking like a hack.

[barbaz]

Decided to regenerate the initramfs with `update-initramfs -u`, we'll see what happens next.

Can anyone offer any advice as to how I can investigate this should it happen again? That is, is there a means to investigate this issue that I didn't think of or don't know about?

[Thrawn]

Not that I know of off the top of my head, sorry.

[barbaz]

Saw it again after updating my VM. There is no way that case could be a hack.
Some of those updates required a restart, I did restart, and as I'm working on other things up pops that notice.

I think probably Thrawn's original thinking on this is right, that one of the updates needed a restart but somehow some part of it didn't register that a restart had already happened.