ラベル VirtualBox の投稿を表示しています。 すべての投稿を表示
ラベル VirtualBox の投稿を表示しています。 すべての投稿を表示

2019年12月1日日曜日

VirtualBox 6.0.14のdkmsがLinux kernel 5.4の仕様変更でbuildできない (VBox 6.1で対応)

*** update ***

2020-01-21更新: Linux kernel 5.4.13 (1/21現在5.4.x系列の最新版)を試している。既にVBox側で対応済みなため、特に問題なくkernel modulesをbuild、使用できている。

*** updateここまで ***


Linux kernel 5.4からset_pages_x()とset_pages_nx()というfunctionsが削除された。

Debian unstableに入っているVirtualBox 6.0.14はこの変更に対応しておらず、現状ではkernel moduleがbuildできずにerrorになる。

VBoxのdevelopersは既に対応するpatchを作製済みで、6.1RC1としてreleaseしている (cf. [#18945 (Linux 5.4: no more arbitrary executable pages and more changes) – Oracle VM VirtualBox](https://www.virtualbox.org/ticket/18945))。

何れDebian unstableかexperimentalに入るだろう。 2020-01-21現在sidに6.1が入っている。

Linux kernel 5.4 seriesにはi915でgpu resetがtimeoutしてin-flight renderingが止まる問題もあるので、当面は5.3で運用する予定。 2020-01-21現在、5.4.13で特に問題がなさそうなのでこのまま移行できそう。

2018年12月12日水曜日

Kali LinuxをVirtualBoxにinstallしてみた

Hardware requirementsは確認しよう


最初、HDDの領域として最大8 GiBを割り当てたのだがinstallが途中で止まってしまった。

host machineのdmesgにもdirect I/Oがどうのでdiskの内容がcorruptしたかも、みたいな赤文字のerror messageが出た。何事かと思ったら、原因は8 GiBでは足りないことにあった。

Kali Linuxのofficial websiteにあるinstallation prerequisitesによれば:

  • A minimum of 20 GB disk space for the Kali Linux install.
  • RAM for i386 and amd64 architectures, minimum: 1GB, recommended: 2GB or more.
  • CD-DVD Drive / USB boot support

cf. [Kali Linux Hard Disk Install – Kali Linux](https://docs.kali.org/installation/kali-linux-hard-disk-install)

とある。実際、install後にdfで見てみると10 GiB近く (9.6 GiBぐらい)使っていた。これはinstallation processだって止まる。

現在のversionのVirtualBoxはGUI (Virtual Media Manager)から簡単にdisk領域の拡張ができるので8 GiB → 32 GiBに拡張して解決した。

Swap partitionの削除に際しての注意


Partitionの分割を間違ってswapを有効にしてしまったので、fdiskで消してext4 (root partition)に割り当て直してresize2fsで拡張したまでは良かったが、その後bootにやたら時間が掛かるようになってしまった。

systemd-analyzeで見てみたりもしたのだが、いまいち原因が分からず。というのも、systemd-analyzeから詳細が見えるのはsystemdによるboot processであって、systemdが呼び出される前については分からないからだ (systemd-analyze plotで出力できるchartにおける"kernel"の部分)。

GRUB menuからrescue modeで立ち上げてみると、/etc/initramfs-tools/がどうのというmessageが出ており、ここで30 secほど待たされていた。調べてみると、/etc/initramfs-tools/conf.d/resumeというfileに指定されているswap partitionを待っているのが原因と分かった (cf. [#860533 - initramfs-tools: boot delayed by 30sec. due to /scripts/local-block loop - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860533))。

RESUME=none

と変更して解決した (cf. [Linux Manpages Online - man.cx manual pages](https://man.cx/initramfs.conf(5%29))。

Metasploit Frameworkに関する注意


Metasploit FrameworkはDBMS backendとしてPostgreSQLを利用している。

起動時にPostgreSQLへ接続するのだが、折しもPostgreSQL 10 → PostgreSQL 11へのupgradeを先に行ってclusterの移行をせずにそのまま削除したため、port 5432に接続できずerrorとなった。

/etc/postgres/11/main/postgresql.confにて:

port = 5433

となっていた箇所を

port = 5432

に変更して解決した。

PostgreSQL 10のclusterと11のclusterが同時に立ち上げられると、default port 5432が10のclusterで使用され、11のclusterは自動的に5433を使う。この名残りが今回のerrorの原因である。

2018年12月11日火曜日

VirtualBox 5.2のGUI (Qt5)でVirtual Media ManagerからMachine Toolsに戻れない時はtoolbarを出そう

*** 2019-01-24 追記 ***

最近、VirtualBox 6.0 (virtualbox-6.0.2)がDebian experimentalに入った。GUIの見た目が変化しており、この記事の内容は当て嵌らない点がある。

*** 追記ここまで ***


VirtualBoxの管理画面 (GUI)の設定をいじったことをすっかり忘れていて、Virtual Media Managerに遷移したあと (元の) Machine Toolsに戻れない状態になっていた。

調べてみると同じ現象で困っていた人がいて、適当な場所で右クリックしてToolbarを出せば直ると分かった (cf. [virtualbox.org • View topic - \[Resolved\] Manager GUI: How do I switch back from media manager to machines list ?](https://forums.virtualbox.org/viewtopic.php?f=1&t=90242))。

なお、VirtualBoxはDebian sidのrepositoryから導入しており、versionは5.2.22-dfsg-2。


キャプチャ画像で見る復旧までの手順


1. VirtualBoxを起動した時の画面 (Machine Tools)。Defaultの設定からはいじってあるのでToolbarが表示されていない



2. File → Virtual Media Manager を選択すると……



3. Virtual Media Managerに遷移した



4. が……Machine Toolsに戻れない



既に触れた通り、Machine Toolsに戻るにはToolbarを表示させる必要があるので復活させる。

5. Menubar (File Helpなどが並んでいる部分。赤く色を付けた領域)にカーソルを合わせて右クリック



6. Context menuが表示されるので、Show Toolbarを選択する



7. Toolbar (赤く色を付けた領域)が復活した



8. Toolbarの中にあるMachine Toolsボタン (赤く色を付けた部分)をクリック



9. Machine Toolsに戻れた


おつかれさまでした。


おまけ


Machine Toolsにて、Detailsの部分で右クリックすると表示する情報を変更できる。


2018年7月14日土曜日

VirtualBoxのkernel moduleをdkmsでrebuildする

*** VERR_LDRELF_RELOCATION_NOT_SUPPORTED への対応 ***

2018-07-14現在の情報: Debian unstableでVirtualBox (OSE)を利用している場合、最新版5.2.14-dfsg-4ではerrorが再発してVMを実行できない。5.2.14-dsfg-3か、testing或いはstable版を利用されたい。

以前のunstableのpackageはsnapshot.debian.orgなどから取得可能。

cf. [#902897 - virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED) - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902897)

2018-07-16 update: 5.2.14-dfsg-5で修正された模様。

2018-07-17 update: 5.2.14-dfsg-7で(ようやく)修正された模様。


dkmsを手動で


自前でbuildしたkernelをinstallした後、VirtualBoxのkernel object (kernel module)がerrorを吐いてloadできなくなったので、手動でkernel moduleをrebuildした。通常はdkmsでkernel moduleをinstallしていれば、packageやkernelのupgradeに伴い自動でrebuildしてくれるので必要ないのだが。

手順


dkms commandを実行する際にmodule nameとかversion numberとかが必要なので、status subcommandで確認しておく。

% sudo dkms status
virtualbox, 5.2.14, 4.17.6, x86_64: installed

man dkmsを見てみるとautoinstallとかそれっぽいsubcommandがあるのだが、実行してみてもrebuildされなかったので、一旦moduleを削除してやり直してみる:

% sudo dkms remove virtualbox/5.2.14 -k 4.17.6

改めてaddし直す:

% sudo dkms add virtualbox/5.2.14 -k 4.17.6

この時点でmoduleは登録されているが、実際のbuildは行われていない。autoinstall subcommandを発行してrebuildさせてみる:

% sudo dkms autoinstall -k 4.17.6

moduleのbuildが終わるとVirtualBoxのkernel moduleがloadされるはずだが、一応serviceでrestartをかける:

% sudo service virtualbox restart