compression algorithm inherit not supported

[Ghydda]

Well, I am puzzled.

It was time to do the half-annually update to the box in the shed.
From GUI I pointed and clicked, till I hit the update button and then I went away, as this usually takes more time than I care to stick around for.
When I came back the browser claimed the system had gone away to do a reboot. Super.

But the system stayed down. Ah-well, off to the shed.

Boot looping. Damn...
After GRUB has filled the screen with gngngngngngngngngngn the system reboots. It takes 2 seconds.

Now,- I am aware of cyberjock's opinion of using thumb-drives for boot-drive, but I figured, naaah he's just too experienced.
Once a man reaches that level of competence, anything less than the moon will not do.

Anywho, I caved last year, and added 2 small mSATA SSDs to the already existing mirror of 2 thumb-drives = 4 drives in total.
That'll teach him I thought. At the time. Foolishly.


Now, I am very surprised to find the update process borked all 4 drives.
Every. Single. One. Of .Them.
No amount of yanking cables does a single thing to the boot process.
4 times it complains of not supporting inherited compression algorithms. I would think one complaint should suffice. Regardless of the number of drives attached.
Only when all 4 drives is yanked I get a different result. It still won't boot though. Would be a miracle if it did.

Veeeery odd indeed.
I'll go plug in a new drive tomorrow and see if that makes a difference. I bet it doesn't.
The Mrs. is gonna be pissed tomorrow. She does not cope well with IT troubles, that affect her media consumption.

L8r.

 

[Ericloewe]

A four-way mirror? Wow.

Though you'd have been better off with just the two real SSDs (the USB drives were slowing everything else down), it's pretty much established that this is a logical problem and not a hardware one.

My guess is that the update process failed in a weird way. The devs have been looking into it, but it's hard to reproduce. My guess is that the USB drives are to blame, because of their crap speeds, which may have caused something to timeout.

As for the fix, reinstall the pre-upgrade version to just the two mSATA SSDs and upload your config. By the way, what versions are involved here?

 

[Ghydda]

As for the fix, reinstall the pre-upgrade version to just the two mSATA SSDs and upload your config.

I'm contemplating this myself.

By the way, what versions are involved here?

Not sure exactly what version I was upgrading from, should have made a mental note of this.
The target version was, I presume, the latest stable. Unless the upgrade path demanded intermediate steps. Again I wasn't paying attention. Do you see a pattern emerging here?

Anywow, I'm not complaining, I've made the setup as recommended everywhere on most counts regarding hardware choice, and so far I have had very little go wrong over the years.
Thanks for providing ample reading material and very useful guidance for all to see.


Cheers
/Ghydda

 

[Ghydda]

Well it is up again.

On the first login I'm greeted with a message
CRITICAL: July 7, 2017, 11:14 p.m. - Update failed. Check /data/update.failed for further details



ghydda@freenas:~ % cat /data/update.failed
Traceback (most recent call last):
File "/usr/local/www/freenasUI/manage.py", line 42, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.7/site-packages/django/core/management/base.py", line 242, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/local/lib/python2.7/site-packages/django/core/management/base.py", line 285, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/site-packages/south/management/commands/migrate.py", line 111, in handle
ignore_ghosts = ignore_ghosts,
File "/usr/local/lib/python2.7/site-packages/south/migration/__init__.py", line 200, in migrate_app
applied_all = check_migration_histories(applied_all, delete_ghosts, ignore_ghosts)
File "/usr/local/lib/python2.7/site-packages/south/migration/__init__.py", line 95, in check_migration_histories
raise exceptions.GhostMigrations(ghosts)
south.exceptions.GhostMigrations:

! These migrations are in the database but not on disk:
<directoryservice: 0061_auto__add_field_activedirectory_ad_userdn__add_field_activedirectory_a>
<directoryservice: 0062_create_kerberossettings>
<account: 0024_add_media_user_and_group>
<services: 0195_auto__add_field_nfs_nfs_srv_mountd_log__add_field_nfs_nfs_srv_statd_lo>
<services: 0196_auto__add_field_services_ups_ups_shutdowncmd>
<services: 0197_add_field_AFP_afp_srv_map_acls>
<services: 0198_iscsi_expunge_lun_auto>
<services: 0199_auto__add_field_iscsitargetglobalconfiguration_iscsi_alua>
<system: 0103_auto__add_cloudcredentials>
<system: 0104_auto__add_field_advanced_adv_fqdn_syslog>
<system: 0105_cert_name>
<system: 0107_auto__add_field_advanced_adv_ixalert>
<system: 0108_auto__add_field_advanced_adv_ixfailsafe_email>
<sharing: 0035_auto__add_field_afp_share_afp_auxparams>
<jails: 0037_nuke_virtualbox_from_orbit>
<jails: 0038_retroactively_change_duplicate_mac_addresses>
<tasks: 0005_auto__add_cloudsync>
<tasks: 0006_auto__add_field_cloudsync_direction>
! I'm not trusting myself; either fix this yourself by fiddling
! with the south_migrationhistory table, or pass --delete-ghost-migrations
! to South to have it delete ALL of these records (this may not be good).

I kinda gather this means trouble ahead.
But other than that, it seems to be fine. All jails boot and all drives are accounted for.

Advice will be appreciated on the wisest next course of action.


Cheers!
/Ghydda

 

[Ericloewe]

Well, file a bug with that traceback and let's see where that goes.

 

[Ghydda]

Bug has been dispatched
It does take a while to get past the step: "Generating debug info".
And uploading the traceback didn't finished over night, so I pushed it it through manually.
EDIT: Well it seems it did go through, the WebGUI progress'o'meter just didn't reflect it.