SystemRescueCd
電腦突然開不了機, 有時候真的會讓人覺得很沮喪.
大多數無法順利開機的故障, 都只是因為開機所需要的系統檔案無法讀取 (磁區損毀、病毒或意外刪除等), 卻因此造成無法進入系統, 也無法將系統中有用的資料檔案取出.
進行任何進一步的修復工作前, 我們需要一個可順利使用故障系統開機的救援工具, 而 SystemRescueCd 算是此類工具中, shortie 覺得用來還算順手的工具之一.
參考資料
MySQL Workbench 8.0.15
為了發行而發行的版本? 這也算是一招.
This release contains no functional changes and is published to align version number with the MySQL Server 8.0.15 release.
https://dev.mysql.com/doc/relnotes/workbench/en/news-8-0-15.html
MySQL Workbench 8.0.15 About
參考資料
MySQL Workbench 8.0.14
這個版本的亮點是: 完美支援 macOS 10.14 Mojave 與 Dark Mode 配色.
參考資料
EdgeRouter PoE (ERPoe-5) 變磚後該這麼修
公司使用的 ERPoe-5 路由器, 某日在跳電/復電的過程中造成損壞, 使用 Hardware Reset 程序亦無法回復運作, 真真實實的成為一個「磚塊」. 一方面緊急採購了一部 Synology RT2600ac 路由器應急, 一方面也思考如何診斷 ERPoe-5 變磚的真正原因.
準備工作
- RJ45 serial console cable
- 由於同事圈、朋友圈沒人有這條連接線, 因此 shortie 是從 PChome 採購一條備用: 伽利略 USB CONSOLE Cable (FT232) 3m
- TFTP 伺服程式
- 可以用來診斷的電腦是 Ubuntu 18.04 LTS, 因此 shortie 準備的是 tftpd-hpa 伺服程式.
- DHCP 伺服程式
- 呈上點所述條件, shortie 準備的是 isc-dhcp-server 伺服程式.
第一步: 取得 console 連接埠輸出, 確認損壞方式
使用 RJ45 serial console 連接線連接診斷電腦與 ERPoe-5 後, 可利用下列指令接收輸出:
$ screen /dev/ttyUSB0 115200
檢視 ERPoe-5 的輸出之後, 發現 kernel panic 訊息難怪她會變磚了:
第二步: 參考 EMRK 說明, 執行 emrk-reinstall
不論有沒有設定好 DHCP, 進入 U-Boot 提示符號之後, 都可以依照文件中的指示設定 tftpboot所需要的參數. 一旦成功下載 emrk-0.9c.bin 之後, 就可以使用 bootoctlinux $loadaddr 讓 ERPoe-5 成功開機.
開機完成之後, 我們就可執行 emrk-reinstall 從網路下載最新的韌體: http://dl.ubnt.com/firmwares/edgemax/v1.10.x/ER-e100.v1.10.8.5142440.tar讓 ERPoe-5 恢復正常運作. 過程中注意兩點:
- 提供可設定正常上網的 DHCP 對網路設定有幫助.
- 輸入韌體的網址時要小心, 建議檢查三次以上.
後話
整個修復的過程, 從 serial console 輸出的訊息來看都很完美, 可惜的是在執行完重新安裝韌體之後, 重新開機還是出現 Kernel Panic 訊息, 看來公司這個 ERPoe-5 是確確實實變成一個磚塊了.
參考資料
Google 付了四千萬美元給 Fossil 買這東西
這筆交易的標的物是神秘的智慧手錶技術, 據傳聞可能是源自於 Misfit. 花了ˊ這麼些錢, 除了買智財 (IP, intellectual property) 和研發團隊主力之外, 如果沒跟醫療服務扯上一點關係的話, 那就不知道 Google 葫蘆裡賣甚麼藥了.
參考資料
AWS RDS AMVU 行為變更
2018/12/21 從 Personal Health Dashboard 收到 Automatic Minor Version Upgrade (AMVU) 的行為將從 2019/01/14 起變更, 針對有設定 Automatic Minor Version Upgrades 之 RDS instances, 將會安排在 DB instances maintenance 程序中, 進行小改版的升級動作.
今日觀察到 RDS 中的 MySQL instance 因為這個變更, 在維護過程中進行的小改版自動升級:
另外也有些 RDS for MySQL instance 被安排在要來的周末維護過程中, 進行小改版的自動升級動作:
由於手上還有許多正式營運中的 RDS for MySQL instances, 所以將會針對 AMVU 這個行為變更, 再次進行所有實例的檢查, 以免意外發生小改版自動升級, 導致意外事件的發生, 同時也建議處境與 shortie 相同的朋友趕快檢查 AMVU 設定.
AWS Personal Health Dashboard 通知內容
We are notifying you to let you know about a change in behavior of the Automatic Minor Version Upgrade (AMVU) feature in Amazon RDS. You are receiving this email because you have had one or more active Amazon RDS database instances with the AMVU property set to TRUE.
Beginning on January 14, 2019, Automatic Minor Version Upgrades will be scheduled through the DB instance maintenance process[1]. You will see when a minor engine version upgrade is scheduled to be applied to your database instance in the AWS Console or through the describe-pending-maintenance-actions command in the AWS CLI. You can also choose to apply AMVU immediately by clicking Apply Now in the AWS Console or via the apply-pending-maintenance-actions command in the AWS CLI.
As the behavior of this feature is changing, we have set the Auto Minor Version Upgrade property to FALSE on all existing RDS for SQL Server and RDS for Oracle DB instances. If you would like to re-enable AMVU for these DB instances, you can enable it via the RDS Console, CLI, or API.
The AMVU property for existing RDS for MySQL, MariaDB, and PostgreSQL database instances has not been changed. If you do not want your database instance to be automatically upgraded to the default engine minor version, you can modify the database instance and set this property to FALSE.
RDS DB instances with the auto minor version upgrade property set to TRUE that are not running the latest minor database engine version will be scheduled to be upgraded during the maintenance window specified for each database instance.
from RDS operational notification
參考資料
- https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html
- https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Upgrading.html
屬靈操練
從 AMVU 這個自動套用小改版更新的設計, 聯想到既然人所創造的 AWS RDS for MySQL 都免不了要持續更新, 我們同時也要記得我們的神, 應許了我們在基督裡的更新、恢復與超越, 包括心理的與靈裡的. 在此以羅馬書 12:2 一起跟眾弟兄姊妹自我期許, 「 不要模倣這世代，反要藉著心思的更新而變化，叫你們驗證何為神那美好、可喜悅、並純全的旨意。」.
MySQL 修改預存程序的參數與內容
預存程序部署到線上資料庫之後, 難免會因為規格修改, 而需要更動參數或內容, 這時候就會驚喜地發現, 原來 MySQL 的 ALTER PROCEDURE 無法修改參數或內容的定義. 雖然很難接受這個事實, 但是人在屋簷下, 也不得不低頭.
那該怎麼做呢? 只能用先刪除再建立預存程序的方法:
USE MyDB;
DROP PROCEDURE IF EXISTS pr_MyStoredProcedure;
DELIMITER //
CREATE PROCEDURE pr_MystoredProcedure(parm_1, ...)
BEGIN
...
END //
DELIMITER ;
已經跟 RDBMS 打交道過一陣子的人, 就會知道上面的程序, 在應用系統負載重的時候, 是會出亂子的.
因此為了避免應用系統突然出現錯誤或效能出現問題, 建議跟開發團隊一起審查該預存程序的使用情境與頻率, 如果可能的話視情況建議開發團隊使用比較安全的上線程序.
參考資料
Windows 10 未更新 SMB 分享資源新密碼的解決方案
在 Windows 10 登入 SMB 分享資源 (NAS, Windows shared folder) 時, 可以選擇將登入帳號 & 密碼記住, 再次使用該分享資源時, 可直接登入使用.
一般情況下, 管理人員會因為安全政策的規定而變更 SMB 分享資源的密碼, 導致登入時無法套用先前儲存之帳號密碼, 而必須重新輸入密碼.
Windows 10 也很貼心地在登入介面中提供儲存新密碼的 Checkbox, 大部分時候都可成功將新密碼套用至設定中. 唯在某些特定情況下, 新密碼無法被儲存, 導致每次使用該分享資源都必須重新輸入密碼, 實在是一件惱人的情況.
碰到這種萬中選一的情況, 我們可以手動更新登入設定, 強制下次登入時使用新密碼.
步驟一:
進入 Control Panel > User Accounts > Credential Manager > Windows Credentials 畫面, 選擇先前已經儲存之設定.
步驟二:
將新密碼更新至該設定中.
密碼更新之後, 下次登入該資源時, 即可自動登入, 被打亂的世界又可再次回復到熟悉的運轉模式之中了.
參考資料
MySQL Workbench 8.0.13 已經發行
Shortie 已經將手邊的 8.0.12 更新至 8.0.13, 未發現任何重大問題, 建議有在使用這個工具的使用者均應升級至此版本.
註: 原本認為此版本應該會啟用對暗黑模式的支援, 不料更新內容中告訴大家還要再等等…
MySQL Workbench on macOS 10.14 Mojave was tested with positive results. The new Dark Mode feature is not yet compatible with all screens and should not be enabled for this release.
from “Changes in MySQL Workbench 8.0.13”
參考資料
CentOS 7.5 升級 Zabbix 4.0 疑難排解
理論上這個升級工作, 應該是屬無無痛升級之類的工作, 沒想到依照官方文件 Upgrade procedure 中所述, 升級 repository 設定套件之後, 卻無法順利更新 Zabbix 4.0 相關套件. 也就是說下列指令會顯示 “No packages marked for update” :
# yum upgrade zabbix-server-mysql zabbix-web-mysql zabbix-agent
解決方式有二:
- yum clean all
- yum –disableplugin=fastestmirror