Video blank, but ShredOS booted (v2021.08.2 v19) development

[PartialVolume]

@Firminator

Still doesn't work on 3 different systems. But as mentioned in the other issue I can confirm you can 'blindly' ALT+F2 to the other console and type reboot and it will reboot.

Could you confirm the CPU/GPU and make/model of monitor you are using on all three systems. Also UEFI details such as whether legacy or CSM is available.

I'm prepared to buy some hardware but I want to do it at minimum cost. Maybe buy the cheapest motherboard that has this same chipset.

In the meantime I'll add some scripts to this latest version which will output logs including details of the framebuffer that's in use, its resolution depth etc. To the USB stick.

[PartialVolume]

There's an easier way, the next version I'm testing has a working network, you will be able to telnet into ShredOS, grab the logs, even run an nwipe session on the hardware via telnet.

[PartialVolume]

@Firminator Before a public release of v2021.08.2...., I think from a security aspect it will be a good idea to only automatically start the telnet server if you have already edited grub.cfg and appended shredos=telnetd to the kernel command line?

Also updating README.md to indicate how you can make a persistent change or alternatively start and stop the telnet daemon once you are booted. On a headless system or a system like we have at the moment that has an issue with framebuffer switching/display then you could edit grub.cfg to enable telnetd and then gain access to the system. And for those that are not aware, why you shouldn't use telnet over the internet unless through a SSH tunnel or VPN.

[Firminator]

I'm prepared to buy some hardware but I want to do it at minimum cost. Maybe buy the cheapest motherboard that has this same chipset.

I think if you can get hold of a used Lenovo Yoga 11e (Type 20HS !) with Windows (not a Chromebook) you would be able to troubleshoot pretty cheap. In the US they sell it for ~$100 ( https://www.ebay.com/itm/324189335836 ). Specs are @ https://pcsupport.lenovo.com/us/en/products/LAPTOPS-AND-NETBOOKS/THINKPAD-YOGA-SERIES-LAPTOPS/THINKPAD-YOGA-11E-4TH-GEN-TYPE-20HS-20HU

This laptop exposes the oddest behaviour when using the USB image of ShredOS and the last published ISO of ShredOS depending on what combination of UEFI/LegacyBIOS and CSM setting I'm using. It really drills down to these two settings.

I've seen 3 different things:
a) just an _ (underscore). It doesn't show the Recalbox message and then apparently a real crash (can't ALT+F2 and reboot)
b) Recalbox, but nwipe curses GUI never shows up (but ALT+F2 reboot works)
c) boots fine showing SHredOS booting then shows nwipe GUI

I'd rather have SSH than telnet. Telnet is usually blocked by firewalls. Although I'm not sure how complicated that would be for you to implement. I hate asking for additional features. For the troubleshooting part I'd also wouldn't mind if all the logs are being saved automatically to the flash drive instead of implementing telnet or SSH. Or if there is a script that I can run manually. Like have a script included in the ISO and IMG that saves the logs and then anyone can copy the logs to a flash drive.

[PartialVolume]

I'd rather have SSH than telnet. Telnet is usually blocked by firewalls.

I would also prefer ssh, although it opens up a few issues yet to be resolved. The public/private key, known hosts files would have to be created by the user and stored on the USB then pulled from the USB by shredos before starting sshd. That seems ok, however one big issue I've had is determining reliably under both legacy & UEFI what the boot device name is. You would have thought that was easy to do, but the only way so far is to search through the attached discs looking for a FAT32 partition with a kernel boot line that scredos knows about. That in itself is easy enough to do, but that's probably a version or two away.

For the time being we only need telnet to help us access dmesg.

For the troubleshooting part I'd also wouldn't mind if all the logs are being saved automatically to the flash drive instead of implementing telnet or SSH.

That can be arranged, however telnetd is already implemented so we can put that to use straightaway just to get dmesg out of a system where just the Recalbox message is displayed but shredos is actually running. Dmesg does contain messages about the frame buffer driver in use, address space etc. Also fbset will output some useful info too.

