PREP_SYSTEM_FOR_DIETPI.sh support building on jessie

[FredericGuilbault]

In PREP_SYSTEM_FOR_DIETPI.sh

# Fixing sources.list due to Debian dropped Jessie support: https://github.com/MichaIng/DietPi/issues/2665
	if grep -qi 'jessie' /etc/os-release && ! grep -qi 'raspbian' /etc/os-release; then

Does Dietpi still build and ship jessie images ?
Could I remove the support of it ?

cuz it's not here in the user inputs options :
# Distro Selection
DISTRO_LIST_ARRAY=(

		'4' ': Stretch (current stable release, recommended)'
		'5' ': Buster (testing only, not officially supported)'

	)

[MichaIng]

@FredericGuilbault
We support to build DietPi on a Jessie image, but it will upgraded to at least a Stretch image. So we do not support fresh Jessie DietPi images anymore.

We have the new "jessie-support" branch where the PREP script allows to keep Jessie: https://github.com/MichaIng/DietPi/blob/jessie-support/PREP_SYSTEM_FOR_DIETPI.sh
But that should only be used as last resort and will not be maintained after DietPi v6.24. v6.23 and v6.24 changes will still be merged into this branch, but I will not invest much time anymore to fix Jessie related issues.

See: #2332

[FredericGuilbault]

So, is it ok if I remove the code related to building on jessy from PREP_SYSTEM_FOR_DIETPI.sh
Or you prefer to keep around ?

[MichaIng]

@FredericGuilbault
Since Fourdee now explicitly re-added it to our code, let's leave it. However for your own needs you are of course free to do so.

I personally would also remove it to not allow creating fresh images that will be out of our support soon and for sure will run into more issues when installing incompatible 3rd party software.

[FredericGuilbault]

ok, no problems.

[FredericGuilbault]

I will try hard to not make my self unique and having to deal with merging conflicts. Unless it"s REALLY a deal breaker, ill go with how dietpi do things. I realy prefer to contribute here then having my own special version to maintain.

[MichaIng]

@FredericGuilbault

I realy prefer to contribute here then having my own special version to maintain.

Very welcome. This is also my philosophie: Instead of only fixing/optimising things for DietPi, share/contribute those to the upstream developers as well. It does not always work out, but at least we tried to make things better for all users, regardless of OS.

If I can help with anything, feel free to ask. And as mentioned earlier: If you can provide pre-compiled binaries for your tools, I will be happy to add them to DietPi-Software as install option, individually or as package, not sure which makes most sense. If you share instruction we can help compiling, although since I have no ARMv6 and ARMv8 device here, I can only offer ARMv7 on RPi and x86_64 currently. Although cross-compiling as last resort is of course possible as well.

[FredericGuilbault]

Atm my plan is to install my tool set On the official dietpi image, with chroot (So before the first run)
So when it will have stable reproductive builds, I will be able to install my toolset after the build, before shipping with too much adaptation.

---

For now Ill try to make everything work as it is first, Then Ill move some things to dietpi. I had no plan for updating yet so that`s my motiation to making dietpi packages.

But now Im surprise on how much work it prepesent moving form raspbian to dietpi. and im only targeting ARM and X86_64 for now. But meh, that`s part of the task, I just have to grind on it untill it work.

Your help is really cool, I feel welcome in the project, althrouI feel like im just dropping here with my big boots spamming the issue board out of nowhere 🤣

[MichaIng]

@FredericGuilbault

althrouI feel like im just dropping here with my big boots spamming the issue board out of nowhere

As long as the result is an improvment for DietPi in general, you are very welcome 😃.

[FredericGuilbault]

Talking aboot questions, How do you shrinking partitions and image drive to the real filesize +50mb before shipping ?

[MichaIng]

@FredericGuilbault
In the past we made this manually. But actually it is not required. When shrinking the file system, there is a limit that already leaves more than enough free space. Also partition/file system expansion on first boot is done during very early boot stage where no disk writes are done yet: https://github.com/MichaIng/DietPi/blob/dev/rootfs/etc/systemd/system/dietpi-fs_partition_resize.service#L4-L7
So the +50M is an obsolete relict from older times.

resize2fs -M /dev/<root_dev> resizes the file system to a minimum which is also the minimum for the partition shrink via gparted. I want to automated the partition shrink as well, but (s)fdisk does not work since it does not move data to the beginning of the partition. gparted works failsafe but I didn't find a way to automate it yet.

When creating the RPi image I take the time to play around with and finish the image creation script: https://github.com/MichaIng/DietPi/pull/2693/files

[FredericGuilbault]

@MichaIng
im currently im testing https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh
As far as I can tell, it work.