web-dev-qa-db-ja.com

ルートパーティションがgpartedでいっぱいと表示されるのはなぜですか?

私はファイルシステムについて少し知っていますが、あまりよく知りません。私はLVMが何であるかについての一般的な考えしか持っていませんが、明らかにそれが私のルートパーティションとして使用しているものです。

コンピューターに1TBのハードドライブが1台あります。 Ubuntu14.04を実行しています。

今日、いくつかのアップデートをインストールしに行きましたが、/bootパーティションによって十分なスペースがないことが通知されました。

ライブCDからgparted GUIを使用してスペースを解放しようとしましたが、ルートファイルシステムがいっぱいであると表示されていることに気付きました。

enter image description here

ただし、dfによると:

Filesystem                  1K-blocks     Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-root 954367812 10720604 895145040   2% /
none                                4        0         4   0% /sys/fs/cgroup
udev                          2995912       12   2995900   1% /dev
tmpfs                          608016     1312    606704   1% /run
none                             5120        0      5120   0% /run/lock
none                          3040072    17312   3022760   1% /run/shm
none                           102400       52    102348   1% /run/user
/dev/sda2                      241965   118221    111252  52% /boot
/dev/sda1                      523248     3428    519820   1% /boot/efi
tmpfs                         3040072        4   3040068   1% /var/lib/polkit-1/localauthority/90-mandatory.d

これはどうしたの? gpartedがパーティションがいっぱいだと思うのはなぜですか?


追加の質問もあります。 /boot/efiパーティションと/bootパーティションの違いと、両方が必要かどうかを知っている人はいますか?

1
Luke

それらの間で、AFHとロメオニノフは基本的に答えを持っていますが、それは一緒にバンドルされる必要があります。

/bootパーティションは、LVM(ファイルシステムではなく、ファイルシステムを含む論理ボリュームのコンテナー)を使用するために基本的に必要であるため、分離されています。 LVMパーティションはサイズ変更できます。必要なものの概要については、 ここ を参照してください。でも、そこに行くかどうかはわかりません。

更新プロセスで244MiB /bootパーティションのスペースが不足しているとの苦情がありましたが、そのパーティションは現在52%しか使用されていません。定期的に個別の/bootパーティションを作成するディストリビューションは、通常、パーティションのサイズを約2倍にしますが、更新によってそこで使用されるスペースの量がほぼ2倍になるのは奇妙なことです。これを入力しているUbuntu14.04インストールでは、/bootで80MiBしか使用しません。したがって、そこに何があるかを確認することをお勧めします。 ls -lh /bootと入力します。これが私のシステムで見たものです:

$ ls -lh /boot
total 70M
-rw-r--r--  1 root root 1.2M Feb 14 17:06 abi-3.13.0-45-generic
-rw-r--r--  1 root root 1.2M May  4 01:09 abi-3.13.0-52-generic
-rw-r--r--  1 root root 162K Feb 14 17:06 config-3.13.0-45-generic
-rw-r--r--  1 root root 162K May  4 01:09 config-3.13.0-52-generic
drwxr-xr-x 10 root root 4.0K Dec 31  1969 efi
drwxr-xr-x  3 root root 1.0K May  7 11:30 extlinux
drwxr-xr-x  5 root root 1.0K Mar 12 20:08 grub
drwxr-xr-x  2 root root 1.0K Feb 14 17:06 grub.bak
-rw-r--r--  1 root root  20M Feb 26 18:39 initrd.img-3.13.0-45-generic
-rw-r--r--  1 root root  20M May  7 11:28 initrd.img-3.13.0-52-generic
drwx------  2 root root  12K Feb 14 17:05 lost+found
-rw-r--r--  1 root root 173K Feb 14 17:06 memtest86+.bin
-rw-r--r--  1 root root 174K Feb 14 17:06 memtest86+.elf
-rw-r--r--  1 root root 175K Feb 14 17:06 memtest86+_multiboot.bin
-rw-r--r--  1 root root  227 Feb 14 17:06 refind_linux.conf
-rw-------  1 root root 3.3M Feb 14 17:06 System.map-3.13.0-45-generic
-rw-------  1 root root 3.3M May  4 01:09 System.map-3.13.0-52-generic
-rw-------  1 root root 5.6M Feb 14 17:06 vmlinuz-3.13.0-45-generic
-rw-r--r--  1 root root 5.6M Feb 19 21:38 vmlinuz-3.13.0-45-generic.efi.signed
-rw-------  1 root root 5.6M May  4 01:09 vmlinuz-3.13.0-52-generic
-rw-r--r--  1 root root 5.6M May 10 21:36 vmlinuz-3.13.0-52-generic.efi.signed