I can send you the latest again if you want to telnet in to it to grab the output of dmesg? Is that email still valid?

I've also found that the version I'm working on with the latest 5.13 kernel won't boot UEFI on my MAC, so still needs more work, while an earlier version worked ok.

I am tempted to revert back to v2020.05.017_x86-64_0.32.003 and then just do a update of nwipe, while keeping the latest version private until I've solved the blank screen/UEFI issue or does v2020.05.018_x86-64_0.32.014 work ok on most systems? It leaves me with a dilemma, not knowing whether these are just edge cases and most systems work fine or whether I should just delete v2020.05.018_x86-64_0.32.014. You don't often hear about the systems where it works fine.

[Firminator]

I'd revert back. The FB drivers that were added in v2020.05.018 were mostly ancient. I've seen those GPUs in the late 90s and early 2000s. I would think that they didn't do anything good really for the UEFI/CSM.screen issue. Plus I would think the behaviour of ShredOS between v017 and v018 didn't change anything for me. I still am able to use ShredOS on my main box. ANd I'm still not able to boot it on any UEFI-(only) box.

I can send you the latest again if you want to telnet in to it to grab the output of dmesg? Is that email still valid?

Can you just send the google drive link and share it with anyone who has the link (that email address from yesterday was ephemeral plus I haven't written down the address). I gotta go now and will grab the files later today if you choose to use google drive. Else I would create a new email address.

[PartialVolume]

I just found something interesting on the grub efi docs,

Make sure to pass pci=nocrs to the kernel command line, to workaround a bug in the EFI BIOS regarding the EFI framebuffer.

Unfortunately it doesn't say what exactly that bug is.

Any chance you could try that and see if it fixes the blank screen.

[Firminator]

I added
linux /boot/shredos console=tty3 loglevel=3 pci=nocrs
to both grub.cfg but no difference. Well, I tested only on one device (the one that is UEFI-only with no CSM or LegacyMode). Good catch though!!!

[Firminator]

I think I found the option that prevents it to boot for UEFI devices:

It offers an EFI option in there. Right now only Legacy (i386-pc) is selected.

Fast forward to the latest buildroot and it even shows that it has the EFI GOP driver included. EFIFB can use this ( https://www.kernel.org/doc/html/latest/fb/efifb.html ) and you have EFIFB enabled.

Of course this is all theory. I haven't tested it. But it sounds about right.

[PartialVolume]

With reference to previous versions of shredos, I need to explain why i386-PC was used but generated a .img that was both capable of legacy and UEFI booting even though that setting was set to i386-PC.

In regards to shredos, buildroot is being used in a way that it wasn't really designed for. It's supposed to built an OS for a single type of hardware for embedded systems and as such you could only select legacy or EFI. To produce a hybrid .img we do some post processing work in /board/shredos/doimg.sh basically copying a pre-build bootx64.efi into the right places in the root /EFI/BOOT/.. So the setting i386-PC builds the bios version while the post processing work in /board/shredos turns that into UEFI bootable.

Now historically when I've updated to a new buildroot version, I've used the .efi file that is saved in /board/shredos and it's always worked. However, last night while looking at the grub efi docs I thought maybe it's an issue with the .efi being copied from one version of buildroot to the next, so I reconfigured buildroot to build a x86_64-EFI. Initially it failed with the biosdisk.mod not being found. Sort of expected, we are not building for a bios system. So start again and remove biosdisk from the string shown above in your snapshot.

This morning, when I come down to check the progress, I found the build failed in the post processing section but importantly it got far enough to build me a new bootx64.efi. Checking the size it's similar, slightly smaller 471040 bytes compared to the original which was 550008.

So my job today, is to take the new .efi, switch back the buildroot to i386-PC, rebuild shredos and the post processing will combine the new .efi with a bios build producing a hybrid bios/UEFI .img

I think I'm correct in saying that even with the new version of buildroot in x86_64-efi mode you can't have it construct both a bios and efi .image. But I'll check that to be double sure, just in case they have improved that part of buildroot.

I'll let you know when the new build of shredos with the new .efi is ready for testing. I'm hoping this new .efi build will solve our problems but we'll have to see.

[PartialVolume]

The efi_gop module is interesting, I'll include that in the build as well.

[PartialVolume]

Also adding in efi_uga as well as efi_gop.

[PartialVolume]

I've found I missed some settings related to EFI in the processor type section, specifically

     [*] EFI runtime service support
        [*]   EFI stub support 
          [*]     EFI mixed-mode support

These were set in all my previous builds but not set with the 5.13 kernel build.

[PartialVolume]

Which then made the setting below appear in Support for frame buffer devices which was previously not visible on the menu.

->Device Drivers
    ->Graphics Support
        ->Frame Buffer Devices
            ->Support for frame buffer devices

[*]   EFI-based Framebuffer Support

[Firminator]

👍 for all these findings

What about splitting up the compilation of the ISO and USB images into LegacyBIOS and UEFI? This would be double the time compiling, but any changes would NOT affect the other build reducing the complexity of troubleshooting.

[PartialVolume]

That may be the way we have to go. I think we are getting there.

To tidy up the current ShredOS based on the 5.6 kernel, I think I'll replace the latest build with a build without all the old framebuffer drivers but including the 0.32.014 version of nwipe, then carry on development on the 5.13 kernel development, when that's ready I'll need to archive the current ShredOS and replace with the new 5.13 build making sure I don't break any URLs to ShredOS. Unfortunately I don't think I can simply push the new build on top of the current build. Before that happens I'll make the development built source of ShredOS with the 5.13 kernel available publically for testing.

[Firminator]

What about introducing a development branch? Right now all the changes are commited to master.
Gotta be careful not to make this is full time job though :)

[PartialVolume]

This may prove useful in future builds, looks like from buildroot 2021.11-rc1, released November 8th, 2021 you can build for multiple grub platforms.

Bootloaders/firmware: grub2 extended to be able to support
	multiple platforms in the same build.

This wasn't possible before so that that will be interesting to see how flexible that is and whether it would simplify simultaneously building legacy and EFi bootable systems, using buildroot rather than the post processing that's currently done in ShredOS to produce the same result.

What about introducing a development branch? Right now all the changes are commited to master.
Gotta be careful not to make this is full time job though :)

