i686 support

[brianlinuxing]

Creating a feature request

Is your feature request related to a problem? Please describe:

• ... To work on I686 architecture. I have gotten the script to work, partly, on an old Sony VAIO V2S (i686), by fiddling the code to say it is an 64 bit machine.

Describe the solution you'd like:

• ...The machine has i386 Debian Buster, a fresh install of 10.7, but it failed slightly at the os prober stage, obviously it can't find linux-image-amd64 in the repo. I fixed it manually to linux-image-686, and the code continued nicely

Describe alternatives you've considered:

• ...There are plenty of workable i686 laptops that would benefit from running Diet Pi, can the script be made to support i686 machines? Fully, rather than my temporary measures. Is that acceptable, policy wise? Debian officially supports that architecture and often the processor is 64 bit but the BIOS is the limited factors (common on old iMacs). It is a shame not to offer the benefits of Diet Pi to as many people as possible. :)

Additional context

• ...Another manual intervention was required. I used vmtouch_1.3.0-1_i386.deb instead of vmtouch_i686.deb, downloading it, renaming it after the script temporarily stopped, otherwise it ran through almost everything sweetly, but seemed to be stuck at the building of fstab (after the networking phase). Powering down and rebooting nearly did the trick. However, it didn't appear to bring up the networking (was plugged in the Eithernet). The main console is unresponsive but possible to get into via alt-ctrl-f2. [I forget that the older accounts were kept]. Got into root, initial script couldn't run, no network. Dropping to shell and running diet-config, reveals no Ethernet but surprisingly there is wireless. Can't get a connection. It sees the SSID but never gets an IP address. Tried a few things. Will do more another time. Overall, I am surprised I got this far, a very impressive piece of code.

Vote for this feature on FeatHub: https://feathub.com/MichaIng/DietPi/

[Joulinar]

Hi,

many thanks for your request. Let me link an older request that was already rejected #1854

[MichaIng]

Hi Brian, nice to "see" you 🙂.

Yeah we have though about x86_32 support in the past and while it is theoretically easy to allow that uname -m architecture within our scripts, it would be a huge work to go through all software titles, check whether they are available for i386 (the DEB/binary architecture) or not, enable/disable them, in case add new download URLs to the correct libraries, decide whether we want to ship old software versions, in case and of course maintain all of this when software developers decide to drop support. I'm already annoyed by the lot of extra work that ARMv6 (RPi 1/Zero) causes, although that is additional difficulty as the DEB package architecture (armhf) matches while the CPU/binary architecture does not (armv6l vs armv7l).

So we always decided against it so far. The only thing I could imagine is to add it as kind off experimental/non-official case and by default disable all software titles for it, then enabling the ones which are only APT installs from Debian repository and keep it a volunteer user task to manually enable and test other software titles and contribute the code change/addition, where necessary. But at least from my end it would cost too much development (and maintenance) time that is desperately needed for the currently supported architectures 😉.

[brianlinuxing]

Makes sense, Micha.

I hadn't appreciated the secondary amount of work involved, and I wouldn't dream of dumping extra work on anyone.

I like your "experimental/non-official" option, access to Debian would suffice in the vast majority of cases I am sure.

I am happy to help out in this area.

But I think the whole support of multi-architecture is interesting if purely taken from the point of debugging things (code that runs only on one architecture, in my experience, tends to be more fragile). I was pleasantly surprised how little intervention I had to do.

Would a CI/CD approach help out handling additional architecture? (Not sure how it is handle now, etc)

Afterwards I worked out the first networking issue was partly mine, when I switch to another SSID it worked and found an IP address.

