How to boot 902 in Lenovo S-12 netbook? (solved)

[wognath]

I am trying to rehabilitate an old netbook, a Lenovo S-12, details below. I used this computer for years with Fatdog 710 which still works great, but it is aging and I’m concerned about security, particularly the browser. Firefox 50.1 is currently installed.
902 (iso burned to a flash drive) boots as far as

Code: Select all

Loading base sfs from initrd
...
Using RAM as temporary storage  

At this point it shows a cursor but it is unresponsive. I tried nomodeset, nox, savefile=none with the same result. 814 stops at the same place.

Does someone have suggestions to make the boot succeed? Or update the browser without having to chase down 100 libs? Consider this a low-priority request: this computer has always been difficult, since 2010! Anyway, I'll eagerly try any suggestions

antiX is another candidate, but it has a similar problem: only older editions (4.something kernels) boot to a desktop. The ultimate plan for this laptop is to remove the hdd and have the OS on a flash drive. It will serve as a travel computer, so secure browser is essential.

Code: Select all

System: 
  Host: fatdog64 Kernel: 4.4.35 x86_64 (64 bit gcc: 4.8.3) 
  Desktop: Openbox 3.5.2   Distro: Fatdog64 Linux 710 Linux 4.4.35 [ arch]
Machine: System: LENOVO (portable) Product: 20021,2959 v: Lenovo Ideapad S12 
  Mobo: LENOVO model: MoutCook serial: <superuser required> 
  BIOS: LENOVO v: 20CN23WW date: 07/17/2009 
CPU: ingle Core VIA Nano U2250 ( Capable) [UP] speed: 800 MHz 
Graphics:  Card: VIA VX800/VX820 Chrome 9 HC3 Integrated Graphics 
	bus-ID: 00:01.0
	Display: server: X.org 1.20.11 driver: loaded: openchrome (unloaded: fbdev,vesa)
Network: Card-1 Broadcom NetLink BCM5906M Fast Ethernet PCI Express 
    driver: tg3 v: kernel port: N/A bus-ID: 01:00.0
  Card-2: Broadcom BCM4312 802.11b/g LP-PHY driver: wl v: kernel
    bus-ID: 02:00.0

[Clarity]

Hello @wognath.

Questions

• How much RAM does the laptop have?

• I see you plan to remove the system drive...Why?

Removable media: It is well known that USB and SDcards are problematic as a system drive replacement. DVD is more reliable and consistent and is an option. My tiny DVDs are 1.4GB storage which is more than enough, for me, for system use and some personal storage.

Browsers: Most, if not all, of today's are secure. Or you can run either TAILS or TOR.

[jamesbond]

New kernels bring new features and devices for ... well, new machines, unfortunately; and then they drop support for older hardware (or introduce bugs). I have a machine like yours, a laptop from 2012, which was previously running 800, and when I updated it to 900, I could no longer control the brightness. The only solution was to use an older kernel.

The 900 series is built to be able to support older kernels (all the way down to 3.2.x line), so in theory, you can take that 4.4.35 kernel from 710 and run it with 902. It's not a guarantee that it will work (considering the amount of stuff they changed in Xorg) , but it's something worth trying. If it does work, then what we can do is to build the closest 4.x LTS kernel, that would be 4.19.318 (as of today).

[wognath]

Thanks for the replies.
@Clarity
The computer has 3GB of ram.

I see you plan to remove the system drive...Why?

Because it will be a travel computer which might get lost. With only a 16GB flash drive and save on encrypted partition, I wouldn't have to worry about data. The HDD is years in use, multiple partitions, too tedious to sanitize it. No dvd drive. Tails is more than I need, and it would probably be very slow on this computer.

@jamesbond

...in theory, you can take that 4.4.35 kernel from 710 and run it with 902

I found the instructions in faqs. I have kernel 4.4.35 running in 814. There are some minor(?) glitches to work out. I'll try the same with 902. This is great fun, thanks!

[p310don]

How long have you left it to boot?

What is your bootloader?

