Open marcin-jozwikowski opened 1 year ago
This error would occur when validating the checksum of the extracted files doesn't match the expected checksum 🤔. No direct clues, other than actual disk issues.
/var/lib/docker
, e.g., could it be a separate mount for storage or something along those lines?No. /var/lib
is part of /
which takes the whole /dev/nvme0n1p5
formatted to Ext4 (version 1.0)
.
mjozwikowski:~$ df -ha
df: /run/user/1000/doc: Operation not permitted
Filesystem Size Used Avail Use% Mounted on
sysfs 0 0 0 - /sys
proc 0 0 0 - /proc
udev 22G 0 22G 0% /dev
devpts 0 0 0 - /dev/pts
tmpfs 4,3G 3,0M 4,3G 1% /run
/dev/nvme0n1p5 359G 144G 197G 43% /
securityfs 0 0 0 - /sys/kernel/security
tmpfs 22G 51M 22G 1% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
cgroup2 0 0 0 - /sys/fs/cgroup
pstore 0 0 0 - /sys/fs/pstore
efivarfs 0 0 0 - /sys/firmware/efi/efivars
bpf 0 0 0 - /sys/fs/bpf
systemd-1 - - - - /proc/sys/fs/binfmt_misc
mqueue 0 0 0 - /dev/mqueue
hugetlbfs 0 0 0 - /dev/hugepages
debugfs 0 0 0 - /sys/kernel/debug
tracefs 0 0 0 - /sys/kernel/tracing
fusectl 0 0 0 - /sys/fs/fuse/connections
configfs 0 0 0 - /sys/kernel/config
ramfs 0 0 0 - /run/credentials/systemd-sysusers.service
/dev/loop0 128K 128K 0 100% /snap/bare/5
/dev/loop1 119M 119M 0 100% /snap/core/15419
/dev/loop2 119M 119M 0 100% /snap/core/15511
/dev/loop3 56M 56M 0 100% /snap/core18/2751
/dev/loop4 56M 56M 0 100% /snap/core18/2785
/dev/loop5 64M 64M 0 100% /snap/core20/1950
/dev/loop7 74M 74M 0 100% /snap/core22/817
/dev/loop6 64M 64M 0 100% /snap/core20/1974
/dev/loop8 74M 74M 0 100% /snap/core22/858
/dev/loop10 238M 238M 0 100% /snap/firefox/2971
/dev/loop11 219M 219M 0 100% /snap/gnome-3-34-1804/90
/dev/loop12 219M 219M 0 100% /snap/gnome-3-34-1804/93
/dev/loop13 350M 350M 0 100% /snap/gnome-3-38-2004/140
/dev/loop14 350M 350M 0 100% /snap/gnome-3-38-2004/143
/dev/loop15 467M 467M 0 100% /snap/gnome-42-2204/111
/dev/loop16 486M 486M 0 100% /snap/gnome-42-2204/120
/dev/loop17 82M 82M 0 100% /snap/gtk-common-themes/1534
/dev/loop18 92M 92M 0 100% /snap/gtk-common-themes/1535
/dev/loop19 9,8M 9,8M 0 100% /snap/htop/3735
/dev/loop20 9,8M 9,8M 0 100% /snap/htop/3758
/dev/loop21 38M 38M 0 100% /snap/hunspell-dictionaries-1-7-2004/2
/dev/loop22 437M 437M 0 100% /snap/kde-frameworks-5-96-qt-5-15-5-core20/7
/dev/loop23 261M 261M 0 100% /snap/kde-frameworks-5-core18/32
/dev/loop24 290M 290M 0 100% /snap/kde-frameworks-5-core18/35
/dev/loop25 449M 449M 0 100% /snap/kf5-5-104-qt-5-15-8-core22/7
/dev/loop26 449M 449M 0 100% /snap/kf5-5-104-qt-5-15-8-core22/9
/dev/loop27 253M 253M 0 100% /snap/krita/85
/dev/loop28 253M 253M 0 100% /snap/krita/90
/dev/loop29 113M 113M 0 100% /snap/slack/82
/dev/loop30 114M 114M 0 100% /snap/slack/83
/dev/loop31 46M 46M 0 100% /snap/snap-store/638
/dev/loop32 13M 13M 0 100% /snap/snap-store/959
/dev/loop33 54M 54M 0 100% /snap/snapd/19361
/dev/loop34 54M 54M 0 100% /snap/snapd/19457
/dev/loop35 512K 512K 0 100% /snap/snapd-desktop-integration/57
/dev/loop36 512K 512K 0 100% /snap/snapd-desktop-integration/83
/dev/loop37 66M 66M 0 100% /snap/sublime-text/118
/dev/loop38 64M 64M 0 100% /snap/sublime-text/122
/dev/nvme0n1p5 359G 144G 197G 43% /var/snap/firefox/common/host-hunspell
/dev/loop39 254M 254M 0 100% /snap/subsync/11
/dev/nvme0n1p1 256M 72M 185M 29% /boot/efi
tmpfs 22G 0 22G 0% /run/qemu
binfmt_misc 0 0 0 - /proc/sys/fs/binfmt_misc
sunrpc 0 0 0 - /run/rpc_pipefs
tmpfs 4,3G 3,0M 4,3G 1% /run/snapd/ns
nsfs 0 0 0 - /run/snapd/ns/snapd-desktop-integration.mnt
tmpfs 4,3G 136K 4,3G 1% /run/user/1000
/home/mjozwikowski/.Private 359G 144G 197G 43% /home/mjozwikowski
nsfs 0 0 0 - /run/snapd/ns/snap-store.mnt
/dev/loop41 238M 238M 0 100% /snap/firefox/2987
nsfs 0 0 0 - /run/snapd/ns/firefox.mnt
And the whole drive seems to be in good condition:
mjozwikowski:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning : 0
temperature : 24 C (297 Kelvin)
available_spare : 100%
available_spare_threshold : 10%
percentage_used : 3%
endurance group critical warning summary: 0
data_units_read : 18 308 944
data_units_written : 25 745 218
host_read_commands : 264 878 067
host_write_commands : 429 459 124
controller_busy_time : 4 131
power_cycles : 1 547
power_on_hours : 3 531
unsafe_shutdowns : 27
media_errors : 0
num_err_log_entries : 0
Warning Temperature Time : 0
Critical Composite Temperature Time : 0
Thermal Management T1 Trans Count : 0
Thermal Management T2 Trans Count : 0
Thermal Management T1 Total Time : 0
Thermal Management T2 Total Time : 0
No, I don't have any antivirus/antimalware software installed. Unless something is one and I'm not aware... At least I didn't until today. Installed clamav, and did a full scan - nothing found.
Would there be a way to enable some more detailed logs? I'd gladly send you all the details I could get but I don't know what exactly to do.
I meet same issue, if you have enough disk space check your internet connection, I am using a ASUS TUF labtop after I switch from WIFI to wired connect I solve the problem.
can relate that changing from wired to wireless solved my issue
In my case it was the other way around. Wired connection seemed more reliable back then. I ended up doing a warranty repair for the laptop I was working on. They replaced the whole motherboard (which has almost everything on it) - only RAM and hard drive remained the same. After that everything worked perfectly - even without reinstalling the OS. It's hard for me to even guess what could have been the issue.
Description
I'm running docker on Ubuntu 22.04 (CLI Engine, not Docker-Desktop) and I keep getting layer verification error. I've tested this command multiple times. This issue occurs on different layers (although some tend to have more occurrences - seems that bigger layers have less chance of success) and once in a while everything works. But on other images (i.e.
mcr.microsoft.com/mssql/server:2019-CU18-ubuntu-20.04
) I wasn't able to successfully finish the pull.It's now a fresh installation. I've completely removed Docker along with its configs and reinstalled it all.
/var/lib/docker
has been removed, so were/etc/docker/daemon.json
and~/.docker/config.json
. I don't use proxy, the internet connection is stable, and this is not a VM - it's a native Ubuntu installation. I've tried docker-desktop and there everything is fine, so it's not a repository issue nor a connection one. Those pulls are not from any private repository, nor are those images built by me.The following two commands were run immediately one after another:
Reproduce
Expected behavior
docker pull
should complete without any issuesdocker version
docker info
Additional Info
Resulted in following entries in
journalctl