PowerShellによるWindows Updateが0x80240023で失敗する(EULAの同意問題)

PowerShellを使って、Windows Updateを行うスクリプトを作成中。

実物はいろんな細かい細工をしているので、似たようなものを作成すると下記のようなものとなる。

$UpdateCollection = New-Object -ComObject Microsoft.Update.UpdateColl
$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = New-Object -ComObject Microsoft.Update.Searcher
$Result = $Searcher.Search("IsInstalled=0 and Type='Software'")
foreach( $Update in $Result.Updates){
    if($Update.AutoSelectOnWebSites -eq $true){
        $UpdateCollection.Add($Update) | Out-Null
    }
}

$Downloader = $Session.CreateUpdateDownloader()
$Downloader.Updates = $UpdateCollection
$DownloadResult = $Downloader.Download()

$Installer = New-Object -ComObject Microsoft.Update.Installer
$Installer.Updates = $UpdateCollection
$InstallerResult = $Installer.Install()

これをWindows7環境で実験を行った。

まず、最初は下記のエラーが出力された。

"0" 個の引数を指定して "Download" を呼び出し中に例外が発生しました: "HRESULT からの例外: 0x80240044"

これは、スクリプトを管理者権限を持たずに実行していたためで、管理者権限を与えることで回避できた。

スクリプトを実行し再起動、ということを何回か行った後、最後の1つになったところで、以下のエラーが出力された。

"0" 個の引数を指定して "Install" を呼び出し中に例外が発生しました: "HRESULT からの例外: 0x80240023"

この「0x80240023」というものは「WU_E_EULAS_DECLINED」というエラー。

適用に失敗したものは「悪意のあるソフトウェアの削除ツール x64 – 2017 年 3月 (KB890830)」

そうです。
手動で適用しようとするとライセンスの同意画面が出てくるやつです。

で・・・探してたら「Windows Update PowerShell Module」というPowerShellでWindows Updateを行うためのモジュールが・・・
ヒントを探してみるとありました。

「$Update.EulaAccepted」が0だったら「$Update.AcceptEula() 」を実行、と

というわけで、修正したものが下記になります。

$UpdateCollection = New-Object -ComObject Microsoft.Update.UpdateColl
$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = New-Object -ComObject Microsoft.Update.Searcher
$Result = $Searcher.Search("IsInstalled=0 and Type='Software'")
foreach( $Update in $Result.Updates){
    if($Update.AutoSelectOnWebSites -eq $true){
        if($Update.EulaAccepted -eq 0){
            $Update.AcceptEula()
        }
        $UpdateCollection.Add($Update) | Out-Null
    }
}

$Downloader = $Session.CreateUpdateDownloader()
$Downloader.Updates = $UpdateCollection
$DownloadResult = $Downloader.Download()

$Installer = New-Object -ComObject Microsoft.Update.Installer
$Installer.Updates = $UpdateCollection
$InstallerResult = $Installer.Install()

(2018/02/05追記)
なお、この記事は同意が必要なものについての対応法だけを記載しています。
普通にWindows Updateを行おうとした場合、ここに書いてあるものだけ適用されないパッチがあります。
そのため「Windows Updateを行うためのPowerShellスクリプト」という記事で詳細を記載しています。

Orange Pi Plus 2Eでのお薦めOSはArmbian

秋葉原でOrange Pi Plus 2Eが、なぜか、いまのタイミングで販売され始めた模様。
なんちゃってと呼ぶにはハイスペックな「Orange Pi Plus 2E」が登場

「なぜか」としたのは、Orange Pi PC2の方が、いまのタイミングだったら、いいんじゃないかなぁ、と思うので・・・
Orange Pi Plus 2の方だったらSATAコネクタがついてるので、NAS用途にって言えるんですが、Orange Pi Plus 2Eだと、あまりお薦めできるポイントが・・・
とりあえず、簡単な比較

・Orange Pi Plus 2Eの利点
 RAMが2GBある(Orange Pi PCとOrange Pi PC2はRAM 1GB)
 オンボードにeMMC 16GBが載っているので、microSDがいらない
 (技適的に駄目なのが、WiFiがオンボード)
 公式通販:Orange Pi Plus 2Eのセット商品。テクノハウス東映で売ってるケースセットは送料込みで$44.39。

・Orange Pi PCの利点
 CPUはOrange Pi Plus 2Eと同じ
 小型
 安い
 技適の問題無し(WiFiを積んでないので)
 公式通販:Orange Pi PCのセット商品。ケースセットは送料込みで$22.56。

・Orange Pi PC2の利点
 CPUは64bitのCortex-A53コア使用のAllwinner H5採用でラズパイ3対抗
 サイズはOrange Pi PCと同じで小型
 Orange Pi Plus 2Eより安い
 技適の問題無し(WiFiを積んでないので)
 公式通販:Orange Pi PC2のセット商品。ケースセットは送料込みで$27.56。

