プレシードの自動パーティショニング
ここ数年、VMの自動インストールに次のpartman設定を使用しています。
d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string regular
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman/alignment string "optimal"
d-i partman-auto/expert_recipe string \
boot-root :: \
64 512 300% linux-swap \
$primary{ } \
method{ swap } format{ } \
. \
500 10000 1000000000 ext4 \
$primary{ } $bootable{ } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ / } \
.
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
これにより、最初に小さなスワップパーティションが作成され、残りのディスクがルートパーティションとして使用されます。これはうまく機能し、仮想ディスクのサイズを増やす必要がある場合に、パーティションを簡単に拡張できます。
今、私はこのレシピを適応させて、同じベアメタルサーバーをいくつかインストールしようとしています。これを行うには、パーティションを切り替えて、サイズを256GB RAMおよび460GBシステムディスク（ハードウェアRAID1のSSDですが、重要ではありません）のマシンでより適切な値に設定します。
boot-root :: \
32768 65536 1000000000 ext4 \
$primary{ } $bootable{ } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ / } \
. \
16384 16384 65536 linux-swap \
$primary{ } \
method{ swap } format{ } \
.
残りのpartman*ディレクティブは同じです。
私がドキュメントを理解している限り（そして追加の このような投稿 ）、これにより、ディスク全体にまたがる大きなルートパーティションが作成され、最後にスワップパーティションが16〜64 GBになるはずです。
まあ、そうではありません。 450MBのパーティションを作成し、続いて460GBのスワップパーティションを作成します。
VMのプレシードと同じマシンをインストールすると、プレシードファイルで定義されているとおりにパーティションが正しく作成されます。
では、ベアメタルマシンのレシピで何が問題になっていますか？
問題がある場合、インストールisoはUbuntu 16.04.5サーバーisoに基づいています。
fdisk /dev/sdaおよびparted /dev/sda printの出力：
私が試したいくつかのバリエーション：
# this belongs to tha last block, as suggested by @Peter
#d-i partman-basicfilesystems/choose_label string gpt
#d-i partman-basicfilesystems/default_label string gpt
#d-i partman-partitioning/choose_label string gpt
#d-i partman-partitioning/default_label string gpt
#d-i partman/choose_label string gpt
#d-i partman/default_label string gpt
d-i partman-auto/expert_recipe string \
boot-root :: \
##########################
65536 1 -1 ext4 \
$primary{ } $bootable{ } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ / } \
. \
65536 65536 65536 linux-swap \
$primary{ } \
method{ swap } format{ } \
.
##########################
# 1 1 -1 ext4 \
# $primary{ } $bootable{ } \
# method{ format } format{ } \
# use_filesystem{ } filesystem{ ext4 } \
# mountpoint{ / } \
# . \
# 65536 65536 65536 linux-swap \
# $primary{ } \
# method{ swap } format{ } \
# .
##########################
# 32768 50 5242880 ext4 \
# $primary{ } $bootable{ } \
# method{ format } format{ } \
# use_filesystem{ } filesystem{ ext4 } \
# mountpoint{ / } \
# . \
# 16384 100 65536 linux-swap \
# $primary{ } \
# method{ swap } format{ } \
# .
##########################
# use along with the annoted partman-* directives above
# 538 538 1075 free \
# $iflabel{ gpt } \
# $reusemethod{ } \
# method{ efi } \
# format{ } \
# . \
# 1 1 -1 ext4 \
# $primary{ } $bootable{ } \
# method{ format } format{ } \
# use_filesystem{ } filesystem{ ext4 } \
# mountpoint{ / } \
# . \
# 65536 65536 65536 linux-swap \
# $primary{ } \
# method{ swap } format { } \ .
# .
違いはありません。結果のルートパーティションには常に453MBしかありません。
TL; DR：
間違ったイメージがマウントされました。私をそのように指摘してくれた@Peterに感謝します。
長い話：
Petersがコメントした後、isoビルドパイプライン全体、.seedファイル、isolinux txt.cfg、カスタムブートロゴ、.isoをビルドするbashスクリプトを再確認し、何も問題がないことを確認しました。 .preseedファイルを再度変更しました。今回は/varとしてマウントする必要がある3番目のパーティションを追加し、イメージを再構築し、サーバーのBMCインターフェイスで[アンマウント]と[マウント]をクリックし、再起動して実行しました。インストール、そして何を推測すると、それは以前と同じレイアウトで、追加のパーティションはありませんでした。疑わしくなった/target/etc/issueを確認しました：
Ubuntu 16.04.1 LTS
それは16.04.5でした。インストールテスト中に、Ubuntu .isoを以前の16.04.1ではなく16.04.5に基づいて完全に再作成しました（.isoファイルにはバージョン番号が含まれているため、異なるISO名になります）。
これらのSuperMicroボードにISOイメージをマウントする方法は2つあります。単一のBMCに接続してISOをそこにマウントすることも、SuperMicro Server Managerを使用して複数のマシンにISOを一度にマウントすることもできます。インストールするマシンの数が多かったので、当然SSM方式を使用し、ISOをどこにでもマウントしました。
16.04.5に変更した後、作業しているホストのBMCでファイル名を直接変更しただけで、再マウントしました。私は確認としてThere is an iso file mounted.のみを受け取ります。詳細はありません。
マウントイメージページのSaveボタンをクリックすると、次のエラーメッセージが表示されます。
この方法ではパスを入力しませんでした。これはサーバーマネージャーによって設定されたので、正しいと思いました。どうやらそうではありません。この後、サーバーマネージャーを使用して.isoファイルをBMCに直接再マウントし、...
これをテストするために私が構成したとおりのもの。
話の教訓：安いBMCインターフェースの愚かさのために、私の時間の1週間（そしてあなたの役に立つ人々の貴重な時間の一部）を無駄にした。それを念頭に置き、説明できない問題が発生した場合は、すべてを再確認してください。
特記事項
Bios_grub、ESP、GPT、またはMBRがあるかどうか、またはファームウェアが使用する方法については言及されていません。 GPTを使用する場合は、どちらか一方（または両方）が必要です。したがって、何が起こるかは、おそらくディスクサイズに関連するいくつかの未知の基準に基づいて、インストーラが選択することです。 GPTを強制的に使用するには、次のように設定します（ここで見つけた6つの方法をすべて使用しても、常に機能するとは限らないことを覚えています）。
d-i partman-basicfilesystems/choose_label string gpt
d-i partman-basicfilesystems/default_label string gpt
d-i partman-partitioning/choose_label string gpt
d-i partman-partitioning/default_label string gpt
d-i partman/choose_label string gpt
d-i partman/default_label string gpt
たとえば、bios_grubの場合、次のように設定します。
1 1 1 free \
$primary{} \
$bios_boot{} \
method{ biosgrub } \
. \
（私は$iflabel{ gpt }をそこに配置しませんでした。何かがうまくいかず、後でそれをMBRからGPTに変換する場合、予約されたスペースが必要になるため、これは役に立ちます）
EFIの場合（ Preseeding debian install-EFI から恥知らずにコピーして貼り付け、iflabelを削除しませんでした）：
538 538 1075 free
$iflabel{ gpt }
$reusemethod{ }
method{ efi }
format{ } .
そして質問に答える
残りを使用するには、任意の非常に大きな数値ではなく-1を使用し、他の数値を1のような偽の値に設定します。そして、範囲も信頼しません...異なる異なるハードウェア用のpreseedファイルであり、debianのautomagicのものではありません。したがって、範囲ではなく、65536のみに設定しました。
d-i partman-auto/expert_recipe string \
boot-root :: \
1 1 -1 ext4 \
$primary{ } $bootable{ } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ / } \
. \
65536 65536 65536 linux-swap \
$primary{ } \
method{ swap } format { } \
.
そして、新しいプレシードファイルを使用していることを確認してください本当に。私はそれをネットワークなどに依存しないので、ネットブートのinitrdイメージに入れて、それがうまく機能することを発見しました。上記のようなものを変更しても動作しない場合は、何度も確認してください。 http/tftpの場合は、http/tftpログまたはtcpdumpを確認してください。または、きっと気づく変更を加えて、それが行われたかどうかを確認します。
Initrdの場合は、initrdを調べて、本当にそこにあるかどうかを確認します。例えば：
cd emptydir
gunzip -c path_to_initrd | cpio -i
# It must be named "preseed.cfg" if it's in the initrd.
cat preseed.cfg