お知らせ

  • 利用規約を守って投稿してください。また、よくある質問および投稿の手引きも参照してください。
  • メッセージの投稿にはアカウントが必要です。未登録の方は、ユーザ登録ページからアカウントを作成することができます。

#1 2021-08-25 13:26:13

takahashi86
メンバ
登録日: 2015-05-22

空き容量がなくアップデートできない

ubuntu18.045
アップデートコマンドで「…空き容量がありません」とエラーがでます。
ディスク容量を確認するとシステムをインストールssdの使用済み領域が100%になっていました。
こちらのサイトに掲載していた「linux-image」の古いバージョンをremoveして apt clean しても100%のままで、
いったい何が原因で使用領域が100%になったか判断できませんでした。
先達の皆様、どうかご教示いただけますようお願いいたします。
ご不明点がありましたらご指摘お願いします。

(システム)
cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic


(現象)
$ sudo apt update

取得:1 http://archive.ubuntulinux.jp/ubuntu bionic InRelease [15.4 kB]
エラー:1 http://archive.ubuntulinux.jp/ubuntu bionic InRelease                                   
  出力ファイルへの書き込みでエラーが発生しました - write (28: デバイスに空き領域がありません) [IP: 118.21.169.235 80]




W: http://archive.ubuntulinux.jp/ubuntu-ja-non-free/dists/bionic/InRelease の取得に失敗しました  出力ファイルへの書き込みでエラーが発生しました - write (28: デバイスに空き領域がありません) [IP: 118.21.169.235 80]
W: いくつかのインデックスファイルのダウンロードに失敗しました。これらは無視されるか、古いものが代わりに使われます。

(確認)
sudo  df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           382M  7.7M  374M   3% /run
/dev/nvme0n1p2  469G  459G     0 100% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/loop1       65M   65M     0 100% /snap/gtk-common-themes/1514
/dev/loop2      640K  640K     0 100% /snap/gnome-logs/103
/dev/loop0      163M  163M     0 100% /snap/gnome-3-28-1804/145
/dev/loop3       66M   66M     0 100% /snap/gtk-common-themes/1515
/dev/loop4      2.5M  2.5M     0 100% /snap/gnome-calculator/826
/dev/loop5      2.5M  2.5M     0 100% /snap/gnome-calculator/884
/dev/loop6      219M  219M     0 100% /snap/gnome-3-34-1804/66
/dev/nvme0n1p1  197M   23M  175M  12% /boot/efi
/dev/sdb2       2.7T  712G  1.9T  28% /mnt/mini_bu
minipool        7.1T  737G  6.3T  11% /minipool
/dev/loop8      2.5M  2.5M     0 100% /snap/gnome-system-monitor/163
/dev/loop9       56M   56M     0 100% /snap/core18/2128
/dev/loop10     2.5M  2.5M     0 100% /snap/gnome-system-monitor/160
/dev/loop11     100M  100M     0 100% /snap/core/11420
/dev/loop12      56M   56M     0 100% /snap/core18/2074
/dev/loop13     244M  244M     0 100% /snap/gnome-3-38-2004/39
/dev/loop14     640K  640K     0 100% /snap/gnome-logs/106
/dev/loop15      62M   62M     0 100% /snap/core20/1081
/dev/loop16     242M  242M     0 100% /snap/gnome-3-38-2004/70
/dev/loop17     219M  219M     0 100% /snap/gnome-3-34-1804/72
/dev/loop18     165M  165M     0 100% /snap/gnome-3-28-1804/161
/dev/loop19      62M   62M     0 100% /snap/core20/1026
tmpfs           382M  4.0K  382M   1% /run/user/121
/dev/loop20     100M  100M     0 100% /snap/core/11606
tmpfs           382M     0  382M   0% /run/user/1001