Yes, I also prefer branches for submitting PRs like we do in nwipe. So yes rather than commit to the master like I currently do (A bad habit I've got into) I should really commit to a branch for testing first. Problem is, I would imagine the majority don't build from source but want the .img / .iso I'm not sure how that would fit in with branches.

Alternatively the development build could be a completely different repository (as it currently is for the 5.13 kernel build)

Anything that makes things easier and less time consuming. :)

[PartialVolume]

@Firminator Can you give this a try. This is the development build with a 5.13 kernel based on buildroot 2021.08.2. It includes efi service support, it's a rebuild of the bootx64.efi code which includes the modules efi_gop, efi_uga and progress. You will notive that Recalbox no longer shows up, what you will get is the message Booting 'shredos' along with progress information as it transfers the bzimage from the USB stick. You will also find it won't boot in legacy mode with the error Invalid arch-dependant ELF magic.

It boots fine on my Dell Optiplex 9020 in UEFI (1024x768x32) and also on a MAC bookPro UEFI. Resolution is crazy high on the MAC at 2880x1800x32 but it boots.

What I'm interested in is whether it now boots on UEFI systems (secure boot off) where the screen was just showing Recalbox but shredos was actually running underneath.

shredos_devs_only

[Firminator]

What can I say. Hallejuja again. It works!! No Recalbox anymore. Instead it shows Booting 'shredos' along with progress information on the upper right side of screen.

