EZSCNF adventure - my setup

[fatdoguser]

... follow along (at your own risk) if you like. Encouraged/prompted by https://www.forum.puppylinux.com/viewto ... 67#p107967 I've opted to post/share my setup.

I use Fatdog as a build system. Tracking https://kernel.org/category/releases.html 6.6 (EOL Dec 2026), 6.6.10 my most recent build

Build script (using Fatdog 901 and its devx sfs as the 'build system') https://distro.ibiblio.org/fatdog/sfs/900/

Code: Select all

K=6.6.10

wget http://kernel.org/pub/linux/kernel/v6.x/linux-${K}.tar.xz
mkdir bootfiles
tar -xvf linux-${K}.tar.xz

cd linux-${K}
cp ../DOTconfig .config

N=`nproc`
N=`expr $N + 1`

yes "" | make oldconfig

make menuconfig

yes "" | make -j$N
cp arch/x86/boot/bzImage ../bootfiles/vmlinuz
echo vmlinuz should now be ready in bootfiles folder

DOTconfig (.config for the Linux build) must be placed alongside the above build script. Mine (gz compressed to gzip -d DOTconfig.gz first). That's for my hardware, all firmware/modules built into the kernel (sometimes I even build the initrd into the kernel as well). But does build a vesa framebuffer based system which is generic. Sound, network (ethernet and wifi), keyboard, mouse, touchpad ...etc. all work for my hardware, may very well not work for your hardware. As part of the build the script drops into menuconfig (so make sure you run in a maximized terminal window). Mostly a matter of discovering what mouse/keyboard/sound ..etc. your hardware is and tweaking menuconfig accordingly (sysinfo is helpful). Once you exit menuconfig then the kernel compile kicks in. Takes < 10 mins on my i5, but over a hour on my (old) laptop.

DOTconfig.gz

(36.74 KiB) Downloaded 97 times

