根が几帳面なので、ちょっとしたコトでこだわって、結局ハマっちゃって、とんでもないことをヤラかすことが多いのです。
で、今回もGNOMEやVNCの環境を再セットアップしようとremoveして再度install・・・・と。エラーでヤンす。
怪しいと踏んだのが「Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.almalinux.org/mirrorlist/9/appstream」。
色々ネットを探してみたケド、なかなか解決しない。で、最終的にこちらのサイトにすがって見た。
（海よりも深く感謝しております）
こちらはCentOS8での対応で/etc/yum.repos.d配下で以下のパラメータの置換だった。
sed -i ‘s/mirrorlist=/#mirrorlist=/g’ /etc/yum.repos.d/CentOS-*
sed -i ‘s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g’ /etc/yum.repos.d/CentOS-*
AlmaLinuxではドウよ。とファイルをのぞいてみるとbaseurlには大きな変更がなさそうなので・・・
sed -i ‘s/mirrorlist=/#mirrorlist=/g’ /etc/yum.repos.d/almalinux-*
sed -i ‘s/# baseurl/baseurl/g’ /etc/yum.repos.d/almalinux-*
と、単純にコメントアウトの位置を入れ替えたカタチにアレンジしたら・・・
上手く行きました・・・とさ。
よし、いざ作業を続行！！！
M1,M3と入手出来るかぎり安価なサーバーを導入してきましたが、遂に今回はM5になりました。
BIOSでRAID1を組んで、インストーラーの立ち上がりで「e」として、ここでいつもは「modprobe.blacklist=ahci inst.dd」と入れ替えてctrl+X ですが、これで進めるとRAIDのHDDが見えません。
そんな現象になってしまったら「inst.dd」だけ入れてみましょう。
AHCIの除外が悪さをしているらしいです。ドツボにはまったら、AHCIモードで２つのHDDを使ってインストールしちゃってから、改めてRAID1に設定し直してからやってみると上手く行っちゃったりします。
これで３日喰っちゃいました。とほほ。
もう、７年前にリリースしたシステムのなんですが、２年に一度実行されるCSVデータのインポート処理なんですよ。リリースの際ももちろんデータ確認しましたサ。過去２～３回の実施でも問題はなかったんですよ。それが今回はインポートした日付時刻データが１２時間（半日分）ズレるんです。
このデータでは開始日と終了日をエントリするのです。java.util.Calendarで受けてデータベースに永続化してます。
時刻まで管理しますので、開始日では00:00:00.000に、終了日では23:59:59.999をセットして書き込んでます。
CSVファイルによるバッチ処理とは別に、オンライン画面での個別処理もあるのですが、こちらでは何故か問題ありません。
うーん。デバッグ作業では、成功するオンラインと失敗するバッチ処理の比較を行いました。
面倒くさいので、System.out.println(そのcalendarインスタンス)と、ダラダラと表示してみたところ、失敗ではtime=?となっちょるのがわかりました。調べるとその次のareFieldsSet=falseでは失敗で、成功してるのはareFieldsSet=trueとなっちょります。
ググってみると「なるほどザ・ワールド」。
setterで色々なパラをもらうたびに日時を再算出していたのでは大変なので、日時自体の値の呼び出しがあるまで算出しないヨ・・・と。
ははぁ、なのでtime=?なのネ。で、パラと算出値に矛盾がありませんよ・・・ってのがareFieldsSet=trueとのことなんですね。
あ、失敗のパターンではさらにAM_PM=1になっているじゃア～りませんか！！！！！
これだ！！！！！！失敗のパターンでは時刻が午後基準になっちょる。
そうか！calendarのインスタンスに年月日時分秒をセットする前に、clear()してあげるのが正しいお作法なのだろうけど、それをしていないのでnewインスタンスでの現在時刻が午後(AM_PM=1)だと、２時が14時に半日ズレちゃうのね。（終了日なんぞは翌日になっちゃいます）
対処として、時刻のsetterが発生する個所では必ずAM_PM=0もセットするようにして、バグつぶしできました。
今回のバグは、処理を行った時刻が午後である際にしか発生しません。故にテストでも数回の運用でも発覚しなかったのですね。また、オンライン画面ではjavaScriptの日付をDWRでjavaクラスに読み換える実装なので、改めてnewしないのでスナオに時刻をconvertしてくれるので問題は起こらない・・・と。
理屈がわかればガッテンです。ずいぶんとjavaやってますが、こんなコトでこんなバグが発見されるなんて、本当に勉強になりますネ。