It sounds like you might have a slow bootloader due to the huge initrd. Have you tried the initrd-nano?

On some of my older machines, boot hangs at about the same spot, and then can take five to fifteen minutes for anything to happen. Changing your boot to include initrd-nano gives normal boot speed.

kernel /fd9/vmlinuz mergeinitrd1=local:/fd9/initrd
initrd /fd9/initrd-nano

That's my boot stanza from grub4dos which speeds up the boot time.

[wognath]

Hello p310don,
You're right, the humongous initrd is super slow. I'm using the mini initrd (fd64.sfs moved outside of initrd). The nano initrd freezes: "You can only use this initrd if ... your hardware is supported by the kernel without any additional modules." (from the faqs) When the boot hangs, I wait a while for a desktop, but not 15 minutes!

My bootloader is syslinux:

Code: Select all

label fatdog
linux vmlinuz-4.4.35
initrd initrd-4.4.35
append rootfstype=ramfs waitdev=2 basesfs=uuid:###:/boot/fd64.sfs savefile=ram:uuid:###:/FDsave:dmcrypt
menu label Fatdog 814 with 4.4.35 kernel 

[wognath]

Update and another question
The 800 and 900 series with 4.4.35 kernel boot on this computer. mini-initrd greatly speeds up boot.
Fatdog 902 xorg 21.1.11, cannot set screen to native resolution, looks ragged. No openchrome driver?
Fatdog 813 xorg 1.20.14 uses 1280x800, looks great

I really like the 813 system + latest firefox. A major use of this computer is for reading, often at night, so I would like to use sct, but redshift, sct, xrandr and xgamma have no effect. Screen brightness controls work perfectly. All work as expected in FD710 with the same kernel and xorg 1.18. gslapt allows to downgrade xorg to 1.19, but still xrandr doesn't work. I tried Gamma "1 1 0.1" in /etc/X11/xorg.conf.d/20-gpudriver.conf, but then X does not start. In the light of jamesbond's comments above, I suppose that this 2009 machine has been left behind by the kernel and xorg. I have tinkered with this a lot; maybe I'll just get myself yellow glasses but if someone has an idea to try, I would appreciate it.

Edit: firelux extension along with a dark theme in firefox will do the job for nightime reading, but sct would be much better.

[jamesbond]

Ok, here's some suggestions: if you look at http://distro.ibiblio.org/fatdog/kernels/800/, there are a few kernels there. Do you mind trying with 4.19.x kernel, anyone of them, and see if the laptop behaves?

The reason is, 4.19.x kernel is the oldest one still maintained. So if you can get the older 4.19.x kernel to work, we may be able to build the most recent version of it.

Also, for openchrome, yes I didn't build it for 900, because I thought nobody uses it anymore. Turns out that you do I've just built it and push it to the gslapt repo (for 900), and it will be included in the next release.

The xrandr and gamma correction is purely kernel stuff, though, so I'm not sure how much help I can provide.

cheers!

[wognath]

Hello jamesbond,
Thank you for making the openchrome driver. I have 902 running with 4.19.92 kernel. It boots to 1280x768 resolution. The menu bar is offscreen, but I can scroll to it. I installed the openchrome package, ran xorgwizard, typed custom resolution 1280x800. But now xinit reports "Connection refused"; xwin fails on reboot (unless savefile=none) and xorgwizard/auto goes directly to the "Click YES if the screen is working" message. I also tried xrandr --newmode but it says "Failed to get size of gamma for output default"

902 may unfortunately be a step too far for this old computer. Besides the display, it takes noticeably longer to boot. I really appreciate your building the driver though I wasn't able to figure out how to get it working. 813 with 4.19.92 kernel works great. Please don't take your time to build me a kernel, I'll try to learn about that . Wish me luck.

Thanks again.

[jamesbond]

No worries. The latest version of the openchrome driver is from 2016; there isn't any newer version, while Xorg (while development has slowed down) is still being updated. So yeah, it may have been left behind unfortunately

