阿兩的筆記本 Ryoutsu's Notebook

最近我們在把Robot升級到3.2.2之後，我想說試試看4.1.2，於是就直接升了上去。沒想到daily build的測試沒發生任何異常。 但不幸的是Jenkins的報表怪怪的: 發生錯誤確Build Success! 趁著颱風假，比較了一下發現新版本的Critical tests測試項目皆為0: 查了一下 官方文件 發現是因為4.0之後，已經把Critical tests概念刪除了，詳細可以參考: Migrating from criticality to SKIP。 解決方法有3種， 自己定義Critical tests，不過看起來5.0就移掉了。 可能可以更新robot framework plugin。我們版本很舊，是1.6.4。因為目前還沒有更新jenkins的計畫，所以我使用了第三個方法。 Build成功與否的Threshold別用Critical tests。 最後測試結果:

考慮到自動測試環境的維護，我們很久以前就使用java去執行robot framework。前陣子開始處理從3.1.2升級到3.2.2的事情，主要先把明確的runtime語法錯誤與deprecate item處理好，這部分內容可以參考: link 。 直到最近才發現，透過SeleniumLibrary執行Choose File去上傳檔案的動作，會導致測試案例timeout。本篇文章主要分享心路歷程與解決方法，我也送了一條issue給robot framework: link 。 我的環境如下: RobotFramework: 3.2.2 Selenium: 3.141.0 SeleniumLibrary: 3.3.1 Remote Selenium Version: selenium-server-standalone-3.141.59 首先並非所有Choose File的動作都會hang住，有些測試案例是可以執行的，但是上傳一個作業系統ISO檔案一定會發生問題。後來我透過wireshark去比對新舊版本的上傳動作，因為我使用 Remote Selenium ，所以Selenium會先把檔案透過REST API發送到Remote Selenium Server上。從下圖我們可以發現，在3.2.2的最後一個TCP封包，比3.1.2大概少了500個bytes。 於是就開始了我trace code之路。包含SeleniumLibrary產生要送給Remote Selenium Server的request內容，還有HTTP Content-Length的計算，我都確認過沒有問題。 最後發現問題是出在socket API的使用上，就是下圖的這支code: 最後發現可能因為開始使用nio的方式送資料，但沒處理到尚未送完的資料內容，而導致發生問題。加一個loop去做計算就可以解決了。 最後我有把解法提供給robot framework官方，在他們出新的版本之前，我是將改完的_socket.py放在我們自己的Lib底下，好讓我們測試可以正常進行。(shutil.py應該也是為了解某個bug而產生的樣子..)

最近在新的開發機上安裝RockyLinux 9.4並且設定git與eclipse。結果要抓code的時候，egit就彈了這個錯誤給我: git@blog.tonylin.idv.tw:tony/commons.git: Unexpected reply from ssh-agent: SSH_AGENT_FAILURE 最後發現有2個解法。方法1，調整ssh key的權限: chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/id_rsa.pub 方法2，到Eclipse Preferences>Git後，別啟用SSH agent:

Intel 13代14代的災情，已經燒好一陣子了，甚至有人提供了測試步驟，讓你可以去測試看你是否為受災戶，詳情可以看以下兩個連結內容: 災情: link 測試: link 不過我腦子沒進水，根本不想去做測試，然後再RMA浪費我自己時間。我大概這個月初就開始等待MSI出新版本來解決我的問題。首先確認一下自己的板子名稱還有BIOS版本，我使用命令提示字元+wmic: wmic baseboard get product,Manufacturer,version,serialnumber wmic bios get BIOSVersion 接著就是上MSI官網下載BIOS，我板子對應連結是: link 。當時我看到8/1版本就有更新CPU的microcode，於是我就更新下去了: 產生了兩個結果: 作業系統啟動金鑰與使用者登入資訊遺失，就是要重新設定。 主機板的音效卡抓不到了。 第二個問題我降回2023年9月的版本就回復了，所以很明顯是BIOS問題，於是我就直接使用提問的功能: 最後MSI給了我一個中繼的測試版，然後再升級到新版本就解決音效卡的問題。但沒想到8/16出的版本才是真正修正這個災情的版本: 請認得0x129，請認得0x129，請認得0x129。 很重要，避免你走冤枉路。

