MichaIng
commented
1 year ago I sent a log a few hours ago...
Can you share the bug report ID or simply the error log/output shown on the screen?
Closed isarrider closed 1 year ago
MichaIng
commented
1 year ago I sent a log a few hours ago...
Can you share the bug report ID or simply the error log/output shown on the screen?
isarrider
commented
1 year ago "APT dist-upgrade │
│ - Command: apt-get -y dist-upgrade │
│ - Exit code: 100 │
│ - DietPi version: v8.13.2 (MichaIng/master) | HW_MODEL: 78 | HW_ARCH: 3 | DISTRO: 7 │
│ - Image creator: DietPi Core Team │
│ - Pre-image: from scratch │
│ - Error log: │
│ Reading package lists... │
│ Building dependency tree... │
│ Reading state information... │
│ Calculating upgrade... │
│ The following packages will be upgraded: │
│ wpasupplicant │
│ 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. │
│ 1 not fully installed or removed. │
│ Need to get 1304 kB of archives. │
│ After this operation, 65.5 kB disk space will be freed. │
│ Get:1 https://deb.debian.org/debian bookworm/main arm64 wpasupplicant arm64 2:2.10-11 [1304 kB] │
│ debconf: delaying package configuration, since apt-utils is not installed │
│ Fetched 1304 kB in 0s (4909 kB/s) │
│ (Reading database ... ^M(Reading database ... 5%^M(Reading database ... 10%^M(Reading database ... 15%^M(Reading dat │
│ ... 20%^M(Reading database ... 25%^M(Reading database ... 30%^M(Reading database ... 35%^M(Reading database ... 40%^M│
│ database ... 45%^M(Reading database ... 50%^M(Reading database ... 55%^M(Reading database ... 60%^M(Reading database │
│ (Reading database ... 70%^M(Reading database ... 75%^M(Reading database ... 80%^M(Reading database ... 85%^M(Reading │
│ database ... 90%^M(Reading database ... 95%^M(Reading database ... 100%^M(Reading database ... 14623 files and direc │
│ currently installed.)^M │
│ Preparing to unpack .../wpasupplicant_2%3a2.10-11_arm64.deb ...^M │
│ Unpacking wpasupplicant (2:2.10-11) over (2:2.10-10) ...^M │
│ Setting up initramfs-tools (0.142) ...^M │
│ update-initramfs: deferring update (trigger activated)^M │
│ Setting up wpasupplicant (2:2.10-11) ...^M │
│ wpa_supplicant.service is a disabled or a static unit not running, not starting it.^M │
│ Processing triggers for initramfs-tools (0.142) ...^M │
│ ln: failed to create hard link '/boot/initrd.img-5.10.110-rockchip-rk3588.dpkg-bak' => │
│ '/boot/initrd.img-5.10.110-rockchip-rk3588': Operation not permitted^M │
│ update-initramfs: Generating /boot/initrd.img-5.10.110-rockchip-rk3588^M │
│ W: No zstd in /usr/bin:/sbin:/bin, using gzip^M │
│ ^M │
│ gzip: stdout: No space left on device^M │
│ E: mkinitramfs failure gzip 1^M │
│ update-initramfs: failed for /boot/initrd.img-5.10.110-rockchip-rk3588 with 1.^M │
│ dpkg: error processing package initramfs-tools (--configure):^M │
│ installed initramfs-tools package post-installation script subprocess returned error exit status 1^M │
│ Errors were encountered while processing:^M │
│ initramfs-tools^M │
│ E: Sub-process /usr/bin/dpkg returned an error code (1)""Reference code: ee141e35-d9ac-41e6-9710-5fc864df28f6"
MichaIng
commented
1 year ago gzip: stdout: No space left on device
Your /boot partition is nearly full. Can you show its content?
ls -al /bootsaw that too, but more worried about the zstd / gzip issues, as I thought I read somewhere that Bookworm need zstd somewhere... (if it is full, it comes from the default image, as I didnt do anything yet...)
root@DietPi:~# ls -al /boot
total 88991
drwxr-xr-x 4 root root 2048 Jan 1 1970 .
drwxr-xr-x 18 root root 4096 Jan 17 22:52 ..
-rwxr-xr-x 1 root root 0 Feb 1 11:36 .next
-rwxr-xr-x 1 root root 33823232 Feb 1 11:36 Image
-rwxr-xr-x 1 root root 7814657 Jan 23 22:03 System.map-5.10.110-rockchip-rk3588
-rwxr-xr-x 1 root root 2710 Jan 17 22:42 boot.cmd
-rwxr-xr-x 1 root root 2782 Jan 17 22:46 boot.scr
-rwxr-xr-x 1 root root 215508 Jan 23 22:03 config-5.10.110-rockchip-rk3588
drwxr-xr-x 4 root root 3072 Feb 1 11:38 dietpi
-rwxr-xr-x 1 root root 18092 Jan 15 22:29 dietpi-LICENSE.txt
-rwxr-xr-x 1 root root 15518 Jan 15 22:29 dietpi-README.md
-rwxr-xr-x 1 root root 3950 Jan 17 22:52 dietpi-wifi.txt
-rwxr-xr-x 1 root root 16271 Feb 2 11:53 dietpi.txt
-rwxr-xr-x 1 root root 349 Jan 17 22:42 dietpiEnv.txt
drwxr-xr-x 3 root root 512 Feb 1 11:36 dtb
-rwxr-xr-x 1 root root 7688883 Feb 1 11:36 initrd.img-5.10.110-rockchip-rk3588
-rwxr-xr-x 1 root root 7688947 Feb 1 11:36 uInitrd
-rwxr-xr-x 1 root root 33823232 Jan 23 22:03 vmlinuz-5.10.110-rockchip-rk3588
Joulinar
commented
1 year ago saw that too, but more worried about the zstd / gzip issues
This was just a warning and not an issue. Can you share as well df -h
isarrider
commented
1 year ago root@DietPi:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.7G 0 1.7G 0% /dev
tmpfs 374M 7.7M 366M 3% /run
/dev/nvme0n1p2 235G 486M 225G 1% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/nvme0n1p1 127M 114M 13M 90% /boot
tmpfs 1.9G 9.7M 1.9G 1% /tmp
tmpfs 50M 32K 50M 1% /var/logbut more worried about the zstd / gzip issues
It's two different things. zstd is used by default for initramfs compression since Bookworm, if supported by the kernel. Good to know that it is. Can you please still verify:
grep CONFIG_RD_ZSTD /boot/config-5.10.110-rockchip-rk3588If this shows CONFIG_RD_ZSTD=y, you can have better initramfs compression and faster decompression by installing the respective tool:
apt install zstdHowever, this is purely optional, the problem is the insufficient boot partition space.
I see, on kernel upgrade, since it is a FAT partition, the Linux image image is created as copy and not as symlink (or hardlink) or instead of just being renamed. Hum, I think we should switch to ext4 then.
For now to fix it:
rm /boot/{vmlinuz,initrd}-5.10.110-rockchip-rk3588
apt full-upgradeah - thx... actually I am not sure that I need zstd then... Could it be an option to set the boot part to 256MB? For big SD / SSDs, prob nowadays doesnt matter?
MichaIng
commented
1 year ago Could it be an option to set the boot part to 256MB?
I'm no fans of wasting space no no reason. ext4 is supported by the kernel, provides better data integrity less disk writes and usage, since symlinks are used on kernel updates. Downside is that one cannot so easily access the dietpi.txt and dietpiEnv.txt from Windows and macOS, but it's a consistent problem at least 😄.
New images are currently built, also with zstd installed OOTB. Since it was a fresh first boot, its probably easier in your case to flash the new image than recreating the /boot filessystem.
isarrider
commented
1 year ago Ill flash the new image on my test SD Card and let you know... -> Yeah - File systems and the up & downsides... ;) Is there a way btw to set all the APT settings before first boot to:
│ APT cache : [Disabled] │
│ APT lists : [In RAM] │
│ List compression : [On] │
│ APT archives : [In RAM] │Didnt see anything in dietpi.txt
MichaIng
commented
1 year ago Not without creating/adjusting the respective config file manually:
cat << '_EOF_' > /etc/apt/apt.conf.d/99-dietpi-cache
Dir::Cache "/tmp/apt";
Dir::Cache::archives "/tmp/apt/archives";
Dir::State "/tmp/apt";
Dir::State::extended_states "/var/lib/apt/extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache::pkgcache "";
Dir::Cache::srcpkgcache "";
_EOF_then I am proposing a new Dietpi.txt entry... Shall I open a feature req?
MichaIng
commented
1 year ago Yes, please do so.
MichaIng
commented
1 year ago Original issues solved with new images. Let me know if you need instructions about how to migrate to ext4 boot partition on your system, i.e. copying boot filesystem content elsewhere, reformatting it to ext4, moving content back in, adjusting UUID in fstab.
isarrider
commented
1 year ago thanks - more like an easy way to edit the DietPi.txt on windows that I have to use ;)
MichaIng
commented
1 year ago Just tested again with WSL2 --mount option. For USB devices it generally fails and needs extra software that works like VirtualHere to provide the USB device via IP network within the guest. Then from there it can be mounted, although this again does not work with SD cards, probably not with any MMC device, i.e. MMC/SD card readers. I was so waiting for this feature to solve all those ext4 on Windows problems once and for all, and now it isn't usable in the most common use cases we face here 😞.
isarrider
commented
1 year ago this is why BTRFS might be a better choice: https://github.com/maharmstone/btrfs
MichaIng
commented
1 year ago Interesting. I hope it works reliable. Any implementation of ext4 on Windows I tested works horribly unreliable, mostly breaking the filesystem when attempting to write to it.
Any non-ext4 filesystem will be optional/non-default on DietPi: F2FS is for flash drives only, Btrfs is usually overkill and AFAIK slower than ext4, so only reasonable if your really need to additional features it provides. ext4 is and was the best and most reliable allrounder, but sadly neither on Windows nor on macOS (same problem as on Windows, horrible driver implementations only) safely accessible.
isarrider
commented
1 year ago I never have tested it exhaustively... But it could be an option... If BTRFS is slower - by what %... I think it makes up in features for that. BTRFS + zstd 1 might be a good deal... (https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git/commit/?h=next&id=5c1aab1dd5445ed8bdcdbb575abc1b0d7ee5b2e7)
MichaIng
commented
1 year ago If BTRFS is slower - by what %...
Quite significantly in some test scenarios: https://www.phoronix.com/review/linux-50-filesystems But highly depends on how it is used, where the bottleneck is, and things may have changed with recent Linux versions.
I think it makes up in features for that.
Of course, if you need/want the features. Most users however won't use them, and ext4 is the still most proven and overall very well performing solution 😉. Do not misunderstand me, I'm all fore offering Btrfs and F2FS images, even other filesystem types once support has been implemented, just not as the promoted default download.
Btw: thanks for the zstd bench link. Pretty impressive how well it performs, with compression level from 1 - 9 depending on needs, defeating nearly all competitors. We are already implementing it as default for initramfs compression. More importantly, we need to use it for our zram-swap implementation. LZMA//7z/xz can still compress better, if compression is all what is relevant, respectively compression/decompression speed does not matter, so for our image and package downloads we'll stay with that.
So wanted to help testing bookworm... Rock5 - latest image (https://dietpi.com/downloads/images/DietPi_ROCK5B-ARMv8-Bookworm.7z) 1st boot: the normal apt-get look good, but the dist upgrade throws an error... I sent a log a few hours ago... (with bullseye all runs smooth) Can update more details later...