資生堂とNTTは9月18日、資生堂の感性科学研究の知見とNTTの非接触情報提示技術を融合させ、遠隔・非接触で化粧品の触り心地を視覚や聴覚を通して体験可能にする新技術の開発を目指し、共同研究を開始したことを発表した。
⇧ 脳科学的な話になってくるんですかね？
とりあえず、
⇧ という考え方があるらしいですが、
「我思う、故に我在り」（われおもう、ゆえにわれあり、仏: Je pense, donc je suis、羅: Cogito ergo sum、英: I think, therefore I am）は、デカルトが仏語の自著『方法序説』（Discours de la méthode）の中で提唱した有名な命題である。
⇧ 最終的には、脳が処理して認知に至るという気はしますな。
一番良い例は、
幻肢痛（げんしつう、英: phantom pain）は、怪我や病気によって四肢を切断した患者の多くが体験する、難治性の疼痛。心身症に該当する。
先天性無痛無汗症（せんてんせいむつうむかんしょう、英: congenital insensitivity to pain with anhidrosis、CIPA）とは、運動麻痺を伴わない、全身の無痛を主症状とする疾患である。温痛覚障害に自律神経障害を合併する遺伝性疾患を、遺伝性感覚性自律神経性ニューロパチーと呼ぶが、このうちIV型とV型が本疾患に相当する。
⇧ 痛みとかですかね。
脳が上手いこと処理できないと。
触覚に作用する脳のメカニズムが解明されれば、非接触で触覚に影響を与えられるかもしれない、所謂、感覚訴求ってのが実現できるかもってことですかね。
RHEL（RedHat Enterprise Linux）のサポートとか
そういえば、
⇧「CentOS 7系」が「EOL（End Of Life）」になったなぁ、と思ってVirtualBoxにインストールしていた「RHEL（RedHat Enterprise Linux）7系」ってどうなるんだろうと気になったのですが、
⇧ まぁ、バージョンアップした方が良いですよね～。
VirtualBoxにインストールしていたRHEL 7系を8系へバージョンアップしてみた
というわけで、まずは、バージョン8系にアップグレードしてみることに。
RedHatの公式のアップグレード手順が公開されているようなので、
⇧ 上記の手順を元に、アップグレードしてみますか。
⇧ 上記サイト様も参考にさせていただきました。
VirtualBoxの仮想マシン（OSが「RHEL 7系」）を起動します。
■サブスクライブされているか確認
subscription-manager status
■インストール済みのRedHat社の製品を確認
subscription-manager list --installed
■Base リポジトリーを有効にします
subscription-manager repos --enable rhel-7-server-rpms
■Leapp およびその依存関係が利用可能な Extras リポジトリーを有効にします
subscription-manager repos --enable rhel-7-server-extras-rpms
■最新の RHEL 7 コンテンツを使用するように Red Hat Subscription Manager を設定します
subscription-manager release --unset
■指定したバージョンにパッケージをロックするために yum-plugin-versionlock プラグインを使用している場合は、次のコマンドを実行してロックを解除します
yum versionlock clear
⇧ versionlockなるものは見つからないと。
何か、「Tera Term」の接続が何回も落ちるので、直接、VirtualBoxの仮想マシンのターミナルでSSHログインして実行。
■Leapp ユーティリティーをインストールします。
yum install leapp-upgrade
leapp-upgradeがインストールできたら、以下を実施。
■インストールされているパッケージのバージョンを最新に更新する
yum update -y
■システムの再起動
reboot
そしたらば、バージョンアップできるかどうかのチェックを行います。
■アップグレード前の事前確認
leapp preupgrade --no-rhsm
⇧ 何やら、赤字が気になりますが、「Inhibitors」の数は0になっている必要があるのですが、3つあるとなっているので、ログを確認する。
■/var/log/leapp/leapp-report.txt の確認
[root@redhat7 ~]# grep -3 "Risk Factor: high" /var/log/leapp/leapp-report.txt
Risk Factor: high (inhibitor)
Title: Leapp detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed.
Summary: Support for the following RHEL 7 device drivers has been removed in RHEL 8:
- pata_acpi
--
- Leapp upgrade fail with error "Inhibitor: Detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed.": https://access.redhat.com/solutions/5436131
Key: f08a07da902958defa4f5c2699fae9ec2eb67c5b
----------------------------------------
Risk Factor: high (inhibitor)
Title: Using RHSM has been skipped but no custom or RHUI repositories have been delivered.
Summary: Leapp is run in the mode when the Red Hat Subscription Manager is not used (the --no-rhsm option or the LEAPP_NO_RHSM=1 environment variable has been set) so leapp is not able to obtain YUM/DNF repositories with the content for the target system in the standard way. The content has to be delivered either by user manually or, in case of public clouds, by a special Leapp package for RHUI environments.
Related links:
--
Key: cbf9e2a5e21f047ae0954fb5e0fc0f21b02dcbb0
----------------------------------------
Risk Factor: high (inhibitor)
Title: Missing required answers in the answer file
Summary: One or more sections in answerfile are missing user choices: remove_pam_pkcs11_module_check.confirm
For more information consult https://red.ht/leapp-dialogs.
--
[command] leapp answer --section remove_pam_pkcs11_module_check.confirm=True
Key: d35f6c6b1b1fa6924ef442e3670d90fa92f0d54b
----------------------------------------
Risk Factor: high
Title: Packages available in excluded repositories will not be installed
Summary: 2 packages will be skipped because they are available only in target system repositories that are intentionally excluded from the list of repositories used during the upgrade. See the report message titled "Excluded target system repositories" for details.
The list of these packages:
--
- rpcgen (repoid: codeready-builder-for-rhel-8-x86_64-rpms)
Key: 2437e204808f987477c0e9be8e4c95b3a87a9f3e
----------------------------------------
Risk Factor: high
Title: Leapp detected loaded kernel drivers which are no longer maintained in RHEL 8.
Summary: The following RHEL 7 device drivers are no longer maintained RHEL 8:
- e1000
--
Key: 0ff2413fd3cb0358736bf9be597f4dbdf58f2c4d
----------------------------------------
Risk Factor: high
Title: GRUB2 core will be automatically updated during the upgrade
Summary: On legacy (BIOS) systems, GRUB2 core (located in the gap between the MBR and the first partition) cannot be updated during the rpm transaction and Leapp has to initiate the update running "grub2-install" after the transaction. No action is needed before the upgrade. After the upgrade, it is recommended to check the GRUB configuration.
Key: ac7030e05d2ee248d34f08a9fa040b352bc410a3
----------------------------------------
Risk Factor: high
Title: Difference in Python versions and support in RHEL 8
Summary: In RHEL 8, there is no 'python' command. Python 3 (backward incompatible) is the primary Python version and Python 2 is available with limited support and limited set of packages. If you no longer require Python 2 packages following the upgrade, please remove them. Read more here: https://red.ht/rhel-8-python
Related links:
何やら、RedHatの公式のドキュメントだと、詳細が端折られている...
『Risk Factor: high (inhibitor)』という指摘について対応する必要があるらしいのだが、どんな対応をすれば良いのかがパッと分からない...
何と言うか、
⇧ クリーンインストールとか望ましい場合もあるって、それは最早「バージョンアップ」とは言わない気がするんだが...
とりあえず、参考サイト様の情報を元に「Inhibitors」の数は0にすべく対応する。
自分の環境は、
⇧ の『RHSM なしでアップグレード する場合、または 「RHUI（Red Hat Update Infrastructure）」を使用する場合は、--no-rhsm オプションを追加します。』に該当しないのか、オプションが不要だったっぽい。
「Inhibitors」の数は0にすべく対応が完了したら、改めて「アップグレード前の事前確認」を行う。
■アップグレード前の事前確認
leapp preupgrade
⇧ 一応、「Error」と「inhibitor」の数は0になったので、アップグレードしてみる。
「HIGH severity reports」の数が4つとか気になりますが...
以下、コマンド実行後、かなり時間かかります。
■RHEL 7 システムで、アップグレードプロセスを開始します
leapp upgrade
⇧ うむ、バージョンアップできたのか、サッパリ分からない...
とりあえず、rebootしてみます。
何か、パッケージのインストールとかが始まったんだが...
⇧ 何やら、不審な挙動を起こしているが、RHEL 7系から8系にバージョンアップされたように見える。
RHEL（RedHat Enterprise Linux）8系にバージョンアップできたか確認
再起動が完了したら、ログインし「OS（Operation System）」のバージョンアップができたのか確認してみます。
cat /etc/os-release
⇧ RHEL 7系から8系へバージョンアップできたようです。
まぁ、VirtualBoxの環境は、使い捨てにするようなものなので、バージョンアップではなくて、新規にインストールしてしまうことが多そうな気はしますな。
アップグレード後のタスクを実行する
何やら、7系から8系へのアップグレード後に、実行が必要なことがあるようなので、実施していく。
アップグレードによって不要になったファイル群などは、自動で削除はしてくれないようなので、明示的に手動で削除する。
■除外 リストからすべてのパッケージを削除する
yum config-manager --save --setopt exclude=''
残りの Leapp パッケージを含む残りの RHEL 7 パッケージを削除します
■以前のカーネルバージョンを確認します
cd /lib/modules && ls -d *.el7*
■以前のカーネルから弱いモジュールを削除します
※ 以下、カーネルバージョンなどはご自身の環境に合わせてください。
[ -x /usr/sbin/weak-modules ] && /usr/sbin/weak-modules --remove-kernel 3.10.0-1160.102.1.el7.x86_64
[ -x /usr/sbin/weak-modules ] && /usr/sbin/weak-modules --remove-kernel 3.10.0-1160.119.1.el7.x86_64
[ -x /usr/sbin/weak-modules ] && /usr/sbin/weak-modules --remove-kernel 3.10.0-1160.el7.x86_64
※ 以下、カーネルバージョンなどはご自身の環境に合わせてください。
/bin/kernel-install remove 3.10.0-1160.102.1.el7.x86_64 /lib/modules/3.10.0-1160.102.1.el7.x86_64/vmlinuz
/bin/kernel-install remove 3.10.0-1160.119.1.el7.x86_64 /lib/modules/3.10.0-1160.119.1.el7.x86_64/vmlinuz
/bin/kernel-install remove 3.10.0-1160.el7.x86_64 /lib/modules/3.10.0-1160.el7.x86_64/vmlinuz
■残りの RHEL 7 パッケージを見つけます
rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
■RHEL 8 システムから、古いカーネルパッケージなど、残りの RHEL 7 パッケージと kernel-workaround パッケージを削除します
yum remove kernel-workaround $(rpm -qa | grep \.el7 | grep -vE 'gpg-pubkey|libmodulemd|katello-ca-consumer`)
■残りの Leapp 依存関係パッケージを削除します
yum remove leapp-deps-el8 leapp-repository-deps-el8
■残りの空のディレクトリーを削除します
rm -r /lib/modules/*el7*
■オプション: 残っているすべてのアップグレード関連データをシステムから削除します
rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leapp
■既存のレスキューカーネルと初期 RAM ディスクを削除します
rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*
■レスキューカーネルと関連する初期 RAM ディスクを再インストールします
/usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"
■古いカーネルがブートローダーエントリーから削除されていることを確認します
grubby --info=ALL | grep "\.el7" || echo "Old kernels are not present in the bootloader."
■以前に削除したレスキューカーネルとレスキュー初期 RAM ディスクファイルが現在のカーネル用に作成されていることを確認します
ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue* lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"
■レスキューブートエントリーが既存のレスキューファイルを参照していることを確認します
grubby --info $(ls /boot/vmlinuz-*rescue*)
⇧ までを一通り実行する必要があると。
とりあえず、「Tera Term」からのホスト接続が安定しなさ過ぎて、コマンドを手入力しないといけなかったのが辛過ぎたんだが...
後は、「HIGH severity reports」とかが残っているからして、RHEL 8系をクリーンインストールした方が良いんじゃないかという気がしてならない...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
