enigma9o7
Crew Member
Posts: 1,210 
Likes: 1,213
|
Post by enigma9o7 on Jan 19, 2021 4:58:12 GMT
For past several days off and on I've been reading a long thread on debian mailing list in regards to i386 moving forward, and learned some interesting things I didn't know/understand before and thought I'd share some highlights.
For example in that message someone looked at current usage numbers of various kernels of debian users booting in the previous month, and found i386 the second most popular architecture, far more usage than all other arches that debian supports combined, with even arm being significantly less in 3rd place.
Then they further break down 32-bit kernels 3/4/5/6-86 and I learned a little bit about the differences - extensions like MMX SSE and PAE that add speed that weren't supported on the 1985 version original i386. etc. Apparently, using SSE provides significant performance improvement, and majority of debian i386 users are using the pae kernel with sse support which is basically Pentium 3 or newer and sometimes called i686. If I understood all that right, I think pae just lets you use more than 4gb ram but otherwise no improvement.
They also mention newest 32-bit Pentium 4 was made in 2007, and Pentium 3 are 20 years old, and many computers over 10 years old end up in landfill so very little reason to use new debian on something older than y2k even if you have it, cuz you can probably get something much better very cheap or free, and modern apps would run like crap.
Another issue brought up is about spectre and meltdown vulnerabilities, which were not mitigated for 32-bit intel until kernel version 4.19. Apparently these are vulnerabilities discovered a few years ago that affect most CPU newer than 1995 and without mitigations can make it possible for one app to see memory from another app which could be exploited.
So anyways, after reading that thread and making those observations, I feel like the next Bodhi Legacy should target Pentium III with pae. If you have even older machine that that you want to play with you probably dont want to use a full modern desktop environment anyway, even a light fast one like Moksha. I want Bodhi to be fast on legacy machines that people actually use with it, so I think we should include pae and sse etc. And we want people to feel secure if browsing etc so want kernel 4.19 or newer (used in debian 10 buster already).
And for the record, I do have a 2004 32-bit Pentium 4 2.8GHz 512MB running bodhi legacy (the reason I first installed linux and found this distro a few years ago in the first place), so I am familiar with how it runs on real hardware. I feel anything more than a cpu generation slower wouldn't be every fast with current Moksha anyway - so may as well make it as fast as possible for majority of people who should be using it, p3 and newer! My opinion, but I think sound logic. |
|
|
|
Post by fidoedidoe on Jan 19, 2021 14:59:31 GMT
So anyways, after reading that thread and making those observations, I feel like the next Bodhi Legacy should target Pentium III with pae. If you have even older machine that that you want to play with you probably dont want to use a full modern desktop environment anyway, even a light fast one like Moksha. I want Bodhi to be fast on legacy machines that people actually use with it, so I think we should include pae and sse etc. And we want people to feel secure if browsing etc so want kernel 4.19 or newer (used in debian 10 buster already). I found and adopted Bodhi because it supported 32-bit Non PAE processors and higher. For me, the initial reason was to help out my neighbour who had an old Windows XP laptop (upgraded to Windows 7), which was on it's knees with regards to performance (Dell Inspiron 1300 from memory). Bodhi Legacy was a perfect fit and given it's so lightweight it met/exceeded expectation and adoption to a Non Linux user went far better than expected (testament to Moksha Desktop). They even use that laptop with Audacity + USB dongle to convert Vinyl Records to MP3. Impressive for ancient 15+ year old hardware. Personally I'd argue having support for Non-PAE is a Jewel in the crown for Bodhi and I'd be very disappointed to see yet another linux distro fail to allow older technologies enjoy the benefits of "modern" desktop/OS feel and associated security (even if that doesn't mitigate Spectre variants etc - how many real world issues did that cause vs. how many PCs it slowed down via the fix?) FYI I've turned off spectre protection using kernel directive on my 7th Gen i7 so android ROM compile times are not impacted. I'd be interested in seeing the usage stats for Bodhi to see whether the "Legacy" Bodhi Community" is niche or mainstream and what sub divisions of Non-PAE/PAE supporting CPU's they fall into. It all feels somewhat subjective without supporting stats. |
|
|
|
Post by Hippytaff on Jan 19, 2021 15:37:11 GMT
I'd be interested in seeing the usage stats for Bodhi to see whether the "Legacy" Bodhi Community" is niche or mainstream and what sub divisions of Non-PAE/PAE supporting CPU's they fall into. It all feels somewhat subjective without supporting stats. Feel free to set up a poll. I’d be interested to see that too. Currently building a moksha Debian 32bit in vm to have a play, but I agree to your points re non-pae support. |
|
enigma9o7
Crew Member
Posts: 1,210
Likes: 1,213
|
Post by enigma9o7 on Jan 19, 2021 17:15:34 GMT
Yeah I think I misunderstood the pae thing anyway. I first read it affects speed significantly, but later learned it seems like that doesnt speed anythiing up at all, just gives support for more than 4gb of ram. So not actually important, anyone with more than 4gb of ram probably has 64bit cpu anyway. Its he SSE2 that speeds things up.
|
|
|
|
Post by nuihc88 on Feb 20, 2021 22:21:28 GMT
I have been researching custom kernels like Zen/Liquorix & XanMod and how to best compile them for past few months in hopes of improving the energy efficiency and responsiveness of my Asus eeePC 1005HA-H while also adding PHC-Intel module for undervolting the CPU, backporting iwlwifi for adding support for a intel AX200 WiFi+BT card and making the special ACPI keys work correctly via acpi-eeepc. Saw this thread and thought i might as well share my research up to now in case it helps with improving future versions of one of the few remaining 32bit distros out there...
First off: it's fairly rare for 32bit Linux desktops/laptops to need more than 4GB of memory, however recompiling a kernel with PAE-support is basically just a few .config switches and hours of waiting away. In theory replacing 'CONFIG_HIGHMEM4G=y' line in .config file with 'CONFIG_HIGHMEM64G=y' & 'CONFIG_X86_PAE=y' lines should suffice, although i've seen a bunch of additional platform specific optimizations in configuration-files of performance optimized kernels like Liquorix.
Another important thing to note is that you can turn off most Spectre/Meltdown-mitigations just by addding 'mitigations=off' to 'GRUB_CMDLINE_LINUX_DEFAULT=""' line in '/etc/default/grub'. I read that this option has already been backported to 4.19.43 and it should be possible to confirm whether mitigations are then disabled or enabled by running 'lscpu', although on my system that information seems to not be displayed for some reason. Furthermore Linux-kernel developers have been busy trying to "mitigate" the performance hits that their vulnerability mitigations have caused so some performance benchmarks have actually gone up as a result of increased scrutiny, however i would still advice against using 5.** on 32bit systems as new kernels seem to be having trouble building some 32bit modules correctly.
In summary, for best performance i would recommend applying new patches on top of XanMod 4.20 kernel, building it using .config copied from the target distro's latest non-PAE kernel with tweaks added from my lists below and then running menuconfig to clean out any incompatible entries and double-check things manually before compiling and then finally always running the resulting kernel with mitigations disabled through grub.
Finally here are some fairly generic tweaks for improving the efficiency of 4.** kernels:
# Trade-off Placebo-Security for Speed:
CONFIG_RANDOM_TRUST_CPU=y
# Energy-Efficiency Tweaks:
CONFIG_RCU_FAST_NO_HZ=y
CONFIG_RCU_NOCB_CPU=y
CONFIG_HZ_100=y
CONFIG_HZ=100 # higher latency; less overhead.
# Responsiveness Tweaks:
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_DELAY=100 # Arbitrary, i've seen values 0 to 500 recommended.
# LowLatency/PreEmptive Tweaks:
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_IRQ_FORCED_THREADING_DEFAULT=y
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPT_RCU=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000 # lower latency; more overhead.
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_CEC_PIN=y
# CONFIG_CEC_PIN_ERROR_INJ is not set
CONFIG_CEC_GPIO=m
# CONFIG_DEBUG_PREEMPT is not set
CONFIG_LATENCYTOP=y
# CONFIG_PREEMPT_TRACER is not set
PS. Note that 'CONFIG_HZ_100=y' from Energy-Efficiency Tweaks and 'CONFIG_HZ_1000=y' from LowLatency/PreEmptive Tweaks as well as the lines directly below them conflict with each other; personally i would pick 100 over 1000 for older computers in order to reduce system overhead.
PPS. The last kernel version to include no mitigations at all was 4.14.
|
|
enigma9o7
Crew Member
Posts: 1,210
Likes: 1,213
|
Post by enigma9o7 on Mar 14, 2021 22:38:47 GMT
The last bodhi legacy came with kernel 4.9, which was a lower version than the 4.15 provided with the ubuntu it was based on. I don't understand how that works, but if they did it before, I assume that means they can do it again. debian bullseye is including 5.10 and I believe thats what next bodhi legacy will be based on. At first I wasn't concerned, I've tried it on my oldest machines (p4, athlon64) and works fine. But then I did some reading, and learned, it will not be good for my my main machines! They both use the nvidia-340 proprietary driver. Nvidia's last update to it supports up to kernel 5.4 only, and nothing newer, and won't be updated again by nvidia, its end of life. This is all well and good for me now, cuz bodhi 5.1 even with hwe is kernel 5.4, and bodhi 6 standard / ubuntu 20.04LTS are also using kernel 5.4. So I'll be able to keep using proprietary nvidia driver for that upgrade, but it'll be the last time.... I suspect others with 32-bit systems might have the same thing. So, my current belief is, the next bodhi legacy 32-bit kernel should be version 5.4 (i686 no pae). To match bodhi 6 standard, and because if my example of how a newer kernel effects me, I bet it'll affect others with the era of pc needing legacy too. But mitigations=off sounds good to me, I've applied it to all my PCs after you brought it up here  |
|
|
|
Post by nuihc88 on Mar 24, 2021 15:22:13 GMT
Here's link to a post listing lots of extra reasons to avoid switching to 5.x kernels: LinkTL;DR: Even 5.4 kernel breaks Intel Graphics support, which includes majority of netbooks and most if not all mini laptops (including eeePCs). What makes matters even worse is that there doesn't seem to be much ongoing organized effort being put into fixing it and most bug reports filed are just closed as duplicates without proper investigation. There are also many reports of issues involving broken ACPI support and increased temperatures from all over the internet. Based on all the driver/module/firmware bugs reported, i suspect that maintaining 32bit compatibility in 5.x would turn out to be much harder and more time consuming in the long run than occasionally patching a 4.20 kernel. Since most of the mitigations themselves have already been backported to 4.x kernels without widespread reports of the same hardware issues, i suspect it's some hastily made structural optimizations for post-Spectre/Meltdown hardware that are breaking support for old hardware in 5.x kernels and i would expect those kinds of optimizations to also lead to worse performance and more overhead on older and especially 32bit hardware. |
|
enigma9o7
Crew Member
Posts: 1,210
Likes: 1,213
|
Post by enigma9o7 on Mar 24, 2021 18:03:51 GMT
Sounds good to me. 4.20 has a nice ring to it... but wouldnt 4.19 be better cuz its LTS? This next legacy version could be the last major release version of bodhi legacy, since my understanding is even debian is unlikely to support 32-bit on bookworm (but still undetermined I guess)... but using a still supported kernel version seems like good idea in any case? unless 4.20 really adds something that makes it worth knowing it'll never get security updates backported and user running outdated kernel...
4.20 was EOL March 2019.
|
|
|
|
Post by nuihc88 on Mar 24, 2021 22:13:54 GMT
I don't really have much of a preference for one over the other and wasn't even aware of the LTS stuff, i mentioned 4.20 because it's the last kernel release without significant yet unavoidable problems. I have no idea how much from 4.20 has been backported to 4.19 LTS, but from looking at 4.20's list of features now, it does appear to have been a rather impressive update and even included lots of 32bit specific improvements and significantly extended support for most types of hardware (including USB, WiFi & new chinese 32bit CPUs). Sources: Link1 & Link2I suppose if i were to build a kernel meant to closely resemble an official ubuntu/debian release, i would use 4.19; however if i were to build an optimized custom kernel, i would use 4.20 (XanMod) as base and apply patches from 4.19 LTS. In summary: 4.19 would likely be better for security and maybe stability due to being LTS, but 4.20 would be better for energy efficiency, performance and hardware support, depending of course on how much has been backported to 4.19. |
|
enigma9o7
Crew Member
Posts: 1,210
Likes: 1,213
|
Post by enigma9o7 on Mar 24, 2021 22:49:23 GMT
I dunno how much LTS support for kernel matters, but I dont think bodhi builds a custom kernel anyway, at least not historically, so I imagine whatever gets used with legacy will be some debian or ubuntu built and packaged kernel. The 4.9 kernel used with Bodhi 5.1 legacy (LTS thru Jan 2023) is from debian V9 stretch, and 4.19 is default kernel for debian V10 buster... So I have strong feeling if kernel 5.4 isn't used, 4.19 would be... and based on what you pointed out vs using 5.x on old hardware, 4.19 has my vote.
|
|
|
|
Post by nuihc88 on Mar 25, 2021 0:27:53 GMT
I guess it might also be worth mentioning that on a XanMod based custom built kernel using the tweaks mentioned above, i am getting no menu-load delays with icons enabled, everything just feels way smoother in general and CPU temperatures are lower too. I don't really know how much of that is due to the tweaks and how much is from XanMod, but it does seem like something worth exploring further.
(Due to my inexperience with compiling kernels i keep running into various problems with compiling and loading modules though, probably due to some misconfiguration on my end.)
|
|
enigma9o7
Crew Member
Posts: 1,210
Likes: 1,213
|
Post by enigma9o7 on May 27, 2021 5:30:22 GMT
wiki.linuxfoundation.org/civilinfrastructureplatform/startI just learned about this, another reason to go with 4.19; Super-Long-Term-Support. I just stumbled across this; apparently when official LTS support ends in 2024, these guys take over (and are already contributing now so know what they're doing) and will continue to maintain it for at least 5 more years thru 2029.
|
|
kev392
Crew Member
Posts: 356
Likes: 472
|
Post by kev392 on Jul 22, 2021 8:25:38 GMT
It probably makes no sense to add support for anything older than Pentium 4.
I still have a Pentium 3 and finding a web browser that still works is a real pain, because P3 only supports first generation SSE. I found the browsers that do work are incredibly slow because of the lack of SSE2, which a Pentium 4 would have.
Lack of SSE2 wasn't a problem until around 2015. At that time I had to move on and get a dual core machine.
|
|
|
|
Post by ylee on Aug 18, 2021 17:27:27 GMT
There is much to digest in this thread, but first of all much thanks to nuihc88 for his detailed analysis and thoughtful comments  I have been researching custom kernels like Zen/Liquorix & XanMod and how to best compile them for past few months in hopes of improving the energy efficiency and responsiveness of my Asus eeePC 1005HA-H while also adding PHC-Intel module for undervolting the CPU, backporting iwlwifi for adding support for a intel AX200 WiFi+BT card and making the special ACPI keys work correctly via acpi-eeepc. Saw this thread and thought i might as well share my research up to now in case it helps with improving future versions of one of the few remaining 32bit distros out there... With a BETA release of a 32 bit Debian Bullseye version of Bodhi Linux 6.0 recently out. It is using the 5.10 kernel (linux-image-5.10.0-8-686) because that is what is available in Bullseye repos. My interest with testing this ISO is more with the installer than the kernel. I know the 5.10 kernel WILL be problematic for some hardware, mine included  Here's link to a post listing lots of extra reasons to avoid switching to 5.x kernels: Link... Based on all the driver/module/firmware bugs reported, i suspect that maintaining 32bit compatibility in 5.x would turn out to be much harder and more time consuming in the long run than occasionally patching a 4.20 kernel. Since most of the mitigations themselves have already been backported to 4.x kernels without widespread reports of the same hardware issues, i suspect it's some hastily made structural optimizations for post-Spectre/Meltdown hardware that are breaking support for old hardware in 5.x kernels and i would expect those kinds of optimizations to also lead to worse performance and more overhead on older and especially 32bit hardware. Ideally BL6 legacy should include a 4.19 or 4.20 kernel. I do not know of any Debian 11 based 32 bit Distro that does so at this point. This makes it rather problematic for us, as it forces us to compile and package it ourselves. I can take the 4.19 kernel out of the Buster based 32 bit distros using it (LXDM or BunsenLabs Linux) and install that on the BL6-legacy system/ISO. That appears to work but I only briefly tested. However, I need more than just the single package for full support. For example, there may be occasions where you may need the header files. But looking at LXDM I think we would need something like the following deb files: - linux-compiler-gcc-8-x86_4.19.194-3_i386.deb
- linux-headers-4.19.0-16-686_4.19.181-1_i386.deb
- linux-headers-4.19.0-16-common_4.19.181-1_all.deb
- linux-image-4.19.0-16-686_4.19.181-1_i386.deb
- linux-kbuild-4.19_4.19.181-1_i386.deb
- linux-libc-dev_4.19.194-3_i386.deb
If we used the 4.20 kernel, it would be the same set of packages but with updated version numbers. These are the 4.19 kernel version and these packages seem to have originally came from debian Buster repos. As packaged they will not all install on Bullseye: dpkg: dependency problems prevent configuration of linux-compiler-gcc-8-x86:
linux-compiler-gcc-8-x86 depends on gcc-8 (>= 8-20180123-1~); however:
Package gcc-8 is not installed.
dpkg: error processing package linux-compiler-gcc-8-x86 (--install):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-headers-4.19.0-16-686:
linux-headers-4.19.0-16-686 depends on linux-compiler-gcc-8-x86; however:
Package linux-compiler-gcc-8-x86 is not configured yet.
dpkg: error processing package linux-headers-4.19.0-16-686 (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-compiler-gcc-8-x86
linux-headers-4.19.0-16-686I have never been comfortable with taking a package from one version of Debian or Ubuntu and dumping it as is into a more recent version. That can be problematic in some cases. Ideally then we would have to package either the 4.19 or 4.20 kernel ourselves: ... I suppose if i were to build a kernel meant to closely resemble an official ubuntu/debian release, i would use 4.19; however if i were to build an optimized custom kernel, i would use 4.20 (XanMod) as base and apply patches from 4.19 LTS. In summary: 4.19 would likely be better for security and maybe stability due to being LTS, but 4.20 would be better for energy efficiency, performance and hardware support, depending of course on how much has been backported to 4.19. The idea of using a XanMod based custom built kernel seems pretty interesting and maybe even a great idea. It would certainly make BL6 unique among the few distros still supporting 32 bit machines: I guess it might also be worth mentioning that on a XanMod based custom built kernel using the tweaks mentioned above, i am getting no menu-load delays with icons enabled, everything just feels way smoother in general and CPU temperatures are lower too. I don't really know how much of that is due to the tweaks and how much is from XanMod, but it does seem like something worth exploring further. (Due to my inexperience with compiling kernels i keep running into various problems with compiling and loading modules though, probably due to some misconfiguration on my end.) However this is also the MAIN issue with using a 4.19 or 4.20 kernel, XanMod or otherwise: " Due to my inexperience with compiling kernels i keep running into various problems..." I also don't have much experience with compiling kernels and NONE with packaging them. So nuihc88 have you gotten any better at this and do you wish to help with trying to package this for BL6-Legacy? |
|
enigma9o7
Crew Member
Posts: 1,210
Likes: 1,213
|
Post by enigma9o7 on Aug 19, 2021 6:13:54 GMT
For experiment, I downloaded those 4.19 kernel packages and their dependencies from buster repos and installed them in a virtual machine on top of bl6 legacy beta. You can see the list of packages in the Note, lines at the beginning.
bodhi@legacy:~/kernel$ sudo apt install ./*.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'cpp-8' instead of './cpp-8_8.3.0-6_i386.deb'
Note, selecting 'gcc-8' instead of './gcc-8_8.3.0-6_i386.deb'
Note, selecting 'gcc-8-base' instead of './gcc-8-base_8.3.0-6_i386.deb'
Note, selecting 'libgcc-8-dev' instead of './libgcc-8-dev_8.3.0-6_i386.deb'
Note, selecting 'libisl19' instead of './libisl19_0.20-2_i386.deb'
Note, selecting 'libmpx2' instead of './libmpx2_8.3.0-6_i386.deb'
Note, selecting 'linux-compiler-gcc-8-x86' instead of './linux-compiler-gcc-8-x86_4.19.194-3_i386.deb'
Note, selecting 'linux-doc-4.19' instead of './linux-doc-4.19_4.19.194-3_all.deb'
Note, selecting 'linux-headers-4.19.0-16-686' instead of './linux-headers-4.19.0-16-686_4.19.181-1_i386.deb'
Note, selecting 'linux-headers-4.19.0-16-common' instead of './linux-headers-4.19.0-16-common_4.19.181-1_all.deb'
Note, selecting 'linux-image-4.19.0-16-686' instead of './linux-image-4.19.0-16-686_4.19.181-1_i386.deb'
Note, selecting 'linux-kbuild-4.19' instead of './linux-kbuild-4.19_4.19.194-3_i386.deb'
Note, selecting 'linux-libc-dev' instead of './linux-libc-dev_4.19.194-2_i386.deb'
The following packages were automatically installed and are no longer required:
libc-dev-bin libc-devtools libcrypt-dev libnsl-dev libtirpc-dev
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
libasan5
Suggested packages:
gcc-8-locales gcc-8-multilib gcc-8-doc libgcc1-dbg libgomp1-dbg libitm1-dbg
libatomic1-dbg libasan5-dbg liblsan0-dbg libtsan0-dbg libubsan1-dbg
libmpx2-dbg libquadmath0-dbg debian-kernel-handbook
Recommended packages:
libc6-dev
The following packages will be REMOVED:
build-essential g++ g++-10 libc6-dev libstdc++-10-dev
The following NEW packages will be installed:
cpp-8 gcc-8 gcc-8-base libasan5 libgcc-8-dev libisl19 libmpx2
linux-compiler-gcc-8-x86 linux-doc-4.19 linux-headers-4.19.0-16-686
linux-headers-4.19.0-16-common linux-image-4.19.0-16-686 linux-kbuild-4.19
The following packages will be DOWNGRADED:
linux-libc-dev
0 upgraded, 13 newly installed, 1 downgraded, 5 to remove and 0 not upgraded.
Need to get 402 kB/94.7 MB of archives.
After this operation, 282 MB of additional disk space will be used.
Do you want to continue? [Y/n]
<EDITED>
Generating grub configuration file ...
Found background: /etc/default/grub.d/backgrounds/grub.png
Found background image: /etc/default/grub.d/backgrounds/grub.png
Found linux image: /boot/vmlinuz-5.10.0-8-686
Found initrd image: /boot/initrd.img-5.10.0-8-686
Found linux image: /boot/vmlinuz-4.19.0-16-686
Found initrd image: /boot/initrd.img-4.19.0-16-686
done
Setting up libmpx2:i386 (8.3.0-6) ...
Setting up libisl19:i386 (0.20-2) ...
Setting up linux-headers-4.19.0-16-common (4.19.181-1) ...
Setting up cpp-8 (8.3.0-6) ...
Setting up libgcc-8-dev:i386 (8.3.0-6) ...
Setting up gcc-8 (8.3.0-6) ...
Setting up linux-compiler-gcc-8-x86 (4.19.194-3) ...
Setting up linux-headers-4.19.0-16-686 (4.19.181-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 4.19.0-16-686:.
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13) ...
N: Download is performed unsandboxed as root as file '/home/bodhi/kernel/gcc-8-base_8.3.0-6_i386.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
bodhi@legacy:~/kernel$
Note the packages being removed, I guess cuz they conflict with the older gcc.
It is downgrading linux-libc-dev because I installed the older package (which itself is not a dependency of the other packages). edit: and note that gets updated automatically when running sudo apt upgrade, so not sure about that, etc. just fyi.
It boots and works, but I think I understand why this is problematic. Since the older kernel package was compiled with older version of gcc, the header files package wants that version of gcc installed too. And installing that older version of gcc makes it remove the newer gcc that came with it. And for programmers, if you need libc6-dev you also would need the buster version and its dependencies, cuz installing the bullseye version will remove gcc-8 and the 4.19 header files. Now I see why its not so simple. I wonder if using kernel 4.9 for bodhi legacy 5.1 was easier for some reason...
HINT: If using VirtualBox to play with this, unless I "use host i/o cache" for sata controller as pictured, it takes an extremely long time to install kernel packages. This makes it fast.
|
|
