Ubuntu日本語フォーラム

takahashi86 · 2021-08-25 13:26:13

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あります。これが影響している様に類推しています。

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

takahashi86 · 2021-08-25 13:37:36

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

$ du -sm swapfile
2049 swapfile

redred · 2021-08-25 18:58:09

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

takahashi86 · 2021-08-25 22:50:23

お世話になります

>>削除された後は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%のままでした。
あまりたくさん削除できていないからかも知れません。

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

si · 2021-08-25 23:52:04

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

sudo du -s -m /home
142487 /home

sudo du -s -m /usr
8335 /usr

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

takahashi86 · 2021-08-26 00:11:37

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

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

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

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

elliptic · 2021-08-26 05:44:06

#6

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

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

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

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

#1

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

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

コード:

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

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

takahashi86 · 2021-08-27 01:43:38

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

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

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

拝

takahashi86 · 2021-08-27 01:57:47

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

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

>>Ubuntu 18.04 LTS では４つの標準ツール
>>「電卓」 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で十分足りると認識していますが、見落とし等ございましたら
ご指摘の程、お願い申し上げます。

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

takahashi86 · 2021-08-27 07:06:40

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

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

takahashi86 · 2021-08-27 13:25:41

elliptic様

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

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

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

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

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

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

rsync -arm -n --include="*/" --include=".*" --exclude="*" [email protected]: /対象ディレクトリ | sort -nrk2 | head -10 > /Users/name/Desktop/test.txt

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

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

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

拝

takahashi86 · 2021-08-27 13:41:59

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

takahashi86 · 2021-08-27 14:05:12

報告です。

$ 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コマンドを試したいと思います。

elliptic · 2021-08-28 12:23:12

#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="*" [email protected]: /対象ディレクトリ | sort -nrk2 | head -10 > /Users/name/Desktop/test.txt

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

コード:

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

ではどうでしょうか。

takahashi86 · 2021-08-29 11:00:36

ellipticさま

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

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

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

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

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

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

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

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

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

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

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

拝

takahashi86 · 2021-08-29 11:03:48

elliptic様

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

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

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

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

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

takahashi86 · 2021-08-29 16:10:40

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 コマンドにてレプリケーションする仕様に変更しました。

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

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

拝

Ubuntu日本語フォーラム

お知らせ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

takahashi86 による投稿:

takahashi86 による投稿:

コード:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コード:

takahashi86 による投稿:

takahashi86 による投稿:

コード:

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

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

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

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

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

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

Board footer