7480円で買うより、公式通販で買って2週間ぐらいで届くのを待ってもいいんじゃないですかね?という気がします。

あと、電源はmicroUSBではなく、PSPと同一形状の極性統一#2/EIAJ#2と言われる形状のものです。
秋葉原で探す場合は、千石電商で、極性統一#2、内径φ1.7、外径:φ4.0のDC05-4017,DC-4017を当たりを探しましょう。

ジャンク屋を巡ると5V機器用のやつでこれを使っているやつがあったりします。ポータブルDVDドライブ用電源だったり、ビデオカメラの電源だったり・・・・探してみても面白いかもしれません。


さて、Orange Pi シリーズですが、公式では「Android 4.4,Ubuntu,Debian,Rasberry Pi Image」とかうたってますが、表現に嘘があります。

「Rasberry Pi Image」です。
これは、「Rasberry pi用のOSがそのまま動く」という意味では無く「Raspberry pi用のOSをOrange Piで動くように改造したものが存在する」という意味です。

また、Orange Pi公式で配布しているUbuntu,Debian,Raspberry Pi Imageですが、Linux kernel部分のアップデートが提供されていません。
サーバとして継続運用するのには向いていないので注意してください。

では、サーバとして継続運用するにはどうすればいいのか?

現状のお薦めは、「Armbian」を使用するということです。
ArmbianはARM系SoC各種向けにDebian/Ubuntuベースで作成されたディストリビューションです。
Kernel周りなどのハードウェア固有のバイナリはArmbianのレポジトリから、それ以外のソフトウェアのバイナリはDebian/Ubuntuのarm用レポジトリから取得する形になっています。
こちらはOrange Pi公式とは異なり、活発に開発されており、セキュリティfixなども、そこそこちゃんとリリースされています。

ダウンロードページから各機種用のページにアクセスし、「Server」もしくは「Desktop」からファイルを入手します。
Serverはコンソールのみ、DesktopはX-Windowが起動します。
初回ログイン時のユーザ名は「root」、パスワードは「1234」です。

また、WiFiが搭載されている場合に、WiFiに接続するにはnmtui-connectコマンドを使用します。
(NetworkManagerを使う設定です)

・・・・え?
Androidを使いたい場合はどうすればいいかって?
Orange Pi公式のAndroidはPlayストアがインストールされていません。
3rdパーティー品でいいのは特にありません。
動作確認程度にしか使えないと思っていいですよ

Xiaomiの自社SoC Surge S1登場。スナドラ625/MediaTek P20対抗

Xiaomi(小米)が、中国のSoCメーカLeadcore Technologyと組んで、オリジナルのSoCを作っている、という話があった。

で・・・MWCにて詳細発表があったようだ。
[Xiaomi] Xiaomi’s First In-House SoC Chipset “Surge S1” Unveiled !

内容の要点
・Snapdragon 625およびMediaTek P10/P20の対抗として、Surge S1を開発
・ARM Cortex-A53コアを使用。2.2GHzコア*4個+1.4GHzコア*4個の計8コア
  28nm HPCプロセス製造
・GPUはARM Mali-T860採用
  Mali-T760と比較し、40%の消費電力削減
・LTEなどの通信機能を司るbaseband部分はOTAによるアップデート可能
  → VoLTEなどで技術革新があっても、あとから対応できる
・独自の画像処理プロセッサー(ISP)により暗いところでの画質などが向上,HDRにも対応
  消費電力や処理時の内部バスの使用帯域幅などが削減されている
・独自の音声処理プロセッサー(DSP)により高音質のVoLTE通話を実現

スナドラ820対抗ぐらいうたってくるかと思ったら、廉価な方で攻める模様。

また、パートナーのLeadcoretechの既存プロセッサって、Cortex-A7までで、Cortex-A53世代って、正式リリースされたものって無いし、LeadcoretechのLTE対応チップセットを採用してる製品もほとんど無いんですよね。
3Gも、中国向けのTD-SCDMA向けばかりですし・・・

果たして、どのレベルに仕上がっているのか…非常に怖いところです。

そんなSurge S1を採用した製品は・・・「Mi 5c」です。

Meet Mi 5c – it’s ultra slim, lightweight, and powered by Surge S1, our first-ever in-house designed SoC chipset. It comes with a 5.15″ JDI display and 1.6mm ultra-thin bezels. Having our own chipset means we’re able to now handle backlight optimization at chipset levels — up to 2048 ultra-precise brightness adjustment levels. It also comes with a large 1.25μm pixel size camera sensor which runs on Surge ISP algorithm, which enhances light sensitivity by up to 150%. The Mi 5c also comes with front fingerprint sensor, 9V 2A fast charging, and is only 132g with its ultra-light metal body. The 3GB+64GB version retails for RMB 1,499. Like it?

