Update Box64 branch #4676
Merged
Update Box64 branch #4676
Conversation
This file contains 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
+ Live patch | Fix Blynk server install
+ DietPi-Live_patches | Fix phpSysInfo install: #4619
+ DietPi-PREP | x86_64: Skip kernel and initramfs symlink creation on kernel installs/upgrades and remove existing ones. This is not required with grub as bootloader and breaks the ability to use a FAT partition for /boot if "link_in_boot" is set. + DietPi-PREP | Pre-create kernel and initramfs hook directories before trying to create files within. This should normally be the case, but we caught one image where the initramfs hook dirs did not exist. + DietPi-PREP | Fix initramfs hook scripts: Since Debian Bullseye, /var/lib/initramfs-tools is not used anymore, hence directly remove non-matching initramfs images. Also there is a syntax error (missing ";"). Furthermore be more explicit about the initramfs image filenames, where the version string is expected to start after a dash.
+ DietPi-PREP | Force APT list and archive downloads to tmpfs and disable binary package cache, during PREP, to avoid intense disk writes and wholes of free space. Clear downloaded archives regularly after package installs, to prevent out-of-space errors. It is sufficient to remove the related PREP-only config much later after all APT installs have been done. + DietPi-PREP | Create a fresh cmdline.txt on RPi, as the one shipped with Raspberry Pi OS in the meantime contains some deprecated entries, and it allows and assures images from scratch and converted ones to be identical in this regards. Use the apparent PARTUUID, and as well edit boot.init UUID entries on Odroids, to allow different pre-images. On C2, /dev/mmcblk0p2 is currently used as hardcoded root partition path. Whether a UUID can be used instead should be tested at best.
+ DietPi-PREP | Remove obsolete scroll lock fix on RPi, but add expected system groups, in case image was created from scratch + DietPi-PREP | Hide RPi logo at boot by default: On small screens it takes away quite a large part and generally it is not necessary limits the view for diagnostics.
+ DietPi-AutoStart | Amiberry: Skip cmdline.txt changes on RPi, as kernel/boot messages do not interfere (anymore). Also do not apply boot_delay=0 anymore: Either it is safe with the used SD card, or it breaks boot or even leads to SD card corruption in combination with forced turbo (according to some web findings about it). We'll probably re-evaluate the default (1 second) and/or add it to dietpi-config, but 1 second more or less shouldn't be relevant. + DietPi-AutoStart | Amiberry: Skip enabling systemd-logind. This is not required anymore as Amiberry does not print (service-wise) to TTY1 anymore and now boot messages remain on TTY1 as well.
+ DietPi-Software | RPi: The recommended GPU memory split is now applied on non-interactive calls (G_WHIP_DEFAULT_ITEM='Ok'), hence Kodi and Jellyfin installs are not required to apply the minimum separately anymore. The 5.10 kernel introduced the new vcsm-cma, which makes use of the system memory, along with some other changes (some hardware-wise on RPi4) which lead to less required GPU memory. The recommended values are hence reduced and may be further reduced in case of Kodi and Jellyfin after some testing. It is furthermore assure that on 256 MiB RAM models not more than 128 MiB GPU memory are applied, as this is the officially maximum recommended value by RPi docs. Also, with recent kernel/firmware, the default GPU memory is 76 MiB on all RPi models with 1 GiB RAM or more, so that the assumed default value needs to be corrected.
+ DietPi-Software | Cuberite: Remove obsolete ARMv6 workaround + DietPi-Software | Cuberite: Merge install and config code blocks + DietPi-Software | Cuberite: Error-handle most uninstall steps + CHANGELOG | Cuberite: Re-applied the official binary on ARMv6 systems (Raspberry Pi 1 and Zero) + DietPi-Software | Cuberite: Use short "-d" daemon flag and explain why we actually need to use it, as this is not a common way to run systemd services
+ DietPi-Software | PaperMC: Fix install due to missing development tools dependency + DietPi-Software | PaperMC: Assure that /usr/local/bin exists before creating mcron there + DietPi-Software | PaperMC: Merging install and config code blocks + DietPi-Software | PaperMC: Error-handle most uninstall steps + CHANGELOG | PaperMC: Resolved an issue where the install failed due to missing build dependencies.
+ DietPi-FirstBoot | On x86_64 BIOS systems, set the GRUB install device to the obtained root drive. Naturally, we cannot know on image create, what the install drives path/name is, or what type it is and UUIDs do not exist for the raw drives, where the bootloader needs to be written to. With a wrong drive in debconf, on a GRUB upgrade or install, the system can become unbootable. GRUB (or the Debian GRUB maintainers) implemented some additional checks to prevent such cases, due to many bug tracker reports, but the issue is generally not ruled out 100% and it requires a manual selection of the bootloader drive on package upgrade, when the stored one does not exist, else the upgrade fails. For our x86_64 images we know that those are full drive images with "our" bootloader stored on the same drive where the DietPi root partition is found, so we can automatically detect and apply it. Even if it is a customised image, this step cannot make things worse compared to the hardcoded "/dev/sda", which is a pure guess that most x86_64 systems will run on the first SATA drive attached to the system.
+ CHANGELOG | DietPi-FirstBoot: On our x86_64 BIOS images, the GRUB bootloader is configured to install itself on upgrade to the "/dev/sda" drive, which is the most commonly used system drive path and there is no way to configure a unique identifier that is assured to match the later actual system drive. When GRUB is upgraded, and the configured drive path does not exist, or GRUB has doubts that it is the correct system drive, the upgrade will fail. If GRUB installs itself to the wrong drive, the actually booted GRUB version won't match the GRUB files on the root filesystem, which can make the system unbootable. To enhance the situation, on first boot, DietPi detects the apparent system drive and changes the GRUB configuration accordingly. This will work on all our images, but note that on custom images it might be wrong: Generally it is possible to have the bootloader installed on one drive, but the root filesystem stored on a different physical drive, and we have no possibility to reliable detect this case. Many thanks to @brianbloom for reporting the issue: #4542
+ DietPi-Software | Lidarr: Move to .NET based builds where supported. Copy method from Radarr as Lidarr is identical in this regards + DietPi-Software | Lidarr: Merge install and config code blocks + DietPi-Software | Lidarr: Error-handle most uninstall staps + CHANGELOG | Lidarr: Where supported (on all platforms but Raspberry Pi 1/Zero), the .NET core build build is now installed, which makes the dedicated Mono runtime obsolete and should generally perform better. This migration is applied automatically during the DietPi update, your settings and data remain untouched. Many thanks for informing us about this possible enhancement: #4607 + DietPi-Patches | Reinstall on non-ARMv6 platforms to migrate to .NET based build and offer to uninstall Mono, unless Sonarr is installed, which still requires it.
+ DietPi-Software | PaperMC: Since Minecraft 1.17 requires Java 16 or newer, it does not work anymore on Debian versions below Bullseye and not on ARMv6, with the Java builds we ship. AdoptOpenJDK is currently on the process or becoming "Adoptium" and creating a new APT repository, after which we can migrate to use those to re-enable support on older Debian versions. On ARMv6 however I most likely won't work and the newest found Java build running on it at all is a single Zulu Java 11 build.
MichaIng
added
the
META
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.
No description provided.