Is the upgrade issue resolved if we skip enforcing SE for everything in mysql, including TABLE_CATEGORY_USER tables, as in another reply?

> OK, so on further testing of an in place upgrade of 5.5 to 5.6, it seems that
> there are system tables that are reporting as TABLE_CATEGORY_USER,
> specifically, the mysql.user table. Creating a regular end-user table is also
> of this type. So on running mysql_upgrade with some printing of interesting
> info from within check_engine() I get lots of errors (many trimmed for
> brevity):
> **** check_engine    db_name[mysql]    table_name[user]    category[2]
> no_substitution[0]    enf_engine[1]
> InnoDB: Error: trying to create a MySQL system table mysql/user of type
> InnoDB.
> InnoDB: MySQL system tables must be of the MyISAM type!
> **** check_engine    db_name[mysql]    table_name[db]    category[2]
> no_substitution[0]    enf_engine[1]
> InnoDB: Error: trying to create a MySQL system table mysql/db of type InnoDB.
> InnoDB: MySQL system tables must be of the MyISAM type!
> 
> Then eventually a server crash:
> mysqld-debug: /home/glorch/dev/bug1218664/5.6/Percona-
> Server/sql/sql_error.cc:430: void Diagnostics_area::set_ok_status(ulonglong,
> ulonglong, const char*): Assertion `! is_set()' failed.
> 18:14:09 UTC - mysqld got signal 6 ;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly built,
> or misconfigured. This error can also be caused by malfunctioning hardware.
> We will try our best to scrape up some info that will hopefully help
> diagnose the problem, but since we have already crashed,
> something is definitely wrong and this may fail.
> Please help us make Percona Server better by reporting any
> bugs at http://bugs.percona.com/
> 
> key_buffer_size=8388608
> read_buffer_size=131072
> max_used_connections=1
> max_threads=153
> thread_count=1
> connection_count=1
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 69137 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
> 
> Thread pointer: 0x3c6e4b0
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 7f0e74456de0 thread_stack 0x40000
> /data/bin/bug1218664/5.6/bin/mysqld-debug(my_print_stacktrace+0x35)[0xabc4ec]
> /data/bin/bug1218664/5.6/bin/mysqld-debug(handle_fatal_signal+0x42e)[0x7316b6]
> /lib64/libpthread.so.0[0x391b00f500]
> /lib64/libc.so.6(gsignal+0x35)[0x391a8328a5]
> /lib64/libc.so.6(abort+0x175)[0x391a834085]
> /lib64/libc.so.6[0x391a82ba1e]
> /lib64/libc.so.6(__assert_perror_fail+0x0)[0x391a82bae0]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(_ZN16Diagnostics_area13set_ok_statusEyyPKc+0x66)[0x7afcde]
> /data/bin/bug1218664/5.6/bin/mysqld-debug(_Z5my_okP3THDyyPKc+0x4f)[0x7692c0]
> /data/bin/bug1218664/5.6/bin/mysqld-debug(_Z17mysql_alter_tableP3THDPcS1_P24st
> _ha_create_informationP10TABLE_LISTP10Alter_infojP8st_orderb+0x2606)[0x85ea4f]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(_ZN19Sql_cmd_alter_table7executeEP3THD+0x51e)[0x9a95e4]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(_Z21mysql_execute_commandP3THD+0x7e26)[0x7eba9e]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(_Z11mysql_parseP3THDPcjP12Parser_state+0x58a)[0x7eed42]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(_Z16dispatch_command19enum_server_commandP3THDPcj+0xd04)[0x7e14c4]
> /data/bin/bug1218664/5.6/bin/mysqld-debug(_Z10do_commandP3THD+0x3ae)[0x7e0385]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(_Z24do_handle_one_connectionP3THD+0x1cc)[0x7a7c74]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(handle_one_connection+0x33)[0x7a7742]
> /data/bin/bug1218664/5.6/bin/mysqld-debug(pfs_spawn_thread+0x159)[0xdad33f]
> /lib64/libpthread.so.0[0x391b007851]
> /lib64/libc.so.6(clone+0x6d)[0x391a8e811d]
> 
> 
> So I am now not sure what to do. I think at a minimum we need to document in
> our upgrade process that you MUST disable enforce-storage-engine during
> mysql_upgrade. Interestingly enough, if you enable it before initially
> creating your db and calling mysql_install_db you will also get a bunch of
> failures .