Highlights
– Powered by Surge S1, octa-core 64-bit processor (2.2GHz quad-core A53 + 1.4GHz quad-core A53)
– 5.15” display, 550-nit brightness, 2048 brightness levels with ultra-precise backlight controls
– Slim and light premium metal body: 132g and 7.09mm thin
– 2860mAh battery; 9V/2A fast charging
– 3GB + 64GB, dual-channel LPDDR3 + eMMC5.0
– 1.25 micron pixel size, ultra light-sensitive 12MP camera
– Single-frame HDR
– Front fingerprint sensor
– RMB 1,499


まぁ・・・どんな感じでしょうね

Spreadtrumから新SoC SC9861G-IAが登場。IAはIntel Airmontアーキテクチャの意味!

現在開催中のMWC2017にあわせて、中国のSpreadtrumから、新しいSoCが発表されました。

Spreadtrum launches 14nm 8-core 64-bit mid- and high-end LTE SoC platform

Intel AirmountアーキテクチャによるCPUコアを8個と、LTE関連回路をあわせて14nmプロセスで製造した、SC9861G-IAが新登場です。

あ・・・一つお詫びがあります。
「IAはIntel Airmountアーキテクチャの意味」ってタイトルですが、公式に言われたわけじゃないです。なので、もしかするとIntel Architectureの意味かもしれません。

さて、従来SpreadtrumからはSC9860GというCortex-A53コアを8個搭載(2GHzコア*4個+1.25GHzコア*4個)し、TSMC 16nm FFCプロセスで製造したSoCを提供していました。

それの演算部分をIntel Airmontに置き換えたようなものになるようです。

ASUSのIntelプロセッサ搭載のAndroidスマホ/タブレットなどで使われていたIntel Atom Z3530のCPUコアは22nmプロセス製造のSilvermontで、GPUコアはPowerVR GR6430でした。(Z3735DはSilvermont/Intel GPU)
Silvermontの次の世代がAirmontコアなのですが、Intelからのスマホ向けプロセッサはSilvermontで最後ということになっていました。
Windows向けに出ているAirmont世代のAtomプロセッサはAtom x5-Z8300/Z8500ですが、これらのGPUはIntel GPUです。

今回のSC9681G-IAは、CPUコアはAirmontで、GPUはPowerVR GT7200という形となります。
つまりは従来発売されていたIntelプロセッサ搭載のAndroidスマホ/タブレットを置き換える目的に使うようです。

SC9861G-IAの出荷は2017年Q2ということなので、秋ぐらいの製品発表に注目しましょう

CentOS7のcronによるログStarting user-0.sliceなどをmessagesから消す方法

CentOS7でcronによるプログラム実行を有効にすると、5分毎に下記の様な出力がある。

journalctlのログには下記の様な感じで

# journalctl |grep " 2月 28 08:30:01"
 2月 28 08:30:01 blog.osakana.net systemd[1]: Started Session 745 of user username.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Starting Session 745 of user username.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Started Session 744 of user username.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Starting Session 744 of user username.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Created slice user-499.slice.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Starting user-499.slice.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Started Session 743 of user munin.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Starting Session 743 of user munin.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Created slice user-0.slice.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Starting user-0.slice.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Started Session 746 of user root.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Starting Session 746 of user root.
 2月 28 08:30:01 blog.osakana.net CROND[713]: (username) CMD (/~/script/toppage.pl >> /~/tw5-topcheck.txt 2>&1)
 2月 28 08:30:01 blog.osakana.net CROND[723]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
 2月 28 08:30:01 blog.osakana.net CROND[724]: (root) CMD (/usr/lib64/sa/sa1 1 1)
 2月 28 08:30:01 blog.osakana.net systemd[1]: Removed slice user-0.slice.
 2月 28 08:30:01 blog.osakana.net systemd[1]: Stopping user-0.slice.
#

/var/log/messagesの方には下記の様な感じで・・・

