Running Qubes OS on Librebooted Thinkpad T500 with Quad core Mod

Hello, I have seen some videos about Qubes and i want to use it for my personal use

Would Qubes run on a Librebooted ThinkPad T500 with 8 gigs of ram and a SSD. Will do the cooling mod and the quad core mod in the near future but i need to know how will it preform with the quad core (i do not have the quad core right now but i know that’s not gonna be a great experience on whats on it now) Would it run smoothly? on my hardware. And what things would i need to install to have ok battery life and what to do to make Qubes absolutely airtight secure. I know Qubes is very heavy but what would i need to squeeze a smidge of battery more

The 8 Gb of RAM will be your bottleneck - if not a dealbreaker.

T400/T500/X200 are really similar.

The following applies:

(for vt-x to be non-bogus, microcode updates are needed, which libreboot won’t provide. Osboot could. For vt-d2, that extension just didn’t existed. So sys-net and sys-usb will not provide strong isolation).

Not sure of 4.1 behavior of Qubes installer. It will sure complain that the hardware is not compatible.
Not sure if installer permits to proceed anyway, if it does, not sure if sys-net nor sys-usb qubes creation will succeed.

You can try to switch your system-qubes into minimal templates and restrict their RAM usage at 400 MB. Also, you can try to run your daily use qubes as a minimal and mostly terminal-based applications, so that you can be comfortable with the 8 GB of RAM on your machine.

1 Like

You can try Qubes by installing it to a USB stick first, instead of the hard drive.

I have a librebooted T500 with the QX9300 quad-mod, I can’t install Qubes OS 4.1 on it.

If you select the Seabios payload in the boot menu you can start the installer, but after the kernel image is loaded the screen just goes black.

So Libreboot doesn’t have the microcode to run Qubes

I could try osboot like you said because i have seen on Libreboot’s website about a seller that sells preinstalled laptops with Libreboot/Coreboot and the seller does a send-in to refurbish and he has so he can install the quad core mod with no extra cost and he can install osboot (i could do it myself but i do not trust myself on hardware level mods yet) and so would that fix it (What i was talking about Send-in service: osboot/libreboot/coreboot installation and refurbishing service – Ministry of Freedom)

On the Qubes installer. Will it just install (i am not sure about how important is sys-usb but if im correct sys-net is kinda important)

1 Like

I do not know how to get this point through: T400/T500/X200 are not fit for Qubes OS.
People have confirmed this, even in this thread, quoted just above, here.

This post is a duplicate of another post on libreboot. Libreboot devices are not fit (platforms too old to have vt-d2, see Qubes OS requirements) to have users benefit of hardware isolation it offers.

That duplicate post:

Refers to a github issue, where Zammit says:
“By the way, I submitted a patch ages ago to fix DMAR table in X200, so VT-d1 works on X200 with coreboot and no ME, see … also, there might be some way to fix the graphics corruption on IGD if someone considers pursuing my old patch that got abandoned:

So there will were still graphical glitches when using Qubes 3.2. Fixes should happen first in coreboot for it to deal with that known problem.

Also, having had to change things under Heads for it to be able to boot 4.1, VBT blobs also need to be injected in coreboot for it to have the installer boot properly.

xx20 can be beautiful machines to boot Tails from USB sticks. But Qubes OS, it never really worked, and making it work today is a bit pointless without the platform fitting Qubes OS System requirements

If libreboot is desired, I think the only platform supporting Qubes (not even sure, untested. Would need to be confirmed.) is the G505S. But it is rare, not so well constructed (people said) and not having a TPM either. Not a requirement, again, but also have lost interest in trying to support it under Heads.

@222 I tested x200 with Qubes for 3.2 support a while back.
libreboot says it themselves
Where “Anecdotal reports from at least 1 user suggests that some models with CPU microcode 1067a (on the CPU itself) might work with vt-x in libreboot”. That was me.
If you could ask Leah from libreboot to make a note saying that libreboot xx00 are not compatible with Qubes OS because lack of vt-d2 and vt-x, that would be a service to both communities.

1 Like

@adw Maybe Qubes OS system requirements should state vt-d2 instead of vt-d for clarity and clearly state that vt-d1 are not supported? Specify a basic platform where vt-d2 became a thing on Intel?

Seems like users do not understand the difference and the lack of interrupt remapping support under vt-d1 as opposed to vt-d2, so the question is repeated over and over at different places since 2016.

You don’t need to worry about getting the point though, no one was asking for your permission.

The problem with install Qubes isn’t related to your vt-d theory, the graphics simply doesn’t work when libreboot is installed. It doesn’t matter what you select in the installer, even the memory test just gives a black screen.

I wasn’t aware of the distinction. @marmarek, thoughts on this?

On past performance I wouldnt trust Leah with my laptop.
minifree has an “interesting” record - I would suggest you look at
reviews or comments on Reddit, but (as mod) Leah removed all the adverse

Was answered:

On that graphical issue, there may be ways around from coreboot (coreboot initializes the hardware, hope we are clear on that) by providing vbios and/or have seabios to deal directly (and with their own graphic initialization) with the graphical installer (and maybe also memtest86++), which needs a valid framebuffer to be able to draw on screen.

I’m giving hints here to make it work even if I do not recommend GM45 usage for Qubes. As stated also earlier here, for Qubes 4.1 installer to work with Heads, vbt blobs (data for configurating display) was somehow needed to have QubesOS installer be able to take ownership of the framebuffer from Heads, even if the framebuffer there is initialized by i915 and drm drivers for xx20/xx30… Something changed there, and the “easy” workaround was for those tables to be available when Qubes installer kernel tried to apply its helpers into determining what was the proper graphical resolution. Otherwise; screen corruption and or blank screen. It took months to figure this out correctly under Heads, which is aimed primarily (I would say most of the user base there) using it to boot Qubes OS. But there is no good reason to push for libreboot here (no microcode, no virtualization) and no real interest for security benefits of Qubes for hardware isolation. I’m pretty sure that with a lot of work here (including working on coreboot to get rid of the screen corruptions by code) or simply using blob base graphic init and/or using Seabios to boot Qubes from its grub bootloader, it might work.

But again, not wanting to discourage anyone here, but if in other threads, people are questioning Ivy bridge hardware (x230/t430/w530/t530) for its security promises (lack of microcode updates), GM45 is simply not even meeting Qubes System Requirements altogether. It is a good fit for booting Tails, though.

1 Like