[SOLVED] Installing kernel-21.1.8-amd64.txz failed

Started by twave, July 12, 2021, 02:27:48 PM

Previous topic - Next topic
Hi,

Hopefully an easy fix, but has anyone had the 21.1.7 to 21.1.8 update fail? I have a situation where all but the Base and Kernel have been updated to 21.1.8. Below is log of what happens when I subsequently run the update. I have rebooted since.


***GOT REQUEST TO UPDATE***
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): . done
Processing candidates (0 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Your system is up to date.
Starting web GUI...done.
Generating RRD graphs...done.
Fetching base-21.1.8-amd64.txz: ..................... done
Fetching kernel-21.1.8-amd64.txz: .......... done
!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!
! A critical upgrade is in progress. !
! Please do not turn off the system. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Installing kernel-21.1.8-amd64.txz...rm: /boot/kernel.old/if_bxe.ko: Operation not permitted
rm: /boot/kernel.old: Directory not empty
failed, rm error 0
***DONE***


Thank you!

Looks like a file system error not releasing the file:

rm: /boot/kernel.old/if_bxe.ko: Operation not permitted

Can you run fsck / to see?


Cheers,
Franco


** /dev/gpt/rootfs (NO WRITE)
** Last Mounted on /mnt
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=13643668 (8 should be 0)
CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

56120 files, 1373127 used, 53109083 free (8147 frags, 6637617 blocks, 0.0% fragmentation)

But when I run it in single user, fsck results in no errors and says disk is clean.

Try /sbin/fsck -fy in single user mode. It may be marked clean but should perform the clean anyway.


Cheers,
Franco

Hi Franco... same result, says file system is clean

/dev/gpt/rootfs

The device is bare metal, with a 250gb ssd been running without problems for a long time.

When I re-run fsck / in multi-user it now gives me:

** /dev/gpt/rootfs (NO WRITE)
** Last Mounted on /mnt
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=13643539 (8 should be 0)
CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE  I=13643539  OWNER=root MODE=100644
SIZE=0 MTIME=Jul 13 13:38 2021
RECONNECT? no


CLEAR? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

56115 files, 1371719 used, 53110491 free (8195 frags, 6637787 blocks, 0.0% fragmentation)

I've checked the SMART data and ran the tests, drive is reporting to be okay. Any ideas?

Thanks again!



Let's apply more force then?  :)

Usually if a file is broken you can still move it to a location until it gets cleaned up eventually.

# mv /boot/kernel.old/if_bxe.ko /tmp

If there are more files like that just move the others as well.


Cheers,
Franco

weird.. won't let me do that either.

I tried in single user, mounted /dev/gpt/rootfs and tried to move it, same result : operation not permitted.

ahhhhh  :o

chflags noschg /boot/kernel.old/if_bxe.ko


For whatever reason, file was set to immutable.... thanks so much for helping out franco... much appreciated!

I know the flag was used in base set but unsure about kernel set. We never had to deal with it in update tools before:

https://github.com/opnsense/update/blob/master/update/opnsense-update.sh.in#L663-L690


Cheers,
Franco