sudo df -i
Filesystem          Inodes  IUsed       IFree IUse% Mounted on
udev                478540    685      477855    1% /dev
tmpfs               487958   1167      486791    1% /run
/dev/nvme0n1p2    31244288 381166    30863122    2% /
tmpfs               487958      1      487957    1% /dev/shm
tmpfs               487958      5      487953    1% /run/lock
tmpfs               487958     18      487940    1% /sys/fs/cgroup
/dev/loop1           63978  63978           0  100% /snap/gtk-common-themes/1514
/dev/loop2             401    401           0  100% /snap/gnome-logs/103
/dev/loop0           27807  27807           0  100% /snap/gnome-3-28-1804/145
/dev/loop3           64986  64986           0  100% /snap/gtk-common-themes/1515
/dev/loop4            1384   1384           0  100% /snap/gnome-calculator/826
/dev/loop5            1388   1388           0  100% /snap/gnome-calculator/884
/dev/loop6           18508  18508           0  100% /snap/gnome-3-34-1804/66
/dev/nvme0n1p1           0      0           0     - /boot/efi
/dev/sdb2        183123968 267920   182856048    1% /mnt/mini_bu
minipool       13521085567 673298 13520412269    1% /minipool
/dev/loop8             907    907           0  100% /snap/gnome-system-monitor/163
/dev/loop9           10803  10803           0  100% /snap/core18/2128
/dev/loop10            907    907           0  100% /snap/gnome-system-monitor/160
/dev/loop11          12850  12850           0  100% /snap/core/11420
/dev/loop12          10803  10803           0  100% /snap/core18/2074
/dev/loop13          17970  17970           0  100% /snap/gnome-3-38-2004/39
/dev/loop14            401    401           0  100% /snap/gnome-logs/106
/dev/loop15          11720  11720           0  100% /snap/core20/1081
/dev/loop16          17461  17461           0  100% /snap/gnome-3-38-2004/70
/dev/loop17          18500  18500           0  100% /snap/gnome-3-34-1804/72
/dev/loop18          27806  27806           0  100% /snap/gnome-3-28-1804/161
/dev/loop19          11708  11708           0  100% /snap/core20/1026
tmpfs               487958     20      487938    1% /run/user/121
/dev/loop20          12850  12850           0  100% /snap/core/11606
tmpfs               487958     12      487946    1% /run/user/1001


dpkg --get-selections | grep linux-image
linux-image-5.0.0-23-generic            deinstall
linux-image-5.3.0-59-generic            deinstall
linux-image-5.3.0-61-generic            deinstall
linux-image-5.3.0-62-generic            deinstall
linux-image-5.4.0-42-generic            deinstall
linux-image-5.4.0-45-generic            deinstall
linux-image-5.4.0-47-generic            deinstall
linux-image-5.4.0-48-generic            deinstall
linux-image-5.4.0-51-generic            deinstall
linux-image-5.4.0-52-generic            deinstall
linux-image-5.4.0-53-generic            deinstall
linux-image-5.4.0-56-generic            deinstall
linux-image-5.4.0-58-generic            deinstall
linux-image-5.4.0-59-generic            deinstall
linux-image-5.4.0-60-generic            deinstall
linux-image-5.4.0-62-generic            deinstall
linux-image-5.4.0-65-generic            deinstall
linux-image-5.4.0-66-generic            deinstall
linux-image-5.4.0-67-generic            deinstall
linux-image-5.4.0-70-generic            deinstall
linux-image-5.4.0-71-generic            deinstall
linux-image-5.4.0-72-generic            deinstall
linux-image-5.4.0-73-generic            deinstall
linux-image-5.4.0-74-generic            deinstall
linux-image-5.4.0-77-generic            install
linux-image-generic-hwe-18.04            install


(/)
ls -l
合計 2097293
drwxr-xr-x   2 root root       4096  6月 26 18:28 bin
drwxr-xr-x   4 root root       4096  8月 25 11:39 boot
drwxr-xr-x   2 root root       4096  6月 16  2020 cdrom
drwxr-xr-x  20 root root       5040  8月 25 13:16 dev
drwxr-xr-x 135 root root      12288  8月 25 10:37 etc
drwxr-xr-x   6 root root       4096  6月 16  2020 home
lrwxrwxrwx   1 root root         32  6月 26 18:24 initrd.img -> boot/initrd.img-5.4.0-77-generic
lrwxrwxrwx   1 root root         32  8月 25 11:39 initrd.img.old -> boot/initrd.img-5.4.0-77-generic
-rw-r--r--   1 root root        344  6月 16  2020 kkk.log
drwxr-xr-x  22 root root       4096  6月 26 18:21 lib
drwxr-xr-x   2 root root       4096  6月 26 18:20 lib64
drwx------   2 root root      16384  6月 16  2020 lost+found
drwxr-xr-x   2 root root       4096  8月  7  2019 media
drwxrwxrwx   5 root root          6  6月 23 23:50 minipool
drwxr-xr-x   3 root root       4096  8月 25 13:11 mnt
drwxr-xr-x   2 root root       4096  8月  7  2019 opt
dr-xr-xr-x 331 root root          0  8月 25 00:44 proc
drwx------   9 root root       4096  8月 20 15:25 root
drwxr-xr-x  30 root root        920  8月 25 11:23 run
drwxr-xr-x   2 root root      12288  6月 26 18:28 sbin
drwxr-xr-x  13 root root       4096  7月  2 08:00 snap
drwxr-xr-x   2 root root       4096  8月  7  2019 srv
-rw-------   1 root root 2147483648  6月 16  2020 swapfile
dr-xr-xr-x  13 root root          0  8月 25 00:44 sys
drwxrwxrwt  12 root root       4096  8月 25 11:39 tmp
drwxr-xr-x  11 root root       4096  8月  7  2019 usr
drwxr-xr-x  14 root root       4096  8月  7  2019 var
lrwxrwxrwx   1 root root         29  6月 26 18:24 vmlinuz -> boot/vmlinuz-5.4.0-77-generic
lrwxrwxrwx   1 root root         29  8月 25 11:39 vmlinuz.old -> boot/vmlinuz-5.4.0-77-generic

