11.2 system is running 11.0 kernel

[abishai]

I have a server running bhyve VMs and looks like something is wrong.
While all VMs are working, I found that top command is not:

top: sysctl(vm.stats.vm.v_laundry_count...) failed: No such file or directory

abishai@alpha:~ % freebsd-version -kru
11.2-RELEASE-p2
11.0-RELEASE-p2
11.2-RELEASE-p2

abishai@alpha:~ % doas freebsd-update --currently-running 11.2-RELEASE-p2 IDS
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 11.2-RELEASE from update5.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
/etc/group has SHA256 hash 9f997954c36266986d71459d672ab83c6b48b15854dacb0e38f51e4eccf3b0c5, but should have SHA256 hash fbcb5c4da1987cdfbf44a1c4cb2d1302ecd0d61e2680e9df072d38b4b31cdfa6.
/etc/mail/sendmail.cf has 0444 permissions, but should have 0644 permissions.
/etc/mail/sendmail.cf has SHA256 hash b8d547a65b334d15718d75983faaf558b01a8b4945b748d577644609ba337679, but should have SHA256 hash 900a37f432d23d4f4d3f1759dedaacaddfedcb3eff3dfb46d1836e98f046c551.
/etc/mail/submit.cf has SHA256 hash aefadb147f9346a92f793e52bd9a621659f988fd167cd57e5a71a1449ed76837, but should have SHA256 hash e002d1713123348983bb0ab893ad73a70781eba371d912dfbb49dadaa9671d72.
/etc/master.passwd has SHA256 hash da7022d230a54a900f12c9db719fdc7efc5c71a2035f6338a6e1b7ae705f9853, but should have SHA256 hash f923585b204fa2669d4989c19ab6483e453dfac6a56dacf77b1f2f90d5017762.
/etc/motd has SHA256 hash 23cd60832024a16e87be8d96215e625f7cb50ad602b0f2c7e748f6d0b1cd465e, but should have SHA256 hash c76d9a02e764e77686f9bf4a9192311b6a0387a088cc414dd312ef6ba069ad7e.
/etc/ntp.conf has SHA256 hash 99fc1ed8954a84efa171e9ecfc30b46ccfd5055ab9954df4ec6cd3678b63b63f, but should have SHA256 hash 6df0c0b436a109cf5d2a123934906d6363c4ee706163759e4c3365c393bebecd.
/etc/passwd has SHA256 hash 385aa286b3e813caa06b173e339080a3541ae0eb7590ee3b91265ae964a052bd, but should have SHA256 hash 23879ad47149dc4c9dc84db37c13d7bf186272c1d55b744f0e9440d5ea5e42f9.
/etc/pwd.db has SHA256 hash 150b0d4501a8f139361c7416477761640a215d948371767f363a2018912bb054, but should have SHA256 hash d81780531d2c5e0b1e8277123c6268c7271ec47066776c30e050bd7d5d051104.
/etc/spwd.db has SHA256 hash 612320479dd06d6a7dfbd0e1e991f4650ea409cdf42048a78f27f2152d79fa95, but should have SHA256 hash 61bf373801ad74d8ff09c88f12d798862d3fc097a868c02acb8c23ebc70652e3.
/etc/ssh/sshd_config has SHA256 hash cc76668c9cbe826d32d32c969150c6d898c7680357f6b5af066a9d1d1e872962, but should have SHA256 hash 4b383b9df338cc0997d672eac0e6d3cdb06d862bb921efcde8ee1d143ecf47b4.

abishai@alpha:~ % uname -a
FreeBSD alpha.abinet.ru 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 06:55:27 UTC 2016     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

abishai@alpha:~ % doas freebsd-update --currently-running 11.2-RELEASE-p2 fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 11.2-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 11.2-RELEASE-p2.

I'm really confused, how can this possible ?

 

[abishai]

Geee, this one was funny.

I've hot plug a new drive that was not really new, but from old FreeBSD box. It's SATA port id was less than port of bootable drive and gptzfsboot of bootable drive picked up /boot from new drive instead. During boot sequence, root from bootable drive was mounted, masking all traces of the crime.

At first, I gpart destroy -F geom and system stop booting at all with this drive present during root mounting with error 6. (I remember an answered topic here with this error).

I was able to fix this with zpool labelclear for this drive.

I can imagine some attacks using this technique... There are no way to figure out that system used incorrect /boot as correct /boot mounted later and system passes freebsd-update IDS test.

Also, it's strange that 11.2 can operate atop of 11.0 kernel.

 

[kpa]

e.

I can imagine some attacks using this technique... There are no way to figure out that system used incorrect /boot as correct /boot mounted later and system passes freebsd-update IDS test.

Please don't, anyone who gets fooled into attaching an untrusted disk onto their system has no business of being a systems admin.