I haven't updated the 800/810 packages for about 1.5 years now, but a few weeks ago I did push an update to 800/810 repo, to open openssh, which had a nasty bug (CVE 2024-6387). Some software still compiles under the 800 base, though many newer ones probably doesn't. But it really depends. I've got PCSX2 emulator compiled in 810, but not in 900; so if I want to play PS2 games in 900 I need to use PCSX2 appimage, while in 810 I can use the self-built version.

As for the kernel build, let me know if you get stuck. Happy to lend a hand.

[wognath]

The lenovo S12 ideapad is working very well with fatdog 813, syslinux boot, 4.19.92 kernel, mini-initrd, encrypted save partition, on a 16GB flash drive. AntiX's live flash drive setup is great, but I like this one more.

jamesbond, regarding the kernel build, thanks for the offer of help, and thanks for not saying "when you get stuck".

my best advice is to download one of the many Fatdog kernel source SFS-es (aptly named as kernel-source-xxx.sfs). Get it, load the SFS, go to /usr/src/linux-XXX and then try to compile it...We only want to try to build it at this time; we can cover the installation process later.

I got that far, and now I'm stuck. Have you described that installation process somewhere? If not, I'll take some more time to read and mess around, then start another thread to ask about it.

[dr__Dan]

@wognath, I'm out of my knowledge base, but have you looked at the Fatdog64 help files pertaining to kernels and kernel modules? They suggest that they are what you are looking for.

Dan

[jamesbond]

@dr__Dan, there is no documentation like this in Fatdog's help so far, because nobody ever asked for it. We're slow and lazy, and only write stuff when people ask for it

@wognath, here are the next steps.

What you want to create in the end is:
A. vmlinuz (the kernel)
B. kernel-modules.sfs (containing kernel modules, firmware, and a few other tools).

(A) is easy. Just run make bzImage (or any of its variants like make -j4 bzImage), and you will find this file: arch/x86/boot/bzImage. That "bzImage" is actually vmlinuz. All you need to do is rename it (from bzImage to vmlinuz).

