Debian look likely to drop the i386 installer

johnraff · 2024-06-03 06:55:40

Bearded_Blunder wrote:

FWIW I just today (June 2nd 2024) installed 32 bit Sid for a lark, used the netboot mini.iso (all 46M of it)

Nice find - I was planning some day to search for a 32bit installer to see if such things still existed. Seems they do.
It remains to be seen whether live-build can still find what it needs to build a whole BL iso (or just a base install), but at least a variant of the BL netinstall script might be able to do something with it.

I have real 32 bit hardware (a laptop, still running a PATA spinning disk) I might try that on next, if I can remember the kernel parameter I need to add to force PAE because of a bug in the Pentium M chip, it has it but doesn't report it, I can easily look that up though.

Wasn't there an argument that PAE had little to offer low-memory systems anyway? My 32bit laptop with 1GB RAM and a Centrino CPU can probably be excused having to deal with PAE I guess.

Sector11 · 2024-06-03 15:04:41

What's wrong with a spinning disk.

Bearded_Blunder · 2024-06-03 20:31:12

Sector11 wrote:

What's wrong with a spinning disk.

They are less than ideal as the OS disk in something portable, when compared to an SSD they run slower, use more power, & are way more vulnerable to minor bumps & knocks, especially while running.

Different story entirely when it comes to bulk storage.

Sector11 · 2024-06-04 00:55:12

Bearded_Blunder wrote:

Different story entirely when it comes to bulk storage.

Or a desktop.
I can well appreciate the idea of one in a laptop.

johnraff · 2024-06-05 06:49:44

Bearded_Blunder wrote:

installed 32 bit Sid for a lark, used the netboot mini.iso

I tried this (thanks for finding it) on a qemu VM emulating a pentium3 CPU. The above daily iso showed a boot splash (still claiming to be Debian 12) but then any selected option sent it into a 100%CPU freeze with dead black screen. To check I hadn't made a silly mistake I tried the Bookworm i386 mini.iso on the same VM which booted and installed fine.

OK, so upgraded that i386 Bookworm to Trixie similarly to Beryllium>Boron and that seemed to give me a working 32bit Trixie, until I rebooted so that the 6.7 kernel would be used. At that point got the same 100% CPU freeze. "But B_B's install of Sid worked" I thought, so maybe Sid's 6.8 kernel would be OK. Downloaded and installed that, but no, the same freeze. If in the grub boot menu I choose the 6.1 kernel that came with Bookworm then it boots OK.