This is from a device that is UEFI-only with no Legacy BIOS or CSM (loads in 12 seconds):

I'll test it on a few other devices tomorrow.

[PartialVolume]

That's really great ! Thanks for doing this testing, I'll be working on the bios issue today to get the combined legacy/UEFI boot working on a single .img

From what I can workout, to get the UEFI working I had to build a new grub .efi file with the new built-in modules efi_gop and efi_uga. Those modules are built in to the efi file or at least I think that's how it works, although don't quote me on that. That may also explain why progress is now displayed in UEFI mode and wasn't before, even though progress was showing up in legacy build.

It's great we are now getting somewhere and with a newer kernel and buildroot.

[PartialVolume]

@Firminator Now booting in legacy and UEFI !

The issue was enabling efi_gop and efi_uga for the legacy build. Enabling efi_gop and efi_uga is only necessary when I'm rebuilding the .efi. I must document the procedure for all this as soon as possible. Also one of the reasons people may run into errors with the current released version of shredos if they try and build from source, is that I used absolute paths which are only any good if you have a identical directory structure to me which is very unlikely. This new build I've used relative paths so it will build fine where ever you choose to build it on you system.

Be aware this has the telnetd daemon running so you can login to shredos from your LAN, assuming you have plugged the PC/device into a network. Shredos only supports ethernet, WiFi is not enabled. To make this more secure, I will disable telnetd from starting automatically, in the next build, unless you specifically request it by putting shredos=telnetd on the kernel command line in grub.cfg. Alternatively you could start/stop it manually. Personally I think this would be useful on a server or headless system or where your display hardware is faulty but you still want to wipe the discs without pulling the PC/laptop apart.

Shredos 2021.08.2 legacy and UEFI bootable

[Firminator]

This build also boots fine on the same machine. I'll test it on a few devices today. This is great! If this holds up a bunch of those tickets/issues can be closed. Thank you also for documenting. The relative path thing might explain why my compile process always fails. I haven't had time to look at all the erros, but the critical error (where it terminates) is not finding opensll?!?!

scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
25 | #include <openssl/opensslv.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.

I'll test these combos later today:
Intel GPU; UEFI mode with CSM on: test
Intel GPU; UEFI mode with CSM off: test
Intel GPU; Legacy mode: test
NVIDIA-only; Legacy mode: test
Intel-only; UEFI-only: works

[Firminator]

Device 1 (SecureBoot off; provides option to select UEFI or Legacy Mode):

• Intel GPU; UEFI mode with CSM on: works (w/ native resolution)
• Intel GPU; UEFI mode with CSM off: works (w/ native resolution)
• Intel GPU; Legacy mode (with no CSM): doesn't boot (falls back to BIOS's boot device selection menu)

Device 2 (no SecureBoot; no UEFI; Legacy BIOS only):

• NVIDIA-only; Legacy mode: works! (640x480 resolution)

Device 3 (SecureBoot off; UEFI-only, no Legacy BIOS, no CSM):

• Intel-only; UEFI-only: works (w/ native resolution)

[Firminator]

Device 4 (SecureBoot off; provides option to select UEFI or Legacy Mode):

• Intel GPU; UEFI mode with CSM on (dubbed 'Legacy External Device'): works (w/ native resolution)
• Intel GPU; UEFI mode with CSM off (dubbed 'Legacy External Devices'): works (w/ native resolution)
• Intel GPU; Legacy mode (with no CSM): works! (640x480 resolution)

[Firminator]

Device 5 with switchable GPUs (Intel GPU and discrete NVIDIA Quadro) ; (SecureBoot off; provides option to select UEFI or Legacy Mode):

• GPU ? ; UEFI mode with CSM on (dubbed 'Legacy External Device'): works (w/ native resolution)
• GPU ? ; UEFI mode with CSM off (dubbed 'Legacy External Devices'): works (w/ native resolution)
• GPU ? ; Legacy mode (with no CSM): first time crashed, 2nd time works (640x480 resolution); might be a device-specific GPU problem since I had problems in the past with this device.