The downsides of this process seem (and I haven't had time to do a fuller study):

1. The Ethernet device was not re-enabled properly (might be because lspci has been removed, etc), thus stopped the script towards the end (around the fstab part).
2. A fair amount of binaries seem missing (am auditing it now to see which).
3. It cleared down the antiX partition by mistake (done a re-install of antiX, as it takes <15 minutes even on this slow machine).
4. The initial system script run in root after reboot assumes it always has a network, which might not always be the case. Works fine after setting up WiFi.

Upsides:

1. Fairly quick on old hardware.
2. Does everything for the user, needs little human input which is good.
3. Really slims down Debian!

I shall try and report more, time and health permitting!

[brianlinuxing]

I have quickly audited both of the systems (which were initially installed from scratch and nothing much added).

The antiX Linux on the Sony V2S had these additionally:

firmware-ath9k-htc
firmware-b43-installer
firmware-b43legacy-installer
firmware-bnx2
firmware-bnx2x
firmware-cavium
firmware-intel-sound
firmware-intelwimax
firmware-ipw2x00
firmware-libertas
firmware-myricom
firmware-netronome
firmware-netxen
firmware-qcom-media
firmware-qcom-soc
firmware-qlogic
firmware-ralink
firmware-samsung
firmware-ti-connectivity
firmware-zd1211

Overall, dkpg -l reveals 1640 packages on antiX, whereas DietPi on the same hardware, after having stripped out a standard Debian Buster 10.7, had 324.

Similarly, /sbin/ on antiX has about 525 binaries, DietPi had 207. Initially it lacked lspci (until I quickly installed), which triggered my investigation, as the Ethernet device** is not fully functioning just yet.

**lspci now shows:

00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82865G/PE/P AGP Bridge (rev 02)
00:06.0 System peripheral: Intel Corporation 82865G/PE/P Processor to I/O Memory Interface (rev 02)
00:1d.0 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
00:1f.6 Modem: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Modem Controller (rev 02)
01:00.0 VGA compatible controller: NVIDIA Corporation NV36M [GeForce FX Go5700] (rev a1)
02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)
02:09.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01)
02:0a.0 Ethernet controller: Qualcomm Atheros AR5212/5213/2414 Wireless Network Adapter (rev 01)
02:0b.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
02:0b.2 FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller
02:0b.3 Mass storage controller: Texas Instruments PCI7420/7620 SD/MS-Pro Controller

[MichaIng]

lspci is not driver or firmware component, so it cannot be responsible for Ethernet working or not working, but of course good for debugging. Old hardware might require old drivers/firmware that are not part of the current generic firmware packages anymore 🤔.

02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)

https://packages.debian.org/buster/firmware-realtek
81** chips are quite some included, 8139 not explicitly, but those identifiers anyway overlap in my experience. Does that one work?

02:0a.0 Ethernet controller: Qualcomm Atheros AR5212/5213/2414 Wireless Network Adapter (rev 01)

We install firmware-atheros but that contains WiFi card drivers only. Also in the additional firmware packages list from antiX I cannot see one that would install QCA Ethernet drivers, nor did I find any related package for such 🤔: https://packages.debian.org/search?keywords=firmware

[brianlinuxing]

I think we can close this.

I tend to agree, it is too much like hard work for minimal results.

I tried it again on another machine (gave that older one away), 64-bit based on Buster 10.7 XFCE 4.12 (then turned off). New Debian install (post update/upgrade and install of SSH, apart from that, complete fresh).

Done from the console took about 27 minutes, little if any human intervention apart from at start, which is nice.

Only two things:

1. It zapped my existing grub setup of: XP, and MX Linux.
2. Post installation didn't see the whole swap partition and wouldn't mount them (tried via drive manager), quick edit of fstab fixed it.

Otherwise a very good experience.

[MichaIng]

It zapped my existing grub setup of: XP, and MX Linux.

Indeed, it installs the grub-pc or grub-efi-amd64 package and hence overrides the drives bootloader. At least it installs and runs os-prober, so hence should detect and add other OS'es on the same drive, but I am not sure how reliable it is. I think we never really intended multi-boot setups with a different main OS (from where the bootloader is managed). This would require making changes to /etc/default/grub + update-grub optional, including the console resolution option, but doesn't look like much to do: https://github.com/MichaIng/DietPi/search?q=grub

Since I have no idea how to reliable determine if there is a functional bootloader installed and if it is the intended one to keep, we'd need to make this a DietPi-PREP option for x86_64. For ARMs, too much options depend on the ability to alter boot parameters, so I see no chance there to natively allow multi-boot. I just remember the Berryboot issues in this regards, which breaks large parts of dietpi-config and dietpi-software attempting to change kernel/dtb/bootloader settings, so in this case a regular minimal Debian makes more sense 😉.

Post installation didn't see the whole swap partition and wouldn't mount them (tried via drive manager), quick edit of fstab fixed it.

Jep, currently we do not support swap partitions: #2995

[brianlinuxing]

No worries, let us close it, thanks for trying, I found it all very interesting and informative.