これはかなり一般的です(ただし、一部のシステムよりも少し多いです)。ここに示したものよりも多くの種類のファイルが表示される場合は、何かが新しくて無関係なものを追加した可能性があり、そのようなファイルは削除の候補になる可能性がありますが、理解できない場合は、事前にアドバイスを求めてくださいそれらを削除します。

チェックするもう1つのことは、無関係なカーネルです。これらは、vmlinuzで始まる名前のファイルです。 (これらは、AFHが検索したinitrd.imgファイルとペアになっています。)私自身の例では、4つのカーネルファイルを示していますが、これらは実際には2つのカーネルの署名付きバージョンと署名なしバージョンです。 3つ以上のカーネルバージョン(それぞれが署名付きおよび署名なしの形式で利用できる場合があります)が表示される場合は、次のコマンドを試してください。

Sudo apt-get autoremove

このコマンドは、元のカーネルと最新の2つのカーネルを除くすべてをシステムから削除し、スペースを空ける必要があります。

パーティションのサイズを変更する必要がある場合は、LVMセットアップを混乱させるよりも、EFIシステムパーティション(ESP;この場合は/dev/sda1)を縮小してそのスペースに/bootを展開する方が安全な場合があります。約200MiBを超えるサイズ変更はお勧めしません。その前に、リムーバブルメディアに両方のパーティション確実にバックアップする必要があります。続行するには、両方のパーティションが起動に不可欠であるため、問題が発生した場合は深刻な問題が発生します。また、一部のEFIは、ESP上のFATファイルシステムについて気難しい場合があることに注意してください。いくつか(ほとんどの場合、2012年以前の古いEFI)は、512MiBよりも小さいFAT32 ESPテストブートを実行します。ブートできる場合は、/bootを空き領域に展開し、再度ブートしてみます。ESPを縮小した後に問題が発生した場合は、緊急システムを使用して元のサイズに拡大します。

2
Rod Smith

gparteddfの結果は異なりますが、この程度ではありません。gpartedlvm2の内容を誤って解釈していると思われます。

問題は、/bootが別の0.25GBドライブにマウントされていることです。これが、スペースが不足している原因です。どうやってこの状態になったのか、どうやって抜け出すのかわかりません。おそらくgrublvm2ファイルシステムからうまく起動しません。

最初に行う最も簡単なことは、現在と以前のカーネルを除くすべてのカーネルを削除することです(複数のバックアップカーネルが必要になることはありません)。タイプ:

ls -l /boot/initrd*
uname -a

これにより、インストールされているすべてのカーネルリリースと実行中のカーネルが表示されます。次に、最後の2つを除くすべてを削除する必要があります。これにはsynapticを使用することをお勧めします。Installedを選択し、検索ボックスに、削除する各リリースの数値部分を順番に設定してから、Ctrl-aと入力して選択しますすべて、右クリックしてMark for Complete Removalを選択します(現在のリリースを削除しないように絶対に注意してください!)。削除する各カーネルを確認したら、Applyをクリックします。

2つのカーネルがインストールされているUbuntu15.04では、私の/bootディレクトリのサイズは120MBをわずかに超えているため、/dev/sda2に3つ目のリリースをインストールする間、2つのリリース用のスペースが必要です(最も古いリリースを削除することを忘れないでください)。これを行うたびに)。

これで問題が解決しない場合は、次の2つのオプションがあります。-

  1. /dev/sda2との境界を移動して、/dev/sda3のサイズを大きくします。
  2. インターネットでgrub lvm2を検索し、そこでのアドバイスに従ってください。

補助的な質問に答えるために、/bootはカーネルブートファイルが存在する場所であり、これは通常/と同じファイルシステム内にありますが、grubはEFIブートの場所を識別する必要がありますファイルが存在し、これは/boot/efiにEFIブートパーティションをマウントすることによって行われます。つまり、/boot/efiは別のファイルシステムのマウントポイントですが、/boot自体がマウントポイントになることは珍しいことです。従来のBIOSを使用して起動する場合を除いて、両方が必要です。

2
AFH

画面にはファイルシステムではなくPV(物理ボリューム)が表示されるためです。そして、pv全体がvgに割り当てられます。実行中

df

ファイルシステムのステータスが表示されます

1
Romeo Ninov