[Firminator]

Device 6 (older Dell server; provides option to select UEFI or LegacyMode):

• Matrox G200e ; Legacy Mode: boots fine w/ beautiful old-school 640x480 resolution.
• Matrox G200e ; UEFI mode yet: boots fine

---

Manufacturer | Matrox Electronics Systems Ltd.
PCIDeviceID | 0534
PCISubDeviceID | 048C
PCISubVendorID | 1028
PCIVendorID | 102B

[PartialVolume]

One Reason why you might get a blank screen (but shredos has actually booted) - The monitor not supporting 640x480 resolution !

---

Motherboard	Processor	Graphics No.1	Graphics No.2
Gigabyte H81M-DS2V	i5-4460	Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller	NVIDIA Corporation GM107 [GeForce GTX 750] (rev a2)

Boots?	Boot Method	Which Graphics Card ?	Resolution	Monitor ratio	Notes
YES !	UEFI	No.2 Nvidia GTX750	1024x768	4:3	No issues
YES !	Legacy	No.2 Nvidia GTX750	640x480	4:3	No issues
YES !	UEFI	No.1 Intel E3-1200	1024x768	16:10	No issues
YES !	Legacy	No.1 Intel E3-1200	640x480 (works if 1024x768 set)	16:10	Screen blank but shredos boots as it was possible to telnet in, set gfxpayload=1024x768x16 in /boot/grub/grub.cfg and it works *

The gigabyte UEFI firmware always appears to have CSM enabled with the user not being able to override. The UEFI bios seems to always default to the external Nvidia graphics card with no options to override in the UEFI firmware. To test the integrated graphics it's necessary to pull out the Nvidia card and the Intel integrated graphics then takes over. Interestingly shredos boots when secure boot is on.

• On this specific combination we are using a HP compaq LA2405X monitor, wide screen with a aspect ratio of 16:10 and a Viewsonic 4:3. Then I remembered I had modified the legacy /boot/grub/grub.cfg with the addition of set gfxpayload=1440×900 which it didn't like, changing the grub.cfg entry to set gfxpayload=1024x768x16 then shredos booted and displayed a nice 1024x768 image. Now if I remove the set gfxpayload=1024x768x16 from /boot/grub/grub.cfg (shredos doesn't normally come with a set gfxpayload command) and then boot shredos, I get a blank screen. However, shredos has booted ok as I can login, if I type fbset -i I can see the display resolution the display buffer is running at, which is shown below:

# fbset -i

mode "640x480-60"
    # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
    geometry 640 480 640 480 4
    timings 39721 48 16 33 10 96 2
    rgba 6/0,6/0,6/0,0/0
endmode

Frame buffer device information:
    Name        : VGA16 VGA
    Address     : 0xa0000
    Size        : 65536
    Type        : VGA 16 colors in 4 planes
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 80
    Accelerator : No
#

Is 640x480 a resolution that the HP compaq LA2405X monitor can't display? Let's put set gfxpayload=1024x768x16 back into /boot/grub/grub.cfg and see if it boots again. Yep, it boots and the nwipe display comes up in 1024x768 resolution. If i telnet in and run fbset -i the resolution is confirmed.

# fbset -i

mode "1024x768"
    geometry 1024 768 1024 768 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/0
endmode

Frame buffer device information:
    Name        : simple
    Address     : 0xe0000000
    Size        : 1572864
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 0
    YPanStep    : 0
    YWrapStep   : 0
    LineLength  : 2048
    Accelerator : No
#

SUMMARY:
So i guess what this all means is that with the latest 2021.08.2 build even if you get a blank screen when booting it may be because your monitor does not support 640x480 resolution in legacy mode. Solution: Change your monitor or set gfxpayload=1024x768x16 in /boot/grub/grub.cfg. How to