(B) is a bit more complicated. Roughly speaking, the process is like this:
1. Collecting all the kernel modules.
2. Generating the modules dependency order.
3. Collecting the related firmware.
4. Building additional aufs tools (optional)
5. Building external kernel modules (modules which aren't included with the kernel source, e.g. the "wl" broadcom drivers, and many other Realtek-chip based wifis, etc). (also optional)
6. Making an SFS out of it.

(4) and (5) are optional, so we'll skip it for now. We'll focus on 1 - 3, and then 6.

(1). You can do this by running make modules_install INSTALL_MOD_PATH=modules
By doing this, you're installing the modules in a directory named "modules" under the kernel source. You can of course point it elsewhere, e.g. INSTALL_MOD_PATH=/path/to/somewhere, it's really up to you. But whatever directory you choose, you have to remember it, because you will have to use the same directory. For simplicity, it's best to stick with the example.

(2). This is done by running the command depmod -a -b "modules" KERNEL_VERSION where KERNEL_VERSION represents the kernel of the version you're building (e.g. 4.19.5, etc), while "modules" is the directory where you installed the modules in step (1) above.

If you forget to do this, the kernel wouldn't be able to load any kernel modules later.

(3). Now, this step is a bit of an art. There is no way to know exactly what firmware are used by the kernel. There are some hints and rule of thumbs - but they are just that, hints. As in, they don't always work. So I will leave them for later.

Instead, the best way to collect the firmware, is to use an existing collection. Get it from existing kernel-modules.sfs whose version is closest to the kernel version that you're building.

Firmware usage normally stays the same for all kernel series, e.g. almost all of 4.19.x kernels will use the same collection, so you can use the same firmware as the one you can find on an existing kernel-modules.sfs for 4.19.x kernels. If you can't find 4.19.x collection, then you can try 4.18.x or 4.17.x or even 5.0.x or 5.1.x.

Once you find this, copy the lib/firmware directory inside the SFS you find, to module/lib/firmware in your module directory (where again, "module" represents the path, so if in step (1) you decided to put it to /path/to/somewhere, the firmware path would be in /path/to/somewhere/lib/firmware).

If later it turns out that you're missing some firmware, you can always add them manually, and re-generate the kernel-modules.sfs - which is the next and final step.

(6). Finally, you can now generate the kernel-modules.sfs by running dir2sfs modules. This will create modules.sfs, which you can rename to kernel-modules.sfs. If you're in system where "dir2sfs" command doesn't exist, you can do it by using mksquashfs directly: mksquashfs modules kernel-modules.sfs -noappend -comp xz.

That's it!

There is one step which I purposely omit: that's the kernel signing step. This is only necessary if you want the kernel to run with secure boot and UEFI. If you're building only for BIOS systems, or for UEFI without secure boot, you don't need to care about this.

PS: All the commands I give above, is to be run from inside the kernel build directory.

Good luck.

[wognath]

dr_Dan: The devs provide many kernels and make it easy to swap them, so it is not surprising that this is not a faq. My system works well with series 4 kernels, but fails with series 5 and 6. I assume there will be some small security benefit to using the latest v. 4 kernel if I can pull it off, but I'm mainly doing this for learning. So far I have learned that it's harder than I expected.

jamesbond: Once again, thank you for generously taking time to provide such a detailed explanation. It is safe to say that I was a loooong way from figuring it out on my own

[jamesbond]

@wognath No worries. Don't be discouraged. I'm posting here how to compile 4.19.319 from scratch. No tricks needed. Just plain simple instructions that anyone can follow.

This is a working example. I actually build this kernel using the steps I write below, and I use it to run Fatdog 900 (in a real machine, not qemu).

xscreenshot-20240817T011808.png (40.47 KiB) Viewed 1111 times

Preparations

1. The most important step of the process: Obtain the known-good kernel configuration file from the kernel version nearest to the one that you want to build.

The kernel configuration file is known as .config file, or in Puppy's terms, the DOTconfig. In Fatdog, this file can be obtained in two ways:
a) from the running kernel, by running the command zcat /proc/config.gz > DOTconfig
b) from kernel-source-X.Y.Z.sfs; this file is located in /usr/src/linux-X.Y.Z/.config

Many kernel builders in the forum also generously provide their DOTconfigs when they announce their new kernel builds as well.