列出兩週內有人修改過的branches 這個可以用來review即將要回master的branch有哪些。使用方法: 使用PowerShell切到repository對應目錄執行以下腳本。如果不要兩週，可以把-14改成你要的天數。 $GIT_REPO_LOCATION="D:\workspace\git\Commons\" cd $GIT_REPO_LOCATION git for-each-ref --sort=-committerdate --format="%(refname:short), %(committerdate:iso8601), %(authorname)" refs/remotes/ | ForEach-Object {     $line = $_ -split ', '     $date = [datetime]$line[1]     if ($date -ge (Get-Date).AddDays(-14)) {         Write-Output $_     } } pause 範例輸出: origin/integration_testing, 2024-08-01 18:54:02 +0800, MJGood origin/staging, 2024-08-01 18:54:02 +0800, MJBad origin/supportCup, 2024-08-01 17:15:21 +0800, MJSmall origin/master, 2024-08-01 12:17:08 +0800, MJBig 列出有哪些branch merge到staging 這個主要是用來解決staging重做的問題，再也不需要肉眼去掃branch了。如果你的branch不叫staging，可以自己把下方名字改掉。使用方法: 使用PowerShell切到repository對應目錄執行以下腳本。 $localBranches = git branch --format="%(refname:short)" | Sort-Object $remoteBranches = git branch -r --format="%(refname:short)&quo

Problem 在系統自動安裝部屬時，可能有以下原因需要更新驅動: 安裝光碟搭載的kernel版本不支援新硬體。 安裝光碟搭載的kernel版本過舊。 最常遇到的問題，莫過於在更新網卡或磁碟陣列驅動了。如果使用kickstart自動部屬，在發生硬體找不到時，應會出現如下圖錯誤: 本篇主要分享我解決此問題的方法，有以下幾個步驟: 準備driver rpm。 製作driverdisk。 指定driverdisk。 調整kickstart檔案。 準備driver rpm 準備rpm目前我試了兩種方法: 直接透過rpmbuild打包Intel下載的驅動包。 自行撰寫rpm spec檔案去產生rpm檔。 透過Intel驅動包產生rpm 最初使用這方法產生的rpm包裝driverdisk，卻發現一直無法正常載入: 在使用方法二與檢查driverdisk程式碼後，發現原因主要有二: kernel-modules版本的判別: .spec的Providers宣告不滿足需求，參考程式碼 link 與 link 。 kernel-modules檔案的副檔名: 檔名需為.ko，參考程式碼 link 。 因此針對Intel驅動包內的.sepc，我做了以下修改(以ixgbe驅動為例): # 原本為Provides: %{name}，修改為以下 Provides: kernel-modules > = 2.6.32- 220   # 原本為將ixgbe.ko改名為ixgbe.ko.new，我改為複製並放入檔案清單中 find lib -name "ixgbe.*o" -exec cp { } { } .new \; \ -fprintf % { _builddir } /% { name } - % { version } / file.list "/%p.new \n /%p \n " 修改後再重新產生的rpm與driverdisk就能夠正常載入驅動。 自行撰寫rpm spec去產生rpm 一開始使用方法一失敗後，並沒足夠時間追究原因，後來是學網路上教學自己寫。 製作driverdisk 我所產生的driverdisk，以iso為主；driverdisk的內容，會長這樣: rhdd3 rpms / rpms

Problem 本篇主要說明如何在RHEL/CentOS7上設定DHCP Timeout。首先在安裝系統或找某個既有系統，觀察某張抓不到DHCP網卡的log: 以上圖測試結果，並且確認過Anaconda的source code，可以得知預設timeout為45秒。在寫本篇文章之前，已經試過了以下幾種方式且失敗: kickstart中加入–dhcptimeout。 在/etc/dhclient.conf與/etc/dhcp/dhclient.conf加入timeout。 在NetworkManager.conf加入ipv4.dhcp-timeout設定。 也透過nmcli試圖修改ipv4.dhcp-timeout設定，但在CentOS7.2上找不到此設定。 以上方法測試於CentOS7.2中。 How to resolve? 經由尋找解答與測試過程中，得知RHEL/CentOS7的安裝環境，網路是透過NetworkManager控制與設定: 而在網卡還沒正常啟動前，NetworkManager每隔一段時間就會透過dhclient重新偵測此網卡。假如你的DHCP Server有機會能在45秒內完成配置，那就不會有問題；如果不行，那請繼續看下去。經過研究一番，我在RHEL7.3 beta release note中，發現是可以在ifcfg設定檔中，加入IPV4_DHCP_TIMEOUT設定dhcp timeout: DHCP timeout in NetworkManager is configurable The faster fallback in a Dynamic Host Configuration Protocol (DHCP) negotiation is useful in case a server is not present. With this update, the user can set the value of the ipv4.dhcp-timeout property or the IPV4_DHCP_TIMEOUT option in the ifcfg files. As a result, NetworkManager waits for a response from the DHCP server only for a giv