I'll upload/share a template of my initramfs once I've found somewhere to do that (maybe google drive, if it still permits such, I haven't used that for ages).

Basically builds around a 6MB vmlinuz, 8MB initramfs that alone is a base system which allows you to perform multiple popular tasks without the need to install additional software. ssh, vnc, sound, wifi and/or ethernet connect. A framebuffer based display where the vnc viewer permits you to connect to any vnc server, and where vnc is very common (phones, Windows, Linux ...etc.).

Boots in a second or two, and once booted more often I simply overlayfs mount a local fd64.sfs, chroot into that and start vncserver, and then framebuffer vnc connect to that. Being on the same box the vnc network overhead/speed is pretty much irrelevant. And you can vnc connect to multiple servers at the same time.

A feature is that as a main FD64.sfs (full gui desktop) is loaded via a overlayfs/chroot you can drop capabities within that, drop chroot and sys_admin for instance, so its like running X (and Fatdog root) as a restricted userid, so might as well run everything a root within that. And being so small, around 16MB to 20MB combined vmlinuz/initramfs, it boots very quickly.

What's with the EZSCNF name? Well it's along the lines of HAL (2001 Space Odyssey) pre characters of IBM, and NT being the subsequent characters to MS. EZSCNF are the pre-characters of FATDOG, and that has a somewhat 'easy' and 'config' ... ring to it.

[fatdoguser]

I run with 16 bit framebuffer color depth, boot with kernel switch vga=ask and select a vesa choice that has -16 at the end, 1366x768 16 for instance.

When booted to framebuffer you can for instance do cat /dev/random >/dev/fb0 ... and that will fill the screen with random colored pixels.

Each individual 16 bit (2 bytes) depth pixel color is formed using 5 blue bits, 5 red bits, 6 green bits. Green gets more as the eye naturally can distinguish between different colors of green.

Basic binary/hex from school days

Code: Select all

# green is the LSBs, then red, then blue (MSBs) so ...
# bits of BBBBBRRRRRGGGGGG
# has red 0000011111000000
# Hex        0   7   C   0
# x='\x07\xC0' # for red

# Blue    1111100000000000
#            F   8   0   0
# x='\xF8\x00' # for blue

# Green   0000000000111111
#            0   0   3   F
# x='\x00\x3F' # for green

So for a screen width of 1366, 12 pixel lines of red

x='\x07\xC0' # for red
x=$x$x # 2
x=$x$x # 4
x=$x$x # 8
FILL=$x
x=$x$x # 16
x=$x$x # 32
x=$x$x # 64
x=$x$x # 128
x=$x$x # 256
x=$x$x # 1024
x=$x$x # 2048
x=$x$x # 4096
x=$x$x # 8192
x=$x$x # 16384
x=$x$x # 32768 pixels, nearly 12 lines of red (12 x 1366 2 = 32784 bytes)
x=$x$FILL # pad out to full 32784 total bytes pixels

now we can display that to our 1366 wide, 16 color depth framebuffer using ... printf $x >/dev/fb0

Or use dd and with appropriate values for dd seek and size you can draw line(s) on whatever lines you like.

I used to have that as part of my low-battery warning indicator, a red (12 pixel height) bar at the top of screen popping up periodically whenever the battery level falls below a level I set. Now I have a image instead. Found a clip art type image of a battery, scaled that to being large/central with mostly black background, and made a raw image copy of that

dd if=/dev/fd0 of=battery.raw

Now when my battery is low I xor that with the current /dev/fb0 content and output that to /dev/fb0, so a transparent battery image becomes visible no matter whether I'm in a tty or within a gui desktop/chrome watching a youtube. That's the thing with framebuffer, it isn't locked, so multiple things can be writing to it at the same time. If for instance Im viewing a Fatdog desktop and chrome playing a video and I ctrl-alt-F3 to a tty then that video are 'bleeds' through, looks as though the video is playing within the terminal/cli. And its the same the other way around, I have a framebuffer battery and clock 'tray' sized 'widgets' that bleed through to the display when I'm in Fatdog.

With my setup - running Fatdog but as a headless system (overlayfs/chroot) where its display output is to vnc (vncserver), it still renders as though a normal desktop system, just that the output is being directed at vnc. So whilst vesa/framebuffer is 'slow', its still plenty quick enough to read/display vnc screens being thrown at it. And when that vnc server is on the same box there's no network lag/bottleneck either (well there is, but its high). It's also pretty generic, and has graphics from the get-go. Forget limited size Linux penguin splash screens, you can easily dd or cp a simgle or multiple raw image(s) to /dev/fb0

[fatdoguser]

vmlinuz-EZSCNF download link. 16MB filesize.

For menu.lst (assumihg grub4dos bootloader), add a item such as

Code: Select all

title EZSCNF
kernel /vmlinuz-EZSCNF vga=ask

or wherever you have stored the kernel file

During bootup it will prompt you to press Enter in order to select a resolution, enter the letter next to a vesa mode that you think may be appropriate but try and select a 16 bit depth choice, 1280x768x16 for instance. If the font is too large/small then there is a "font" command (script), "font 12n" for instance will switch to a 12 sized normal font, "font 12b" for bold, other choices are 14, 16, 18, 20, 22, 24, 28, 32, so "font 32b" for instance will set the largest font. See if "cat /dev/random >/dev/fb0" fills the screen with random colored pixels. To take a screenshot and dd if=/dev/fb0 of=snap.raw does the trick, you may want to add a sleep 10 before that, sleep 10; dd if=/dev/fb0 of=snap.raw To 'view' that snapshot just cat snap.raw >/dev/fb0

Is specific to my hardware, so the mouse, keyboard, "wifi", "eth0" commands, along with sound may very well not work. Should boot to a cli (framebuffer) desktop however as framebuffer/vesa is common. Once booted see if running "wifi" (or "eth0") network connects for you. Maybe "telnet endofthelinebbs.com" to test the internet connection (that BBS also has many fido/other netmail choices). If you tether your phone (usb cable that supports tethering) - that is already wifi net connected,then running "tether" on the laptop may secure a IP/link.

alsa sound, again works for me, because the scripts are configured for my setup, card 2. A recent change I've made in that respect is to include the SND_ALOOP=y kernel .config switch, along with swapping out /root/.asoundrc for James' suggested version, so now mixout is permanently available as a record sound choice (arecord -D mixout >recording.wav ... and ctrl-C to end the recording).

fbvnc, the framebuffer vnc viewer uses ctrl-spacebar to 'freeze' the display so that videos wont bleed through when you ctrl-alt-Fn to a different tty, or if you like seeing the video bleed through then just ctrl-alt-Fn without toggling fbvnc screen updates off. ctrl-alt-x quits fbvnc. To connect to a vnc server its fbvnc <ip> <port>, so for instance if you have another box running vncserver at 192.168.1.10 on port 5901 you'd run
fbvnc 192.168.1.10 5901
to connect to that.

If you point fd64sfsload to your own copy of fd64.sfs, then its best if you have tigervnc installed into that fatdog. The script should then connect to that and start vncserver running within that after its established the overlayfs

Generally the concept is a small system that is enough to do many things without having to install additional software. wifi/ethernet connect, telnet, ssh, vnc, vi editor, cli as file manager. When you can also fire up a full fd64 (Fatdog gui desktop) and vnc into that so more the better.

As is /usr/local/bin/fd64sfsload is set to where I store my main fd64.sfs, that it overlayfs mounts and starts vnc server within that, so the framebuffer can vnc viewer (fbvnc) into that for a full gui desktop.

The initramfs is built into that kernel (along with all firmware/modules for my hardware). If you add a initrd=... usual menu.lst in addition to the kernel=... line, then that external initrd will take precedence over the internal version.

It's a minimal desktop system, so /bin is just busybox, and I've combined /usr/bin, usr/sbin ...etc. as have all libs be combined. /usr/local/bin is where I keep scripts, /usr/bin is where all of the binaries are, nearly all of bin's and lib's are directly copied out of Fatdog, so you could compile those yourself as per normal Fatdog compiles. A couple/few exceptions, fbbattery, fbclock, xor, fbvnc are outside of that, where the source code for those is under the /src folder. A battery low indicator flashes up once the battery level declines to below 40%, when a 'transparent' image is copied to the framebuffer (using xor), again those calculations are set according to my own particular hardware, yours may very well differ. That will also affect the 'tray' (top right of screen) battery level indicator (immediately to the left of the clock) - where that battery 'widget also changes color according to whether your mains connected or not. For a PC the battery widget wont be shown.

[fatdoguser]

Fundamentally we have ...

overlayfs with fd64.sfs on top of the main mini-boot system
a upper folder where all changes are stored
a initially empty work folder that overlayfs uses for moving files (has to be on the same filesystem)
The top merged layer

As real root we chroot into that, dropping chroot and sys_admin capabilities. Within that it runs fd64.sfs (the main/full Fatdog) as though it was a headless system, where it feeds out its display to vnc (vncserver).

Within the same system we then use framebuffer vnc viewer to connect to that vnc service.

So Fatdogs X is running as root, but a root that has no chroot or sys_admin capabilities. Similar to as though X was actually running as a regular userid.

The layering also means that any changes are stored in ram (upper overlayfs folder), that are lost at shutdown. Real root however can access those folders to copy in/out files/folders, so changes could be recorded/preserved (and restored at reboot). As-is however and that's functionality that's not currently present in the EZSCNF I posted earlier, even the base (real root) system runs in ram, no changes preserved.

Note that dropping sys_adm capability also means that you can't even mount sda2 (whatever) from within that chroot environment, so your data files are secure. To be able to edit files and record them back to sda2 you have to migrate them in, edit them as desired, and then migrate them back out again. Again as-is that is all a manual process. Obviously extending the code could automate much of that.

When our main display is a framebuffer/vnc viewer, then given the commonality of vnc servers across many OS's its trivial to connect to/use such gui's.

[fatdoguser]

I have grub4dos bootloader and its associated menu.lst installed on a usb stick.

Adding EZSCNF to that with a vga=ask kernel boot switch and booting that on a i5/nvidia desktop box (distinctly different to my AMD/Radeon laptop) and initially pressing F12 to bring up the bios boot choices, selecting my sandisk usb stick as the boot device and then pressing Enter when prompted by vga=ask during the boot process, and that indicated 'w' as the 1920x1060x16 resolution choice. That booted to graphical vesa cli as expected. cat /dev/random >/dev/fb0 and the screen filled with random color pixels.

Also as expected there was no sound

Code: Select all

aplay /dev/random

and silence.

Edited /root/.asoundrc and changed the bottom and top lines to use card 1 instead of card 2. Ran

Code: Select all

alsactl restore

and then

Code: Select all

aplay /dev/random

again and white noise was hear ok. Quickly used ctrl-C to exit out of that.

Next I ran

Code: Select all

eth0

and a IP was obtained (the desktop has no wifi, hence I ran 'eth0' instead of 'wifi')

That desktop also has Fatdog available, and in the same location, on sda2 in a sub folder called FATDOG901-FINAL, the same as on my laptop. So there was no need to edit /usr/local/bin/fd64sfsload, so I ran that script, and up popped the Fatdog gui desktop. The USB Mouse worked (my laptop has a touchpad) so I opened a terminal window and found that I first needed to run

Code: Select all

. /etc/profile

before running

Code: Select all

seamonkey

in order to get seamonkey to start. I navigated to a youtube within seamonkey and that looked/sounded OK.

The screen however wasn't sized to 1920x1080, so in the terminal I ran

Code: Select all

xrandr --output VNC-0 --mode 1920x1080

which reset the resolution, but also has the effect of dropping the vnc connection, so I had to run

Code: Select all

fbvnc localhost 5901

to reconnect again.

With the youtube playing and set to full-screen, I also opened bmon and dragged that down to the bottom of the screen so that just the top few lines that show data rates were visible - the screen otherwise being filled with the video, I was somewhat surprised to see lo running at around 60MB/sec (so that's 480 Mbs). But that's largely irrelevant, as that data is within the same bus/system, internal. Both video and audio quality were good (I adjusted the youtube video to 1080p using the cog wheel option at the bottom right of the youtube video).

I had hoped that it would be relatively easy to use that 16MB EZSCNF on other systems without too much problems, which it so seems.

Note that in the above seamonkey was run as root, not seamonkey-spot - which didn't work, the FD64 overlayfs mount as-is doesn't like running things as spot. However also note that fd64sfsload invokes /v as a chroot action, and in that script we drop chroot and sys_admin capabilities as part of the chroot, so root within that chroot is significantly restricted, as-is seamonkey and everything else running under that, including X.

I've posted this walk-through as its likely the same/similar process that would be involved on other hardware. Much of that could be scripted in a generic manner (auto detect/adjust). Another choice might be to store fd64.sfs on the usb stick and point to/use that instead. It's only being accessed for read only so wouldn't unduly shorten the life of the usb stick. Similar/same as Barry's EasyOS.

sfs load/unload issues (aufs) are inclined to become more of a thing of the past as we transition to where full OS's or App Images, that contain near or actual full systems (all required libs etc.) become more common. It can be near as quick to load/unload a kvm/qemu of a full system/OS as loading/unloading a sfs. As are other filesystems such as BTRFS/ZFS becoming more commonplace and refined, where dynamic loading/unloading volumes are a integral part of the integral filesystem.

[fatdoguser]

On my regular (standard) Fatdog boot, open a terminal and run glxgears and I get 60fps.

With EZSCNF ... I get 260fps

I suspect that free of a actual display (lcd screen) that tend to be slower to actually write to, to instead be writing to vnc (vnc server) ... direct memory, that glxgears runs much quicker (over 4 times quicker).

Our vesa framebuffer is naturally relatively slow, I don't have a actual measure of the rate, but it looks OK. Framebuffer vnc viewer just reads in pixels data and drops them onto the display as fast as it can/does, but at least that pixel data stream is at a fast/high resolution rate.

As a rough estimate I took the 60MB/second rate that the 1920x1080x16 was transferring data at, With 2 bytes per pixel that works out to around a 15 fps rate. But that was on a faster i5 box. I arrive at around a similar 15fps figure for my slower laptop (lower resolution), around 30MB peak data rate, 1366x768x16 resolution.

So yes, vesa/framebuffer can be a bottleneck for higher end graphics, but for more regular usage, browsing/editing documents, 15fps, at least to me, is fine.

Which brings to mind ... parallelism. With 8 cores all just reading vnc/pixel data in, each core individually dumping that to the framebuffer, each just looking after 1/8th of the screen, then conceptually at least that vesa rate could be scaled 8 fold to 120 fps. Twice as fast as a regular/normal Fatdog boot. Pretty sure however its not as clear-cut/simple as that (nothing particular in mind - just expectant of some barrier/issue that my limited knowledge is missing).

[fatdoguser]

Booted my configured (reformed fd64.sfs with all changes) Fatdog desktop
Control-Panel, Display, Choose Graphics Driver, and selected/set options for 1366x768 (my laptops res), 16 bit depth. Saved that (creates a new xorg.conf), tried to restart X but it failed. No matter, I still saved that into a newly created fd64.sfs with that change.

Booting (a variant of) EZSCNF, vga=ask boot parameter, selecting 1366x768x16, and in cli overlayfs mounting and chrooting into that modified fd64.sfs (cli) to start Xvnc (vnc server) with -depth 16, and using a framebuffer vnc (16 bit depth vnc viewer) to vnc into that, and the Fatdog gui desktop displayed as normal. The vnc's server log confirms that both the server and the connected vnc client are both set to/running at 16 bit depth.

16 bit depth rgb 565 is one byte less per pixel than regular 888 rgb. Which for 1366x768 pixels per frame, and even a low 10 frames per second = 10MB/second less data to be conveyed/processed. General color quality is still OK/good, usable. Test videos played in chrome/youtube such as nvidia's test video see much less stalling, hardly any (whereas before at higher resolutions the spinning arrow was a relatively frequent occurrence). However I'm still seeing around the same fps rate, 260 fps being reported when glxgears is run. Far fewer dropped frames reported however. I wasn't sure whether the framerate would have been increased, or data/cpu reduced, turns out it looks more a case of the latter (even though I was hoping for a 50% increase in frame rate).

Fatdog running in a vesa framebuffer at 16 bit depth so far has been perfectly comfortable, no real noticeable difference to if I booted Fatdog as per a standard boot. It's also comforting to boot Fatdog/X via a chroot with chroot and sys_admin capabilities dropped, can't mount my HDD data drives (or access them even if mounted outside of the chroot).

I did also try overlayfs mounting Bionic Pup's sfs concurrently, the method I'm using is to sym link the .sfs into /tmp and mounting that - as the lower layer of the overlayfs, which works well running only uses ram for whatever files are actually used/cached. However there was incompatibilities between Bionic libs and the internal Xvnc within EZSCNF, so X (Xvnc) didn't start, but I could still run cli things such as htop.

EZSCNF being so small (16MB) boots very quickly, and sym linking/overlayfs mounting is also very quick. The initial chrrot and start up of the desktop is ... much the same as usual, as initially its still pulling in files into cache. Collectively overall boots quicker than regular Fatdog.

[jamesbond]

@fatdoguser, exciting stuff! Please keep them coming!

Just a note of testing with glxgears: on modern systems, glxgears syncs to the video refresh rate, so you almost always get 60fps (or close to it, on real hardware). To test the max rendering rate using glxgears, you must tell it to not bother with sync-ing: vblank_mode=0 glxgears.

[fatdoguser]

@fatdoguser, exciting stuff! Please keep them coming!

Just a note of testing with glxgears: on modern systems, glxgears syncs to the video refresh rate, so you almost always get 60fps (or close to it, on real hardware). To test the max rendering rate using glxgears, you must tell it to not bother with sync-ing: vblank_mode=0 glxgears.

Good to know thanks @jamesbond

So far I've only run a single quick test with that and noted that with no FrameRate limit defined compared to if the FrameRate was set to 16 maximum fps only yielded a 10% higher glxgears framerate report. That was at 16 bit color depth in both cases, I imagine that would be further improved relative to if I'd booted vga=ask with a 1366x768x32 choice instead of a 1366x768x16 choice. Out of interest I tried another run setting a 1 frame per second maximum rate, and watching a youtube video with that obviously is like a picture by picture type look, which under extreme low bandwidth conditions could be a better than nothing choice.

A core 6.6 kernel/initramfs of just a vesafb boot, ssl/ssh, alsa, and framebuffer vnc that can net connect for me compiles in a little over 5 minutes, with all modules/firmware built in. You can build the initramfs into that so you can boot with just the vmlinuz vga=ask .. alone. Or if you specify a initrd along with that it will use that instead of the internal initramfs.

Boots very quickly, and I've now set that to mount a partition, sym link fd64.sfs, overlayfs that and chroot with chroot/sys_admin capabilities dropped. Where the fd64.sfs is set to use Xvnc instead of X - serve the display via vnc. kvm/qemu's or ssh into a server that provides vnc server access are alternatives.

Xvsa caters for running at 16 bit color depth, so you end up with X running in the framebuffer, where the color depth and (if using tigervnc's vncserver) frames per second rate can be selectively set. Despite being vesafb based for general browing/use it works very well, is as responsive as a regular X boot, but is portable (a common vmlinuz booting to simple framebuffer pretty much boots on anything, Intel, AMD, Nvidia.

You also have the option to mutiple layer (overlayfs), different vnc's on different ctrl-alt-Fn tty's. With sym linked sfs's only what files are used are pulled into ram/cache.

The isolation is also nice. With X (Xnc) running with just chroot and sys_admin capabilities dropped, you can't for instance mount /dev/sda2 - where your data files might be kept. And with the chroot method you can load/unload sfs's without having to reboot. Downloaded a C program that you want to compile but don't have devx.sfs loaded, then just create another sym linked/overlayfs and chroot into that where both fd64.sfs and devs.sfs are included in the lower overlayfs layer and use the main system to copy that C program from one chroot to the other and compile it. Copy the bin file back to the former session, and close/unload that devx.sfs overlayfs.

As everything runs in the framebuffer you have the added benefit that fbcon (framebuffer terminal emulator) can see X(vnc) videos/dynmics, bleed through, a video in a terminal session. As can you for instance easiiy write a red line or two at the top of the screen - that I now do as a low battery warning indicator, that shows no matter what tty or X desktop you may be viewing (being the same framebuffer).

The main cost is loss of graphics acceleration, gaming etc. But in turn your battery may last longer, gpu's are quite energy intensive. If you're using the same fd64.sfs to boot either normally or via framebuffer, then you have the option to (re)boot according to what tasks you have planned. Boot the full main system with nvidia/whatever if your doing high intensity graphics, or boot the framebuffer near immediately for general browing/office activities.

Fundamentally it might be worthwhile considering a revision of Fatdog's Bulldog structure/content. With ssl/ssh, alsa, fbvnc built in, along with simple framebuffer availability that is quite powerful/flexible in itself and is very portable. I have around 30 core binaries and 30 odd libs making up my initramfs content that is enough to boot/wifi net connect, ssh and vnc - so alone without even loading fd64.sfs can connect to a full gui desktop vnc server (such as the one on my phone or another on a 'remote' desktop/server (our i5 the other side of the room). When vnc'd into that desktop/server being hard wired ethernet and nvidia graphics, the laptops (vnc client) look and feel is very impressive, web pages load instantly, online internet speed tests indicate very fast rates even though the laptop is just wif net connected - because in reality its just a vnc client graphical terminal.

[fatdoguser]

Is it possible to boot a regular laptop/Fatdog into 16 bit color depth mode (rgb565)?

If I use control-panel to define that, X wont restart.

If I boot with 1366x768x16 (vga=ask) no boot text is seen, just a black screen, but X does appear. However that is reverted to 32 bit depth (appears that KMS takes over and "corrects" the "error").

For general use, 16 bit depth is fine, Most things looks perfectly acceptable. Whilst a 2 byte saving per pixel x number of pixels x 60 frames per second ... is a lot of data processing saving (near 250MB/second on a 1920x1080)

[jamesbond]

1. use boot param pfix=nox nomodeset
2. in console run modprobe uvesafb mode_option=1024x768-16 (obviously choose a mode that works for you)
3. then run xorgwizard, choose "fbdev", set resolution to auto. Enable ShadowFB if your display is slow, otherwise leave it off. Test and confirm that it works.
4. Then launch xwin.
   Once you get this to work I trust you can automate the process.

This works on BIOS machines. I haven't seen an UEFI machine that supports 16-bit colour.

[fatdoguser]

1. use boot param pfix=nox nomodeset
2. in console run modprobe uvesafb mode_option=1024x768-16 (obviously choose a mode that works for you)
3. then run xorgwizard, choose "fbdev", set resolution to auto. Enable ShadowFB if your display is slow, otherwise leave it off. Test and confirm that it works.
4. Then launch xwin.
   Once you get this to work I trust you can automate the process.

This works on BIOS machines. I haven't seen an UEFI machine that supports 16-bit colour.

Thanks @jamesbond

Haven't bought new hardware for quite a while now (i5). I've always reset away from UEFI to use BIOS instead (zap the drives, partition/install from clean, usually setting the first as a small FAT partition in order to install grub4dos bootloader). Is that still generally possible on later machines, or is that increasingly a UEFI or nowt situation?

I've been using standard busybox inittab, four tty's. Need to define more as I'm currently running with fatdog out of the box fd64.sfs on tty1 with seamonkey running as root, but with chroot and sys_admin capabilities dropped to that X session (x11vnc), my regular fd64.sfs (re-configured to my liking) running with full permissions on tty2 (Xvnc), running chrome. A i5 desktop (remote) vnc again running chrome on tty3 (vncserver/Xvnc), my phones vnc server on tty4 running jwm/otter browser. All displayed to fbcon/framebuffer. fbvnc requires ctrl-spacebar to turn of screen updates, otherwise other vnc's all bleed through to the one that you're viewing, but in some cases you might like to see changing screen elements from one session bleed through to all others. I need to add more tty's so I can add a further 16+ cores/64GB ram real remote (third party) to that and then focus upon automating the startup and network sharing (sshfs) side of things. Real remotes are nice, as they run 24/7 so as soon a framebuffer is booted (a second or two in my case) and wifi/net established, vnc drops you straight into a full gui deskop, as you last left it or however it may have mved on (long compile or render).

[fatdoguser]

1. use boot param pfix=nox nomodeset
2. in console run modprobe uvesafb mode_option=1024x768-16 (obviously choose a mode that works for you)
3. then run xorgwizard, choose "fbdev", set resolution to auto. Enable ShadowFB if your display is slow, otherwise leave it off. Test and confirm that it works.
4. Then launch xwin.
   Once you get this to work I trust you can automate the process.

This works on BIOS machines. I haven't seen an UEFI machine that supports 16-bit colour.

Worked OK. Having problems with persistence however. Tried adding the modprobe to the /etc/modprobe.d set which didn't work so added it to initrd just after the process modules function call which didn't work either. Does boot to framebuffer, but at 32 bit (rgb888).

At rgb888 the colouring is easier than figuring out rgb565, the following for example flashes 4 pixel rows of alternate red and white lines (the alert I'm using as a battery getting low indicator)

Code: Select all

#!/bin/sh

# fbset indicates 32 bit depth

WIDTH=`fbset | grep geometry | awk '{print $2}'`

# blue, green, red, blending (repeated WIDTH times (pixels in one line)
RED=`printf '\\\\x00\\\\x00\\\\xff\\\\x00%0.s' $(seq 1 $WIDTH)`
WHITE=`printf '\\\\xff\\\\xff\\\\xff\\\\x00%0.s' $(seq 1 $WIDTH)`

RED=$RED$RED$RED$RED            # expand to 4 pixel rows
WHITE=$WHITE$WHITE$WHITE$WHITE

a=0
while [ $a -lt 4 ]; do
   printf $WHITE >/dev/fb0
   sleep 0.3
   printf $RED >/dev/fb0
   sleep 0.3
   a=$(($a+1))
done   

[dr__Dan]

@fatdoguser,

Is that still generally possible on later machines, or is that increasingly a UEFI or nowt situation?

New to me nearly 5YO workstation laptop requires UEFI booting from internal drives, but allows BIOS booting from external drives. Does not require Secure Boot for internal drives.

Lost in the details but learning,

Dan

[fatdoguser]

@fatdoguser,

Is that still generally possible on later machines, or is that increasingly a UEFI or nowt situation?

New to me nearly 5YO workstation laptop requires UEFI booting from internal drives, but allows BIOS booting from external drives. Does not require Secure Boot for internal drives.

Lost in the details but learning,

Dan

@dr__Dan