So on my 32bit qemu VM it seems that kernels newer than 6.1.67 or so (don't know the exact break point) don't work.

(BTW no problems with the amd64 Trixie mini.iso)

@B_B do you have any hints? What kind of VM did you install 32bit Sid on?

Bearded_Blunder · 2024-06-05 07:18:02

My install was using VirtualBox, so I couldn't tell it a cpu type, could well be the difference, I think I'd have tried an emulated P4, there can't be many PIIIs still running, if you want I could try getting a CLI only system installed on my P2 (real hardware), that's not going to run a graphical environment though, well maybe possibly Bunsen Base, it won't run a browser though, they're all compiled assuming instructions the processor doesn't have. Or when I get round to it I have a P4(M) laptop I could try on..

[edit]
Debian don't recommend anything less than a 1 GHz P4 for a desktop system for Bookworm, & that's using a "light" desktop. Might be a fair minimum if a Trixie base can be done in 32 bit at all.
[/edit]

Last edited by Bearded_Blunder (2024-06-05 07:44:20)

WolfeN · 2024-06-05 18:16:39

I have 3 old PCs in storage and look forward to the day when I can break them out again and use them. I'd like to know I can install linux on them any time in the future. Maybe I should start archiving some 32-bit distro ISO's. Being able to run updates would be nice though.

But, I can understand progress, after all we don't have hand cranks to start cars anymore, and as mentioned above, I can download 32-bit ISO's now and at least be able to run the basics.

For BL, I'm fine with whatever decision is made by the developers, and as always many thanks for this awesome distro!

johnraff · 2024-06-06 07:50:18

Bearded_Blunder wrote:

My install was using VirtualBox, so I couldn't tell it a cpu type, could well be the difference, I think I'd have tried an emulated P4, there can't be many PIIIs still running, if you want I could try getting a CLI only system installed on my P2 (real hardware), that's not going to run a graphical environment though, well maybe possibly Bunsen Base, it won't run a browser though, they're all compiled assuming instructions the processor doesn't have. Or when I get round to it I have a P4(M) laptop I could try on..
[edit]
Debian don't recommend anything less than a 1 GHz P4 for a desktop system for Bookworm, & that's using a "light" desktop. Might be a fair minimum if a Trixie base can be done in 32 bit at all.
[/edit]

Thanks for the offer of testing on your hardware. If you have the time it would be a useful extra data point, but I think I've got a bit more of an idea now. Clearly pentium3 wasn't good enough. There is a long list of CPU models to choose from in virt-manager if you don't choose to pass through the host's processor as-is:

john@boron:~$ virsh domcapabilities --arch $(uname -m) | grep "model usable='yes'" | sed "s/<model usable='yes' vendor='[[:alpha:]]*'>//;s/<\/model>//"
      qemu64
      qemu32
      pentium3
      pentium2
      pentium
      n270
      kvm64
      kvm32
      coreduo
      core2duo
      Westmere-IBRS
      Westmere
      SandyBridge-IBRS
      SandyBridge
      Penryn
      Opteron_G2
      Opteron_G1
      Nehalem-IBRS
      Nehalem
      IvyBridge-IBRS
      IvyBridge
      Haswell-noTSX-IBRS
      Haswell-noTSX
      Conroe
      486

There's no pentium4 option available, and I've very little idea what the other names mean, except that most of them look like 64bit CPUs somehow. I tried generic "pentium" and "qemu32" - no good - but finally "kvm32" ran the new kernels OK.

https://www.berrange.com/posts/2018/06/ … x86-hosts/
https://rwmj.wordpress.com/2010/10/08/3 … pu-in-kvm/

Reading up a bit it seems kvm32 is not recommended at all, and the general advice is to use an emulated 64bit CPU even for a 32bit guest. That would likely work fine, but my goal here is not to have a performant and secure 32bit guest, but simply to test whether our 32bit packages and isos will work on oldish hardware. For that I'd prefer to emulate the oldest CPU which will still work. If you can suggest anything on the above list to try, I'll give it a shot.

Meanwhile, I copied a recent i386 mini.iso onto a USB stick and tried it on my 32bit laptop with a Centrino CPU. Yes, it booted off it and the installer started up OK so it looks as if we're OK to carry on a bit longer with i386. But there's no guarantee that will continue right up to Trixie release time, and I'd be rather surprised if Debian put out official i386 installer isos. Getting live-build to sucessfully build 32bit isos is in doubt as it relies on being able to download the udeb files needed to put together the installer. It might turn out that upgrading from Boron will be the only way to get a 32bit Carbon , and that only if we're lucky.

Bearded_Blunder · 2024-06-10 21:41:06

johnraff wrote:

There's no pentium4 option available, and I've very little idea what the other names mean, except that most of them look like 64bit CPUs somehow.

They're basically Intel or AMD internal codenames for the production technology / architecture If they'd got the generation my 64bit core2quad is listed the codename would be "Yorkfield". Though they've not been consistent in the naming.

The old 32 bit laptop I loaded on if listed (it's not) Might be either Pentium M or M Banias...

      qemu32          Looks 32bit, but who knows what instruction sets it has...
      pentium3        32 bit but too old (no sse2 don't think a mainstream browser will run at all)
      pentium2        32 bit but way too old  (no sse2)
      pentium         Ditto, no mmx either. Except confusingly the name has been 
                            re-used since with newer 64 bit stuff.

      n270               Intel Atom (2008) 32 bit. (I had one but it that netbook died)
                            Later Atoms are often 64 bit but so weak running 32 might be better.
      
      kvm32            looks 32bit, but who knows what instruction sets it has...

      coreduo          It's 64 bit but on early MacBooks they paired it with 32bit EFI
                           Making installing 64 bit a manual process involving getting boot files
                           from 32 bit for the EFI partition.
      
      Conroe           Which one of a dozen+ variants? Could be either 32 or 64 bit depending.
      486              Way Way too old.

Pentium 4s have sse2 & also sse3 after they switched from the 130nm (Northwood) to the 90nm (Prescott) production process.

Assuming that netboot mini.iso installer remains available & viable, at the least a netinstall option might be possible, assuming the backups from my server are OK I might be able to update what I had & hack something together by way of a preseed.cfg had one going reasonably, hadn't figured out embedding it.
Then my home-lab let out the magic blue smoke, stranding the VMs on SAS drives behind an embedded RAID controller.
Sadly nothing so simple as the power supply either.

Pretty cool what I found could be done in preseed late_command, I just don't want to repeat all the research.

Just testing & tweaking an updated version would be hard enough, without learning all over again.

Beats resorting to install BoronWorm & upgrade to CarTrixie in-place.

johnraff · 2024-06-11 02:56:23

^Thanks for the extra data there. It looks as if most people wanting to run a 32bit system should pick a 64bit capable CPU anyway. For testing 32bit BL images I could do the same, but if possible would like to try to emulate an earlier processor, if qemu offer anything suitable. Why? Just to be able to say the image will run on old hardware with a bit more confidence.

Clearly those pentium* options are no use, and my own testing to date showed that the Debian Trixie i386 installer wouldn't run with qemu32 either. kvm32 is not well spoken of in the only docs I could find, but the Trixie kernel runs on it. I'll also try n270, coreduo and Conroe just to see what happens.

Then my own Centrino-equipped laptop is another real-hardware testbed.

Last edited by johnraff (2024-06-11 09:19:50)

johnraff · 2024-06-11 02:59:01

Bearded_Blunder wrote:

Assuming that netboot mini.iso installer remains available & viable, at the least a netinstall option might be possible...
Beats resorting to install BoronWorm & upgrade to CarTrixie in-place.

Yes, if Big D choose to keep the 32bit mini.iso then we'll have something to offer any i386 users.

johnraff · 2024-06-11 09:28:29

johnraff wrote:

I'll also try n270, coreduo and Conroe just to see what happens.

i386 cli Trixie was able to boot with all three of those. I'll set it to n270 for now, and try installing the bunsen-meta-base X session.

btw

lscpu

gave some emulated CPU details on my cli-only Trixie (with Debian essential, important and standard packages). I could extract that data from the VM if you're interested.

Last edited by johnraff (2024-06-11 09:42:28)

Bearded_Blunder · 2024-06-11 11:19:44

johnraff wrote:

I'll also try n270, coreduo and Conroe just to see what happens.

i386 cli Trixie was able to boot with all three of those.

If the one set to Conroe is still around, & out of curiosity, you can tell if it's emulating one of the 64 bit variants by

grep flags /proc/cpuinfo | grep lm

If it's doing a 64bit variant, that'll spit out the flags line for each core
In which case it'll most likely be emulating one of the socket 775 Core 2 Duo or Xeon parts, or the lowest common denominator between them.

From digging at what docs I can find I think kvm32's "very limited feature set" pretty much resembles a P4.

Sorry I've not got to firing up the old actual P4 yet, that'll be "fun" If I remember correctly one of the 2 RAM sockets is faulty so it runs without hyperthreading (1 logical core) & only seeing half what's installed. It's only hanging around because the case has many 5/14 bays, unlike modern cases.

Once I get that fired up I'll post the cpu flags so you have a datapoint for comparison.

On the old thinkpad I (with forcepae on the kernel command line) I get:

grep flags /proc/cpuinfo 
flags      : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov cflush dts acpi mmx fxsr sse see2 tm pbe bts cpuid est tm2 pti

Also very limited.

Edit to update: Sadly the old P4 is a no POST, it did before being set to one side, the symptoms & tester say it's the PSU, I'm not about to buy one for it, so unless I can find an ATX PSU with a 20 pin connector (or a 24 that splits down to 20) in a junkpile that test is off, at least, postponed for the forseeable.

Last edited by Bearded_Blunder (2024-06-11 11:49:21)

johnraff · 2024-06-12 05:22:13

johnraff wrote:

I'll set it to n270 for now...
btw
lscpu
gave some emulated CPU details on my cli-only Trixie (with Debian essential, important and standard packages). I could extract that data from the VM if you're interested.

Forgot, a screenshot from a VM is very easy to do:

That's with n270, now with Conroe:

and kvm32:

Finally coreduo:

For testing, my guess is that there's not much to choose between them. n270 has no vulnerabilities shown though.

Last edited by johnraff (2024-06-12 05:23:45)

Bearded_Blunder · 2024-06-12 13:10:09

Soooo...
You've caused me to reinstall QEMU for Windows, which has reminded me why I got rid after a short try-out.
I suppose it's in a good cause though. No acceleration available on Windows (Not with my old Core2Quad) since it requires enabling a feature which windows won't, missing a required CPU flag.
Also no GUI for the 64 bit variant, so CLI only.

johnraff wrote:

I tried this (thanks for finding it) on a qemu VM emulating a pentium3 CPU. The above daily iso showed a boot splash (still claiming to be Debian 12) but then any selected option sent it into a 100%CPU freeze with dead black screen. To check I hadn't made a silly mistake I tried the Bookworm i386 mini.iso on the same VM which booted and installed fine.

In the immotal words of maintaines when bugs get reported "Works here! ®".
Installed (glacially) using:

qemu-system-x86_64 -cpu pentium3 -m 1024 -cdrom "C:\Users\Beardy\Downloads\mini.iso -drive file="D:\qemu\trixie.cow,format=qcow2 -nic user,dns=8.8.8.8

I imagine you had -enable-kvm in your command line, which is impossible here, wonder if that's related?

Forgot, a screenshot from a VM is very easy to do:

Only if you remember your password for imgur, or the mailserver/email you usedis available, mailserver went offline when that home-lab let out the magic smoke.

Consequently I'm posting from inside that P3 VM, so I can more easily pust stuff like lspcu

beardy@P3-Carbon:~$ lspcu
Architecture:                         i686
CPU op-mode(s):                       32-bit
Address sizes:                        36 bits physical, 32 bits virtual
Byte Order:                           Little Endian
CPU(s):                               1
On-line CPU(s) list:                  0
Vendor ID:                            GenuineIntel
Model name:                           Pentium III (Katmai)
CPU family:                           6
Model:                                7
Thread(s) per core:                   1
Core(s) per socket:                   1
Socket(s):                            1
Stepping:                             3
BogoMIPS:                             5999.42
Flags:                                fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 mmx fxsr sse cpuid hypervisor pti
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          KVM: Mitigation: VMX unsupported
Vulnerability L1tf:                   Mitigation; PTE Inversion
Vulnerability Mds:                    Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
Vulnerability Meltdown:               Mitigation; PTI
Vulnerability Mmio stale data:        Unknown: No mitigations
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Not affected
Vulnerability Spec store bypass:      Vulnerable
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

Dillo being broken for coming here I had to install netsurf-gtk as an alternative.
Much as I might have liked Midori,experience from years back tells me it'll crash on any system without sse2. Yes NetSurf is a tad more sluggish, but avoids that issue on really old hardware. I suspect it's more sluggish loading pages expressly because it's compiled without sse2 in the CFLAGS bound to be slower when not optimised that way.

Anyhow, going to switch back to the host PC now, this is painful in an unaccelerated QEMU VM, it might be borderline useable for single task at a time & don't even think about playing video on real hardware, I don't have any such to test on though.

Last edited by Bearded_Blunder (2024-06-12 13:16:37)

Bearded_Blunder · 2024-06-12 13:58:01

johnraff wrote:

For testing, my guess is that there's not much to choose between them.though.

For testing there probably isn't, I did do some grepping of the interwebs & found some old fora with P4 owners who'd posted the output from cat /proc/cpuinfo, for reference: cpu_family 8 model 2

As data points I have stepping 2 & 7.

Stepping 2:

flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm

Stepping 7:

flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts sync_rdtsc cid xtpr

Discounting stuff that the kernel/qemu adds such as hypervisor on a cursory look kvm32 is the closest look-alike to a P4 there, at least as is.

I did get n270 looking pretty close too, sorry no screenshot, I simply booted the iso, started the installer, switched to a TTY & issued cat /proc/cpuinfo repeatedly.

The nearest I could make the flags look to an actual P4 stepping 2 was starting thus:

qemu-system-x86_64 -cpu n200,nx=off,constant_tsc=off,pni=off,monitor=off,ds_cpl=off,est=off,tm2=off,ssse3=off,xptr=off,lahf_lm=off <rest of command line>

No idea if that's useful data or not. Even though I've had an install run on an emulated P3 I don't think anything less than a P4 is really viable.

... n270 has no vulnerabilities shown.

Real hardware will show most if not all of them if it's P4 era. The kernel implements mitigations, though for an isolated (unconnected), or very intermittently connected system, turning off the mitigations for Spectre & Meltdown using kernel boot parameters can garner a performance boost that's quite perceptible.

Not something to do routinely, but for a suitably used system...

johnraff · 2024-06-13 04:49:55

Bearded_Blunder wrote:

Soooo...
You've caused me to reinstall QEMU for Windows...

No Linux machine to install on?

Installed (glacially) using:
qemu-system-x86_64 -cpu pentium3 -m 1024 -cdrom "C:\Users\Beardy\Downloads\mini.iso -drive file="D:\qemu\trixie.cow,format=qcow2 -nic user,dns=8.8.8.8
I imagine you had -enable-kvm in your command line...

I made the VM on the very usable virt-manager - haven't checked the exact command which launches it. It can easily be tweaked from the GUI after shutting down, but anyway I'm pretty sure kvm is being invoked along with qemu.

which is impossible here, wonder if that's related?

No KVM for qemu on Windows? I thought stuff like that depended more on the machine's hardware/BIOS layer than the OS?

Forgot, a screenshot from a VM is very easy to do:
Only if you remember your password for imgur, or the mailserver/email you usedis available, mailserver went offline when that home-lab let out the magic smoke.

Imgur allows anonymous uploads. It's very easy to upload a screenshot if you're running BL - keybind PrtScr invokes xfce4-screenshooter; "Active window" option works well here. No passwords or mail addresses needed.

Consequently I'm posting from inside that P3 VM

OK that's an option too, and lets you post real text which is nicer than an image.

Dillo being broken for coming here I had to install netsurf-gtk as an alternative.

Sorry, I'll get to that eventually. Meanwhile you could temporarily enable BL Boron in apt sources and install dillo from there.

Bearded_Blunder · 2024-06-13 06:06:23

johnraff wrote:

No Linux machine to install on?

Being lazy & trying to save time, I've a couple machines, but they're both spitting errors. They're not good candidates for hosting VMs though.

There's a Dell Optiplex that's old enough to belong in this test, which is complaining about keyboard failure on boot, though it does boot to a login screen I think my physical KVM switch needs a new USB cable on that port, & I lack one the right length. That's another P4 I had but forgot was a P4, distracted by the fact it's one of the less common very late 64 bit capable P4s.

There's there's an old HP something (actual desktop form factor, to give an idea of the age) which has to have kernel params supplied (buggy apic? I'd have to boot it & inspect the grub command line to remind myself), which when attempting to boot is giving me a series of 8 beeps & no video output.

Neither is blessed with an overabundance of RAM & so far as I'm aware, processors aren't VT enabled, so no KVM accel there either. Not good candidates for running VMs on, though they may be candidates for actual testing.

Apart from my Windows box & the half decent laptop everything hand-me down dumpster dive specials which belong on a Retro PC youtube channel.

Windows was (I thought) quicker than troubleshooting the junkpile. I can't even remember if that's HP is a core duo or core 2 duo, but it's the era to be either. KVM as such is a Linux thing, there is a Windows equivalent to get accel on QEMU, but even the Windows box is one generation of processor too old to enable it.

Dillo being broken for coming here I had to install netsurf-gtk as an alternative.
Sorry, I'll get to that eventually. Meanwhile you could temporarily enable BL Boron in apt sources and install dillo from there.

Will do. Though I quite like NetSurf, tends to be my go-to for ancient boxes that won't handle Firefox.

Bearded_Blunder · 2024-06-13 07:05:23

OK, have done, that version appears to work.
Significantly quicker, but not in the same league for pretty as NetSurf.

Gets the job done though which is the important thing.

Posted using Dillo inside P3 VM

Edit to add, when posting it doesn't finish redirecting to display the post & you're required to click the link to end up seeing it. So quicker, but less polished.

Last edited by Bearded_Blunder (2024-06-13 07:08:05)

johnraff · 2024-06-13 07:09:56

Dillo's not pretty at all. What's always appealed to me is the speed, only that.

#21 2024-06-03 06:55:40

Re: Debian look likely to drop the i386 installer

#22 2024-06-03 15:04:41

Re: Debian look likely to drop the i386 installer

#23 2024-06-03 20:31:12

Re: Debian look likely to drop the i386 installer

#24 2024-06-04 00:55:12

Re: Debian look likely to drop the i386 installer

#25 2024-06-05 06:49:44

Re: Debian look likely to drop the i386 installer

#26 2024-06-05 07:18:02

Re: Debian look likely to drop the i386 installer

#27 2024-06-05 18:16:39

Re: Debian look likely to drop the i386 installer

#28 2024-06-06 07:50:18

Re: Debian look likely to drop the i386 installer

#29 2024-06-10 21:41:06

Re: Debian look likely to drop the i386 installer

#30 2024-06-11 02:56:23

Re: Debian look likely to drop the i386 installer

#31 2024-06-11 02:59:01

Re: Debian look likely to drop the i386 installer

#32 2024-06-11 09:28:29

Re: Debian look likely to drop the i386 installer

#33 2024-06-11 11:19:44

Re: Debian look likely to drop the i386 installer

#34 2024-06-12 05:22:13

Re: Debian look likely to drop the i386 installer

#35 2024-06-12 13:10:09

Re: Debian look likely to drop the i386 installer

#36 2024-06-12 13:58:01

Re: Debian look likely to drop the i386 installer

#37 2024-06-13 04:49:55

Re: Debian look likely to drop the i386 installer

#38 2024-06-13 06:06:23

Re: Debian look likely to drop the i386 installer

#39 2024-06-13 07:05:23

Re: Debian look likely to drop the i386 installer

#40 2024-06-13 07:09:56

Re: Debian look likely to drop the i386 installer

Board footer