# grep "Feb 28 08:30:01" /var/log/messages
Feb 28 08:30:01 blog.osakana.net systemd: Started Session 745 of user username.
Feb 28 08:30:01 blog.osakana.net systemd: Starting Session 745 of user username.
Feb 28 08:30:01 blog.osakana.net systemd: Started Session 744 of user username.
Feb 28 08:30:01 blog.osakana.net systemd: Starting Session 744 of user username.
Feb 28 08:30:01 blog.osakana.net systemd: Created slice user-499.slice.
Feb 28 08:30:01 blog.osakana.net systemd: Starting user-499.slice.
Feb 28 08:30:01 blog.osakana.net systemd: Started Session 743 of user munin.
Feb 28 08:30:01 blog.osakana.net systemd: Starting Session 743 of user munin.
Feb 28 08:30:01 blog.osakana.net systemd: Created slice user-0.slice.
Feb 28 08:30:01 blog.osakana.net systemd: Starting user-0.slice.
Feb 28 08:30:01 blog.osakana.net systemd: Started Session 746 of user root.
Feb 28 08:30:01 blog.osakana.net systemd: Starting Session 746 of user root.
Feb 28 08:30:01 blog.osakana.net systemd: Removed slice user-0.slice.
Feb 28 08:30:01 blog.osakana.net systemd: Stopping user-0.slice.
#

これを消すための方法をググると、 「/etc/systemd/system.confにLogLevel=noticeを書けばok」なんてのが出てきます。

しかし、これはsystemd全体のログを出力させなくするものであって、今回のログ以外にも出てこなくなってしまうものが発生します。

もっと影響範囲が狭い対処方法がないか探したところRedHatサイトで下記を発見
Logs flooded with systemd messages: Created slice & Starting Session
messagesログに systemd メッセージ Created slice や Starting Session が大量に出力される

これは、systemdによるログはrsyslogにより/var/log/messagesに記録されているが、systemdからの特定文字列が含まれるログ出力を無視する設定をrsyslogの設定ファイルに記載する、というやり方です。(journalctlの次の段階の出力を調整する手法のため、journalctlの出力結果は変わらない)

下記のコマンドで/etc/rsyslog.d/ignore-systemd-session-slice.confファイルを作成します。

(下記は2017/2/28時点でのもの)
echo 'if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-") then stop' >/etc/rsyslog.d/ignore-systemd-session-slice.conf
(下記は2020/07/20時点でのもの)
echo 'if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Starting User Slice of" or $msg contains "Removed session" or $msg contains "Removed slice User Slice of" or $msg contains "Stopping User Slice of") then stop' >/etc/rsyslog.d/ignore-systemd-session-slice.conf

作成後、「systemctl restart rsyslog」でrsyslogを再起動します。

# ls -l /etc/rsyslog.d
合計 4
-rw-r--r--. 1 root root 49 11月 22 10:27 listen.conf
# cat /etc/rsyslog.d/listen.conf
$SystemLogSocketName /run/systemd/journal/syslog
# echo 'if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-") then stop' >/etc/rsyslog.d/ignore-systemd-session-slice.conf
# ls -l /etc/rsyslog.d
合計 8
-rw-r--r--. 1 root root 180  2月 28 09:14 ignore-systemd-session-slice.conf
-rw-r--r--. 1 root root  49 11月 22 10:27 listen.conf
# cat /etc/rsyslog.d/ignore-systemd-session-slice.conf
if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-") then stop
# systemctl restart rsyslog
#

上記の対処後の状況を見てみる

# tail /var/log/messages
Feb 28 09:20:01 blog systemd: Removed slice user-0.slice.
Feb 28 09:20:01 blog.osakana.net systemd: Stopping user-0.slice.
Feb 28 09:20:22 blog.osakana.net systemd: Removed slice user-499.slice.
Feb 28 09:20:22 blog.osakana.net systemd: Stopping user-499.slice.
#

/var/log/messages は「Removed slice」と「Stopping user-」が条件になかったので、記録されていました。

このため、下記の様に条件を追加して、対処しました。

# cat /etc/rsyslog.d/ignore-systemd-session-slice.conf
if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Removed slice" or $msg contains "Stopping user-") then stop
$

なお、journalctlの方は引き続き出力ありです。 (今回の対処方法では消せない)

# journalctl |tail
 2月 28 09:30:01 blog.osakana.net systemd[1]: Started Session 783 of user username.
 2月 28 09:30:01 blog.osakana.net systemd[1]: Starting Session 783 of user username.
 2月 28 09:30:01 blog.osakana.net CROND[6940]: (root) CMD (/usr/lib64/sa/sa1 1 1)
 2月 28 09:30:01 blog.osakana.net CROND[6942]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
 2月 28 09:30:01 blog.osakana.net CROND[6943]: (username) CMD (/~/script/toppage.pl >> /~/tw5-topcheck.txt 2>&1)
 2月 28 09:30:01 blog.osakana.net systemd[1]: Removed slice user-0.slice.
 2月 28 09:30:01 blog.osakana.net systemd[1]: Stopping user-0.slice.
 2月 28 09:30:25 blog.osakana.net systemd[1]: Removed slice user-499.slice.
 2月 28 09:30:25 blog.osakana.net systemd[1]: Stopping user-499.slice.
#