阿兩的筆記本 Ryoutsu's Notebook

最近我們將RobotFramework升級至4.1.2，因為Jython的關係這個是目前可以使用Java執行的最後版本。 我們目前Selenium相關的Libraries版本如下: Selenium2Library - 3.0.0 (Latest, https://github.com/robotframework/Selenium2Library ) SeleniumLibrary - 3.0.0 ( https://github.com/robotframework/SeleniumLibrary/releases ) Selenium - 3.8.0 其中Selenium2Library已經沒在維護，也是最後一個版本，它所做的事情僅僅是把keyword forward給SeleniumLibrary。所以升級重點在SeleniumLibrary與Selenium。 而要升級這些Libraries，最重要的就是要知道它們彼此之間的相依，還有python版本的支援度。在我查詢套件的release note之後，因為4.1.2版本的jython只能支援到python 2.7.x，所以能升級的版本就有限制。其中SeleniumLibrary的情況如下: SeleniumLibrary 5.0.0 - 不支援Python 2 and Jython  SeleniumLibrary 4.5.0 - Python 2.7 and Selenium 3.141.0+  SeleniumLibrary 3.3.1 - Python 2.7 and Selenium 3.4+ 所以搭配了Selenium後，以下為我的第一個升級計畫: Selenium - 3.141.0 SeleniumLibrary - 3.3.。主要想確定是否會有deprecated items產生。 升級方式就是把以上原始碼丟到Lib底下，執行robot測試的時候會透過jython重新編譯。在我執行後，出現了urllib3找不到的問題: 我想可能是原本的套件中有包含urllib3，因此我到urllib3的package網站查了release note，找了可以匹配python 2.7的版本: urllib3 - 1.26.20 (https://pypi.org/project/...

最近我們在把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="%(re...

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...

 Problem  在answer file中設定網卡名稱後，安裝時會停在以下畫面: 所使用的command參數如下: network --onboot = yes --bootproto =dhcp --ipv6 =auto --device =eth1 Diagnostic Result 這樣的參數，以前試驗過是可以安裝完成的。因此在發生這個問題後，我檢查了它的debug console: 從console得知，eth1可能是沒有連接網路線或者是網路太慢而導致的問題。後來和Ivy再三確認，有問題的是有接網路線的網卡，且問題是發生在activate階段: Solution 我想既然有retry應該就有次數或者timeout限制，因此發現在Anaconda的說明文件中( link )，有提到dhcptimeout這個boot參數。看了一些人的使用範例，應該是可以直接串在isolinux.cfg中，如下: default linux ksdevice = link ip =dhcp ks =cdrom: / ks.cfg dhcptimeout = 90 然而我在RHEL/CentOS 6.7與6.8試驗後都無效。 因此我就拿了顯示的錯誤字串，問問Google大師，想找一下Anaconda source code來看一下。最後找到別人根據Anaconda code修改的版本: link ，關鍵在於setupIfaceStruct函式中的setupIfaceStruct與readNetConfig: setupIfaceStruct: 會在dhcp時設定dhcptimeout。 readNetConfig: 在writeEnabledNetInfo將timeout寫入dhclient config中；在wait_for_iface_activation內會根據timeout做retry。 再來從log與code可以得知，它讀取的檔案是answer file而不是boot command line。因此我接下來的測試，就是在answer file的network command上加入dhcptimeout: network --onboot = yes --bootproto =dhcp --ipv6 =auto --device =eth1 --...

Problem Ubuntu在安裝過程中，會在%pre後如下圖的階段去設定網路: 而我們曾遇過幾次DHCP取不到的問題。本篇文章主要告訴你，如何去設定DHCP Timeout。 Diagnostic Result 首先是確認Ubuntu使用什麼工具去透過DHCP取得IP，通常都是使用dhclient。檢查/var/log/syslog可以確定是dhclient:(以下的圖有將timeout改為40秒) 接著就是確認dhclient設定檔。通常dhclient設定檔會放在/etc/dhclient.conf或/etc/dhcp/dhclient.conf中，而在整個安裝過程中，你可能會找到三個dhclient設定檔: /mnt/etc/dhcp/dhclient.conf /target/etc/dhcp/dhclient.conf /etc/dhclient.conf 第一個是安裝來源(如光碟)所攜帶的；第二個是安裝完系統上的；第三個則是安裝環境使用的，必須kickstart中network使用dhcp才會出現。此外，檢查/etc/dhclient.conf可以發現預設的timeout為30秒。 How to resolve? 使用preseed 首先在isolinux.cfg的append中加入preseed檔案路徑:(以檔名test.seed為例) append file = / cdrom / test.seed initrd = / install / initrd.gz ks =cdrom: / ks.cfg 而test.seed內要包含以下設定: d-i netcfg / dhcp_timeout string 60 d-i netcfg / dhcpv6_timeout string 60 在安裝過程中，可以去檢查/etc/dhclient.conf，會改成你所設定的值: 使用udhcpc 假如不想透過preseed的方式，可以透過udhcpc。udhcpc是BusyBox內建的DHCP client程式，你可以這樣去設定timeout: udhcpc -i eno2 -T 90 -n -T是timeout；-n則是代表發生錯誤後就離開。 使用dhclient 在經過installer的網路設定階段後，dhclient套件...

Basic Process 在RHEL/CentOS、VMWare ESXI與SLES的自動安裝系統流程中，都有pre與post階段。Ubuntu的kickstart檔案，也提供了pre與post區塊；但Ubuntu與其它distribution最大差異在於: pre階段並沒載入網卡驅動。它的流程像這樣: Run pre script。 Detect HW。 Install OS。 Run post script。 在Detect HW階段，會去偵測並設定網卡。 Multiple NICs Warning 當你有兩張以上網卡且都可以連線的時候，安裝就會停住，並要求你選一張:(圖片來自於 link ) 原先我是在preseed檔案中宣告了: d-i netcfg / choose_interface select auto 但它卻很惱殘的選第一張且無法連線的網卡。後來爬文發現這是一個bug，所以改在isolinux.cfg或grub.cfg中串入以下參數: netcfg / choose_interface =auto 以isolinux.cfg為例: append file = / cdrom / example.seed initrd = / install / initrd.gz ks =cdrom: / ks.cfg netcfg / choose_interface =auto 如此就會自動挑一張可以用的或者是你在kickstart檔案中所宣告的device名稱。 Config Multiple NICs 在RHEL/CentOS中，面對多張需要被設定的網卡，你可以在kickstart檔案中，透過多個network指令與–device參數去完成設定。而在Ubuntu上，即使你設定了多個network指令，也只有最後一個會生效。這意味著以下的內容只有em2會在第二階段被設定: network --bootproto =dhcp --device =em1 network --bootproto =dhcp --device =em2 這個問題我目前的解決方式是在%post的區塊去設定網卡。我提供設定dhcp的方式給大家參考: % post --interpreter = / bin / bash FILE_NET_CONFIG = / etc / ne...

Useful configurations Disable self update SLES15在安裝之前，會先透過線上下載最新的安裝程式內容，如果不想執行這段可以用以下設定略過，如果“你沒設定”且網路連不到它也會自動略過: <general > <self_update config:type = "boolean" > false </self_update > ... </general > 如果你有設定為true，沒網路就會GG。 Disable Installing Recommended Packages/Pattern install_recommended預設為true，會安裝所有的Packages；把它disable後，就可以設定自己要安裝的packages: <software > <install_recommended config:type = "boolean" > false </install_recommended > ... </software > Know-How DVD iso SLES15後所提供的DVD iso，細分成三種用途，我以SLES15 SP1為例子: SLE-15-SP1-Installer-DVD-x86_64-GM-DVD1.iso: 安裝程式，僅提供執行安裝程式的能力。 SLE-15-SP1-Installer-DVD-x86_64-GM-DVD2.iso: Source code。 SLE-15-SP1-Packages-x86_64-GM-DVD1.iso: 所有要安裝的套件。 Addon 在answer file中，有一個add-on block可以指定要安裝的模組，這邊記錄幾個重要的模組，詳情可以參考Deployment Guide: Basesystem Module: 預設會被安裝的模組，提供了base system。 Desktop Applications Module: 提供Desktop與相關的應用程式模組。 Server Applications Module: 提供Server相關packages的模...

Problem 剛好碰到有人把使用過Intel RAID的硬碟，拔起來插在另外一台上；在用KS安裝時，會出現以下訊息 檢查發現有/dev/md*映射檔案，應是偵測到有RAID資訊，但實際上是沒做Intel RAID。 How to resolve? 假如是硬碟sda，可以透過以下指令清掉RAID資訊，問題即解決。 dd if = / dev / zero of = / dev / sda bs = 512 seek =$ ( ( $ ( blockdev --getsz / dev / sda ) - 1024 ) ) count = 1024 Reference Removing RAID metadata

Introduction Answer File指的是執行無人安裝時所使用到的應答檔案，本篇主要收集編輯Answer File所遇到想到的問題。(以下在ESXI6 update 2做測試) Problems Required Items rootpw: 設定root密碼 accepteula或vmaccepteula: 接受VMware License Agreement Network 問題1: 目前知道無法設定超過一個，超過一個會出現警告說使用最後一個: 此外，繼續安裝下去會發生錯誤: 訊息如下，原因有空再研究: 問題2: 設定錯誤名稱則會出現dialog告訴你無法繼續安裝下去。 問題3: 如果在安裝pre階段去enable所有網卡後，且device設定非vmnic0(即vmnic1+)；在configuring network switch階段會出現operation Busy的錯誤。 Encrypted Password 如果要使用編碼過的password，密碼可以透過以下方式編碼(MD5): openssl passwd -1 ( rootpw ) 而answer file內需放入–iscrypted: rootpw --iscrypted $1 $KB .cKvYa $OjgDiG1Z7O7mkjX0t79vW0 如果你的密碼有問題，在安裝畫面會跳出Crypted password is not valid。 keyboard ESXI website聲稱有效值為: Default, French, German, Japanese, Russian, 'United Kingdom' 在ESXI6u2使用Default會出現invalid keyboard type警告，改用'US Default'則會正常。可使用'US Default'的版本: 6u2、5.5u2。 何謂firstdisk? clearpart、part、install、upgrade與installorupgrade都有firstdisk的參數，而fistdisk支援local、remote與usb三種type，預設順序為local>remote>usb。按照目前測試結果，所謂的local firstdisk，以下圖...