For this example I will take the .config from kernel-source-4.19.92.sfs (from here: http://distro.ibiblio.org/fatdog/sfs/800/)

2. Obtain the known-good firmware collection for a kernel version which is nearest to the one that you're building.

This is normally located in kernel-modules.sfs, located in /lib/firmware. If you're being lazy, then just download one of the tarballs from here: https://git.kernel.org/pub/scm/linux/ke ... rmware.git, but that file will be huge (linux-firmware-20240811.tar.gz is 555 MB) as it will include firmware from all kernel versions back to version 2.6 onwards. The point of using existing firmware collection is to include only the firmware that you need, to make the size smaller.

For this example I will use the firmware from kernel-modules.sfs-4.19.92 (from here: http://distro.ibiblio.org/fatdog/kernels/800/)

3. Have a Linux partition ready. Building kernel requires a lot of space which probably won't fit into your RAM, or your savefile/savefolder, so do it in an external Linux partition.

For this example, I will use /mnt/sdc1 as the location (/mnt/sdc1 is the mountpoint of /dev/sdc1, which is my external USB drive containing an ext4 partition).

For the rest of the steps, I will show you the commands, one line at a time, and leave out the commentary except when it is absolutely necessary (comments are prefixed by #).

Let's do it!

Code: Select all

cd /mnt/sdc1

# get and unpack kernel sources
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.319.tar.xz
tar -xvf linux-4.19.319.tar.xz
cd linux-4.19.319

# get aufs and apply aufs patches
git clone https://github.com/sfjro/aufs4-standalone
cd aufs4-standalone 
git checkout aufs4.19.63+
cp -r Documentation/ fs/ ..
cp include/uapi/linux/aufs_type.h ../include/uapi/linux/
cd ..
patch -Np1 -i aufs4-standalone/aufs4-kbuild.patch
patch -Np1 -i aufs4-standalone/aufs4-base.patch
patch -Np1 -i aufs4-standalone/aufs4-mmap.patch
patch -Np1 -i aufs4-standalone/aufs4-loopback.patch
patch -Np1 -i aufs4-standalone/vfs-ino.patch
patch -Np1 -i aufs4-standalone/tmpfs-idr.patch
patch -Np1 -i aufs4-standalone/proc_mounts.patch

# get .config
mount /path/to/kernel-source-4.19.92.sfs /mnt/data
cp /mnt/data/usr/src/linux-4.19.92/.config .config
umount /mnt/data

# apply .config
yes "" | make oldconfig
# if you want to, you can adjust your kernel configuration by running:
# make menuconfig

# go for coffee
make -j4 bzImage modules

# install and prepare modules
make modules_install INSTALL_MOD_PATH=modules
depmod -a -b modules 4.19.319

# create kernel-source links for dkms
ln -s /usr/src/linux-4.19.319 modules/lib/modules/4.19.319/build
ln -s /usr/src/linux-4.19.319 modules/lib/modules/4.19.319/source

# copy firmware
mkdir -p modules/lib/firmware
mount /path/to/kernel-modules.sfs-4.19.92 /mnt/data
cp -a /mnt/data/lib/firmware/* modules/lib/firmware
umount /mnt/data

# package kernel-modules.sfs and vmlinuz
mksquashfs modules kernel-modules.sfs -noappend -comp xz
cp arch/x86/boot/bzImage vmlinuz

Your vmlinuz and kernel-modules.sfs will be in your kernel build directory.
In this example, it will be in /mnt/sdc1/linux-4.19.319.

[wognath]

I'm using Fatdog with the 4.19.320 kernel (thanks to jamesbond's instructions in the previous post) on my 2009 S12 netbook. I used localmodconfig https://docs.kernel.org/admin-guide/qui ... linux.html because otherwise the compilation takes 10 hours.

I read somewhere that the broadcom wifi driver wl.ko is "kernel agnostic", but it isn't. I have to compile it for each new kernel. viewtopic.php?p=10959#p10959

Regarding the color temperature issue, sct, redshift, xgamma have no effect in FD813 (xorg 1.20.14) or FD721 (xorg 1.19.5) but they work in FD710 (xorg 1.18.3), in all cases with the 4.19.320 kernel. (On another computer they work ok) As I said above, the display doesn't work properly with FD90x nor with series 5 and 6 kernels. I haven't quite decided whether to use 813 or 710. The latest firefox works in both. Are there any serious security concerns with the older software in FD710?

Thanks again, jamesbond, for your help with this interesting experience! I'm happy to see that you've added your guide to the faqs.

[jamesbond]

I'm using Fatdog with the 4.19.320 kernel (thanks to jamesbond's instructions in the previous post) on my 2009 S12 netbook. I used localmodconfig https://docs.kernel.org/admin-guide/qui ... linux.html because otherwise the compilation takes 10 hours.

Building kernel in a slow system will definitely take time, but if your system takes up to 10 hours ... It is probably because your system doesn't have enough RAM? It was probably swapping in and out as it was building the kernel.

I read somewhere that the broadcom wifi driver wl.ko is "kernel agnostic", but it isn't. I have to compile it for each new kernel.

The word "kernel-agnostic" means different things for different people. With "wl", it means that you can use the same "wl source" to compile it with many different kernel versions. It certainly does not mean (as you realise it) that you can compile it once and use it for all different kernel versions. Would be a dream if it could

This is not unique to "wl". NVIDIA driver is actually kinda similar too.

Are there any serious security concerns with the older software in FD710?

See PM.

Thanks again, jamesbond, for your help with this interesting experience! I'm happy to see that you've added your guide to the faqs.

You're much welcome. I decided to add it to the FAQ, because I thought, since I've already spent the effort, I might as well keep it in location that won't easily get buried with time, like the forum post.