となっています。

削除が可能なファイルの探し方としては、大きい容量のフォルダ内を一つずつ確認しています。
/var/log内も圧縮ファイル等はすべて削除しました。

RAMが4GBで運用しています。
swapfileが2,147,483,648あります。これが影響している様に類推しています。

以上の内容ですがよろしくお願いいたします。

オフライン

 

#2 2021-08-25 13:37:36

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

swapfileの単位が違っておりました訂正させていただきます。

$ du -sm swapfile
2049    swapfile

オフライン

 

#3 2021-08-25 18:58:09

redred
メンバ
登録日: 2020-05-27

Re: 空き容量がなくアップデートできない

圧迫の原因はわかりませんが、
ある程度、削除された後は
ssdのtrimはやってみましたか?

オンライン

 

#4 2021-08-25 22:50:23

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

お世話になります

>>削除された後はssdのtrimはやってみましたか?
ありがとうございます。
# lsblk --discard



nvme0n1            0      512B       2T         0
├─nvme0n1p1        0      512B       2T         0
└─nvme0n1p2        0      512B       2T         0
root@mm:/home/takahashi1# systemctl status fstrim
● fstrim.service - Discard unused blocks
   Loaded: loaded (/lib/systemd/system/fstrim.service; static; vendor pre
   Active: inactive (dead)


# fstrim -v /
/: 9 GiB (9697714176 バイト) に切り揃えました

# systemctl enable fstrim.timer
# systemctl list-timers --all

NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES



Mon 2021-08-30 00:00:00 JST  4 days left   Mon 2021-08-23 00:00:00 JST  2 days ago   fstrim.timer                 fstrim.service

スケジュールを有効にしました。

削除したあとも df -l で使用率みると100%のままでした。
あまりたくさん削除できていないからかも知れません。


取り急ぎ御礼と報告をいたします!

オフライン

 

#5 2021-08-25 23:52:04

si
メンバ
From: hokkaido kitami, jp
登録日: 2007-01-15

Re: 空き容量がなくアップデートできない

先ず、どの辺りが容量を食っているのかを調べないと、話が進まない様に思います。
それには、du コマンドでディレクトリ毎に調べるのが手っ取り早いのではないかと思います。
例(-s はディレクトリの総使用量のみ表示 -m はメガバイト表示オプション)
sudo du -s -m /var
6387    /var

sudo du -s -m /home
142487    /home

sudo du -s -m /usr
8335    /usr

* サーバの使用法やアクセス頻度等を明記すれば、溢れるディレクトリを推測できるかもしれません
* エラーや不正アクセスが多い場合は、ログが肥大化しますので、ログのチェックも必要かもしれません

オフライン

 

#6 2021-08-26 00:11:37

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

7GBを使用している /snap がありますが、snapでのアプリ管理は使用していません。
その場合

Sudo apt autoremove snapd
または
Sudo apt autoremove --purge snapd

でsnapを削除しても問題ないでしょうか?

ご教示いただけましたら助かります。

オフライン

 

#7 2021-08-26 05:44:06

elliptic
メンバ
登録日: 2020-03-05

Re: 空き容量がなくアップデートできない

#6

takahashi86 による投稿:

7GBを使用している /snap がありますが、snapでのアプリ管理は使用していません。
その場合

Sudo apt autoremove snapd
または
Sudo apt autoremove --purge snapd

でsnapを削除しても問題ないでしょうか?

autoremoveは引数を取りません。
Ubuntu 18.04 LTS では 4つの標準ツール
「電卓」    gnome-calculator
「文字」    gnome-characters
「ログ」    gnome-logs
「システムモニター」  gnome-system-monitor
がsnapアプリケーションです。
snapdを削除するとこれらが使えなくなります。

#1

takahashi86 による投稿:

削除が可能なファイルの探し方としては、大きい容量のフォルダ内を一つずつ確認しています。

まずフォルダを使用量順に並べてみましょう

コード:

sudo du -d3  / 2>/dev/null |sort -nrk1 |head -20

上位20個をリストアップします。
ディスク全体を走査するので結果が返るまでしばらくかかります。

オフライン

 

#8 2021-08-27 01:43:38

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

>>先ず、どの辺りが容量を食っているのかを調べないと、話が進まない様に思います。
>>それには、du コマンドでディレクトリ毎に調べるのが手っ取り早いのではないかと思います。
例(-s はディレクトリの総使用量のみ表示 -m はメガバイト表示オプション)
sudo du -s -m /var
6387    /var

教えていただきありがとうございます。現状のご説明が悪く申し訳ありません。
私のメッセージにある通り、すべてのフォルダに対しご指摘の様な方法で du -sm または du -sh 既にサイズを確認しまして、可能と思われるフォルダ ログ等、削除済みです。
それでも使用率が100%になっている状況となっており大変困っております。

どうぞ引き続きよろしくお願いいたします。
取り急ぎ御礼まで

オフライン

 

#9 2021-08-27 01:57:47

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

>>autoremoveは引数を取りません。

失礼しました。purge --remove と間違いました。
ご指摘ありがとうございます。

>>Ubuntu 18.04 LTS では 4つの標準ツール
>>「電卓」    gnome-calculator
>>「文字」    gnome-characters
>>「ログ」    gnome-logs
>>「システムモニター」  gnome-system-monitor
>>がsnapアプリケーションです。
>> snapdを削除するとこれらが使えなくなります。

はい。そういうことですね。
snapというのにあまり馴染みがなく使用感がありませんでした。
/snap下では現在使用しているアプリがあるのですね。
ご教示ありがとうございました。
使用していないと誤解しておりました。


#1

    takahashi86 による投稿:

    削除が可能なファイルの探し方としては、大きい容量のフォルダ内を一つずつ確認しています。

>> まずフォルダを使用量順に並べてみましょう

はい。

コード:

>> sudo du -d3  / 2>/dev/null |sort -nrk1 |head -20

>>上位20個をリストアップします。
>>ディスク全体を走査するので結果が返るまでしばらくかかります。


はい。

$ sudo du -d3  / 2>/dev/null |sort -nrk1 |head -20
1530904424    /
764216438    /mmpool   #外部RAIDZ2
763952086    /mmpool/nd   #------- 外部RAIDZ2
748247396    /mnt  #マウントしているのはthunderbolt2 Drive
748247392    /mnt/mm_bu #------- 外部ext4
748247372    /mnt/mm_bu/nd1 #------- 外部ext4
280393415    /mmpool/nd/2020-1 #------- 外部RAIDZ2
274117149    /mmpool/nd/2021 #------- 外部RAIDZ2
180105306    /mmpool/nd/2020-2 #------- 外部RAIDZ2
29336087    /mmpool/nd/Ap  #------- 外部RAIDZ2
7203667    /snap
4692100    /var
3356904    /usr
2695240    /var/lib
2499976    /var/lib/snapd
2103259    /snap/gnome-3-38-2004
1951212    /var/log
1941652    /var/log/journal
1754933    /snap/gnome-3-34-1804
1710688    /usr/lib

となっております。
snapが一番大きいですが、/を圧迫しているデータはありません。
500GBのNVMe SSDで十分足りると認識していますが、見落とし等ございましたら
ご指摘の程、お願い申し上げます。


ご教示いただきありがとうございます。

オフライン

 

#10 2021-08-27 07:06:40

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

ellipticさま
purge --remove と入力しましたが、
「apt remove --purge と勘違いをしてしまいました。」間違いでした。
確認せず申し訳ありません。
お詫びして訂正いたします。

引き続きご教示の程、お願い申し上げます。

オフライン

 

#11 2021-08-27 13:25:41

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

elliptic様

昨日はご丁寧に教えていただきありがとうございます。

こちらはSMBファイルサーバとして使用しています。
いろいろ考えてみました。
昨日確認した内容では、現場でスイッチハブ電源が切れて、再起動をしたとの事でした。
7時に遠隔サーバと同期を取る予定になっていました。

この様な経験は複数台のubuntuサーバでも今まで一度もなく、原因が特定できませんでした。
その為、ubuntuサーバ先達の皆様にご教示をいただきました。

もしかするとシステム自体強制再起動による損傷などがあるようにも考えられます。
その為、今度現場に行った際、再起動時grub オプションにて fsckを実行して確認したいと思います。

また、その際隠しファイルなどで蓄積していればそのファイルも表示させてサイズ確認したいと思います。

duコマンドで探した場合、'.'から始まる隠しファイルの表示方法が分かりませんので、rsync コマンドで探す事にしました。
あまりシェルうまく組めませんが、

rsync -arm -n --include="*/" --include=".*" --exclude="*" usr@192.168.xxx.xxx: /対象ディレクトリ | sort -nrk2 | head -10  > /Users/name/Desktop/test.txt

の様に組んで探してみたいと思います。

またご指摘、アドバイスの程お願い申し上げます。

この様な状況はあまり発生しないと思いますが、結果など(進展があれば)を報告させていただきます。

オフライン

 

#12 2021-08-27 13:41:59

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

rsync コマンドはリモートでやった場合間違って記述されております。確認しましたら再掲いたします。
申し訳ありません。

オフライン

 

#13 2021-08-27 14:05:12

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

報告です。


$ sudo tune2fs -l /dev/sda
tune2fs 1.44.1 (24-Mar-2018)
tune2fs: Bad magic number in super-block while trying to open /dev/sda
Found a gpt partition table in /dev/sda

とでました。
やはりFSCKコマンドを試したいと思います。

オフライン

 

#14 2021-08-28 12:23:12

elliptic
メンバ
登録日: 2020-03-05

Re: 空き容量がなくアップデートできない

#9の duの結果から推定すると
(/dev/nvme0n1p2の使用量)
= (/) - (/mmpool) - (/mnt)
= 1530904424 - 764216438 - 748247396
= 18440590
約 17.6GiB使っています。

#1の 459G Used という 表示とは違いすぎるので
何かのファイルがディスクを消費しているのではなく。
ファイルシステムの管理データが壊れて誤報を出している可能性が高いです。

マウントした追加ディスクを除外するように

コード:

sudo du -x /  |sort -nrk1 |head -20

にしておけば見やすくなってよかったのにと #9を見てから気づきました。

#13

takahashi86 による投稿:

$ sudo tune2fs -l /dev/sda

/dev/sdaはここまでの話にでてきてませんが 当該マシンにもとからついている
HDDでWindowsが入っているとかでしょうか?
* /dev/sda はそのままディスク全体をファイルシステムに使うケースは少なく
普通は /dev/sda1, /dev/sda2, ... とパーティションで区切って部分領域に
ファイルシステムを作ります。
* tune2fsは ext2, ext3, ext4 ファイルシステム用で ntfsやfat32 には使えません。
* どのディスクがどんなパーティション分けでにどんなファイルシステムを
  使っているかは
    lsblk -f
  を見るとわかりやすいです。
* いま調べるべきは
> /dev/nvme0n1p2  469G  459G     0 100% /
  です。

これまで/dev/nvme0n1p2 のファイルシステムが何であるか出てきてませんが
普通にext4を使用しているで合ってますか?

tune2fs -l でスーパーブロック情報の取得。
e2fsckで修復を試みる。
smartctl 等で SSD に警告がでてないか調べる。
などをすることになると思います。

#11

takahashi86 による投稿:

rsync -arm -n --include="*/" --include=".*" --exclude="*" usr@192.168.xxx.xxx: /対象ディレクトリ | sort -nrk2 | head -10  > /Users/name/Desktop/test.txt

上に書いたように 犯人となるファイルは探しても出てきそうにないと思います。
隠しファイルになるドットファイルだけをリストするには

コード:

rsync -rx [USER@]HOST:SRC |awk '$5~/(^|\/)\.[^\/]+$/ {print}' |sort -nrk2

ではどうでしょうか。

オフライン

 

#15 2021-08-29 11:00:36

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

ellipticさま

日頃より大変お忙しい中、本当にすばらしいサポートをありがとうございます。
感謝の気持ちでいっぱいです。

またご返事遅くなりまして申し訳ありません。

27日夕方にリモートサーバの代替えを作って持っていきまして、問題のサーバをローカルに持ってきました。

損傷は、リモートではわからなかったのですが、とても著しく画面も映らない? よく見えない文字の羅列が黒い背景にありました。
一旦クローンを作成してから、fsckしてスーパーブロック(SB)などをSBバックアップから修復したところ、今まで見えなかったティレクトリが見えました。 (修復は -y を引数に設定せず、一回ごとにやっていたので 'yes'は相当入力しました。設定ミスです。)

/mntの中に本来外付けDiskがあった場所に(外付けディスクは外しています)外付けDiskのファイルが入っていました。

すぐさま削除しましたが、起動部分(boot efi)も壊れていてうまく起動しませんでした。
これの修復をboot-repair等使いましたがうまくできませんでした。

結局 rsyncでバックアップをとって、再インストールしました。
今度はtimeshiftの他、サブディスクにddで完成したシステムimageファイルを保管しました。

実際にelliptic様からご教示たまわりました内容はまだテストしておりません。
クローンが残っていますので、すこし時間があるときに修得させていただきたく存じます。


user 移行は少なかったので比較的短時間で済みましたが、私にとってノウハウがありませんでした。
サイトを参考にしながらでしたがどうしても変更できなす id番号とかがあり、課題は残りました。

昨日1日復旧等で時間がかかってしまい、またあらためて御礼・報告をさせていただきます。

サポートありがとうございます。
取り急ぎ、簡単な報告と御礼まで

オフライン

 

#16 2021-08-29 11:03:48

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

elliptic様

失念しておりました。
申し訳ありません。

NTFSなどwindowsは使っておりませんでした。

tune2fs -l でスーパーブロック情報の取得。
e2fsckで修復を試みる。

はい。おっしゃる通り上記のコマンドで修復しました。

ありがとうございました。

オフライン

 

#17 2021-08-29 16:10:40

takahashi86
メンバ
登録日: 2015-05-22

Re: 空き容量がなくアップデートできない

elliptic様

お世話になります。
おおよその原因が理解できました。

サーバのrsync作業が稼働している時に、スイッチングハブの電源がシャットダウンし、ユーザーがサーバーの反応がないため再起動処理を行った。
しかしシステムはwsync処理中でしたのでシステムを終了しなかった。
ユーザーはフリーズを疑って電源ボタン長押しをして強制終了した。

再起動処理のタイミングでマウント中のハードディスクがアンマウントになった。
アンマウントになったディスクもスーパーブロックエラーになっていた。

アンマウントしているにも関わらず、システムは過去にマウントしていたディレクトリを対象にcron指示によりrsync で同期を取った。
できる限るの内容がコピーされ容量が不足して停止。

という顛末が整合がとれます。

fsckは以下の通りに実行しました。

//
# mkfs.ext4 -n /dev/sdb
mke2fs 1.44.1 (24-Mar-2018)
Found a gpt partition table in /dev/sdb
Proceed anyway? (y,N) y
Creating filesystem with 732566646 4k blocks and 183148544 inodes
Filesystem UUID: 36460d78-3f94-4005-a48d-8ad823db6891
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000, 550731776, 644972544


# mke2fs -S /dev/sdb
mke2fs 1.44.1 (24-Mar-2018)
Found a gpt partition table in /dev/sdb
Proceed anyway? (y,N) y
Creating filesystem with 732566646 4k blocks and 183148544 inodes
Filesystem UUID: f4d3e6bd-58fb-486d-ac1c-1ca3875717c0
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done                           
Found a gpt partition table in /dev/sdb
/dev/sdb may be further corrupted by superblock rewrite
Proceed anyway? (y,N) y
Writing superblocks and filesystem accounting information: done     

という結果になりましたが、結局本日リモートで電源断に強いと言われるZFSでフォーマットしなおして、
zfs send | recv コマンドにてレプリケーションする仕様に変更しました。

今回はお陰様で以上の様に解決いたしました。
ご丁寧なサポートに心から感謝いたします。

ありがとうございました。

オフライン

 

Board footer

Powered by FluxBB