Release v9.18 #7774
Merged
Release v9.18 #7774
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dietpi-installer: enable first run expansion for container images as well. It is now needed for ext4 journal generation, and does not hurt anyway. Many containers won't be able to inform the kernel about partition changes, but some can depending on the level of sandboxing. dietpi-trixie-upgrade: remove redundant block
* init * simple test install for lazy librarian * corrected software id * correct user and download for lazy lib * fix pip command * add service for lazylibrarian * fix permissions * fix uninstall * added lazylibrarian to dietpi-services * changed pip install to G_EXEC_OUTPUT=1 bc pip install can take a while * Update dietpi/dietpi-software remove trailing space Co-authored-by: MichaIng <[email protected]> * Update dietpi-software removed empty line --------- Co-authored-by: MichaIng <[email protected]>
The option is gracefully ignored if the dir does not exist, but the warnings can cause confusion.
There is no Forky suite yet, hence we use the Trixie one. But its FFmpeg package depends on a library version not available on Forky. Hence use FFmpeg from Debian.
…ssing We obtain the drive device node path in a failsafe way based on known schemes. If that does not exist, it is a container system that is sandboxed enough so that informing the (host) kernel about partition changes is impossible anyway. Skip expansion gracefully, but print a message. Container images need to be expanded from the host in most cases. Previously, we shipped those images without resize service enabled. Now this is needed for ext3/4 journal generation, and it does not hurt where supported. But in simple systemd-nspawn startups do not mount through any block device. dietpi-installer: detect needed filesystem packages based on mounted filesystems instead of based on attached ones. This is mostly done since blkid requires the block device node to be mounted into containers, while findmnt works. However, it makes sense in general: the installer does not unmount any filesystem, and dietpi-drive_manager installs missing packages automatically on mount.
Use patched resize script, mainly for container images, but it can be required as well if other images are on purpose booted as container.
raspberrypi.org => raspberrypi.com in some overlooked cases and some changed documentation links
Due to 64-bit time_t transition, PostgreSQL 15 is forcefully removed on dist-upgrade on 32-bit architecture: #7644 (comment)
Co-authored-by: MichaIng <[email protected]>
…rootfs device node in which case we assume the image was booted as container without block device access. The journal then needs to be created on the host, and can safely be skipped if this is a temporary image for testing or builds only. dietpi-build: remove obsolete AlloGUI workaround
Applying the dist-upgrade immediately does not cause any direct issues, but can cause indirect ones: A larger number of deb packages is downloaded at once, which might fill the tmpfs in case the APT archive has been moved into one. Also package upgrade pre-processing on slower SBCs/drives can take a very long time. And if APT runs into errors, a larger number of packages are in an unconfigured state. It does not hurt to split the upgrade into two smaller chunks which can finish faster and have a higher success chance each.
Any other key is typed into the console. Enter or Return are needed to finish read input.
since Poetry cannot make use of multiple sources properly. Either it uses PyPI only, or it uses piwheels only, no matter which priorities are used.
Generally it makes sense to exit scripts when triggering a reboot, else they continue to run until the init system kills it, which is usually not intended. Furthermore, on first login, when started from dietpi-login, its STDOUT+STDERR are redirected to a log file on disk. If the rootfs is a network filesystem, this prevents it from being able to unmount, hanging the shutdown procedure. Similarly, the login script itself should exit in these cases to avoid it looping to the next install stage if the init system takes long to initiate the shutdown procedure for some reason.
A reboot is strictly needed after adding a the filesytem journal, otherwise it is not practically used for this boot session. On reboot mount can then fail since the last metadata changes in the unused journal do not match those on disk. e2fsck fixes this, but in case only after a power cycle, if it was not triggered by another filesytem error, unclean shutdown, as part of regular fsck enforcement every 60 (default) mounts etc.
(or an unmounted fs). Since this means that additional writes are done after journal creation and hence a metadata mismatch, an fsck is strictly required to fix this. /forcefsck is ignored by initramfs-tools, fsck.mode=force via cmdline is way too complex (the many different methods and not even assured to add cmdline entries, the need to remove it afterwards), mark filesystem as dirty.
It is not requried to re-create the GPT backup partition table via gdisk. fdisk can deal with GPT partitions as well, re-creates the backup header automatically, if missing or damaged, and can be used as well to explicitly move it.
The dirty bit is somehow ignored in most cases. Also, fsck requires "-y" on first attempt, while on another run it re-generates the journal without "-y" for some reason. Hence we add fsck.repair=yes to cmdline by default from now on, there was a request for this anyway: https://dietpi.com/forum/t/24030 Update VisionFive 2 kernel build workflow, which is however still a WIP. Some code alignments in dietpi-firstboot
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
/etc/bashrc.d would run as non-root user as well, is hence not assured to run at all and would require a root permissions check. postboot.d runs via systemd service instead, independant of any login.
since v13 requires Git 2.34.1 while Bullseye provides v2.30.2 only
The exclamation mark has the special event meaning even in double-quotes.
The problem with next mount after adding a journal exists only if the initramfs performs an fsck before mounting the rootfs. It migrates the temporary /.journal inode into the hidden inode 8, and for whatever reason, this causes a failing mount, which is solved only with a forced fsck with forced repair, otherwise requires another power cycle, before fsck fixes it without "-y". If there is no initramfs (or it does not fsck), systemd-fsck runs instead, but it cannot migrate /.journal to the hidden inode 8, since the rootfs is (R/O) mounted already. It hence also does not cause the mount issue, no reboot and no forced fsck is needed. This is the reason this issue was not recognised before. There is still a little benefit when performing the reboot regardless, since the journal is pratically not in use before. It needs to be freshly mounted to become active, the R/W-remount is not sufficient. But a reboot is anyway often needed after first run setup, so that should be fine, not slowing down first run setup. Add changelog entry about the issue.
The hwclock command is not actually needed, i.e. util-linux-extra does not need to be installed. Instead of hiding (or reverting) the option if hwclock fails, hide it if the RTC device nodes it would use do not exist. This is the typical reason if fails. Also add info that fake-hwclock does not hurt if an RTC is present, since it never turns back the clock.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
v9.18
(2025-10-19)
New images
New software
Enhancements
/dev/xvd[a-z][1-9]. Many thanks to @jr551 for implementing this compatibility enhancement: Added xen hv drive support #7755mtd-utils/flashcpto/dev/mtd0as well as flashing viaddto the block device node/dev/mtdblock0. In some cases, the wrong device node was passed to the function. Many thanks to @mlanner for reporting this issue: Orange Pi 5 - Cannot boot from NVMe, dietpi-config results in "No SPI image chosen" #7761Bug fixes
/.journalto a hidden inode 8. For some reason, it then fails to mount that filesystem, requiring another reboot where fsck regenerates the journal, after which everything works fine. To avoid this, right after our script generates the journal, it triggers a reboot with forced fsck. fsck then does not only import the journal from/.journalto a hidden inode 8, but repairs whichever quirk this causes immediately, so that mounting the roofs succeeds right away.SSLUseStapling,SSLStaplingCache, and other directives starting withSSLStapling*) or Ginning config respectively. For details about why OCSP has been deprecated, see this article: https://letsencrypt.org/2024/12/05/ending-ocsp