Unable to get graphics with regular or Edge ISOs, but can with LMDE5

[juannm]

Hi, is there a fixed procedure or decision flow by Mint devs, to select which kernel versions are shipped in the Edge builds? I'm saying this because with my too new laptop seems to, surprisingly, work only with an older version of the kernel, something that got me 100% by surprise. So for situations like this it might be really useful being able to select between different versions (all being newer than the provided by base Mint).

The problematic laptop in question is an LG Gram, model 16Z90P-G.AD89B. Report from System Info: http://termbin.com/6s0v
The key is that it has an Intel Core i7-1165G7, and the GPU is an Intel TigerLake GT2 ("Iris Xe").

Linux Mint 20.3 comes with kernel 5.4, and Mint 20.3 Edge comes with 5.13... but both get a blank screen when trying to boot from the live USB, regardless of GRUB options tested:

Code: Select all

pci=nommconf

However, Mint Debian Edition 5, with its kernel 5.10 LTS, is able to boot fine! That's how I was able to get the System Info report from above.

I'm now curious if the kernel 5.15 (which is also LTS) would fail like the 5.13, or work like the 5.10...

Another option is that if there is documentation somewhere, I would probably be able to make my own ISO with different kernel versions. Is something like that possible? Any published document that I can use as inspiration?

Regards and a thousand thanks for building this great distro.

[SMG]

Hi, is there a fixed procedure or decision flow by Mint devs, to select which kernel versions are shipped in the Edge builds? I'm saying this because with my too new laptop seems to, surprisingly, work only with an older version of the kernel, something that got me 100% by surprise. So for situations like this it might be really useful being able to select between different versions (all being newer than the provided by base Mint).

The problematic laptop in question is an LG Gram, model 16Z90P-G.AD89B. Report from System Info: http://termbin.com/6s0v
The key is that it has an Intel Core i7-1165G7, and the GPU is an Intel TigerLake GT2 ("Iris Xe").

Normally, kernels 5.8 (Which is on the LM20.1 Edge ISO) and higher will provide graphics for that CPU. Did you try booting the LM20.2 Edge ISO which has the 5.11 kernel?

In any case, you should be able to boot in compatibility mode and then boot into Recovery Mode for the installed version (both of those automatically use nomodeset kernel parameter) to change to a different kernel if a different kernel is needed. There is no need to have many different kernels on the ISO.

It is possible your system might need the i915.enable_psr=0 kernel parameter to get graphics with the 5.13 kernel. Or there is also a 5.14-oem kernel you could try once you install Linux Mint.

There are quite a few different options if you really want to get Ubuntu-based Mint installed.

I'm now curious if the kernel 5.15 (which is also LTS) would fail like the 5.13, or work like the 5.10...

If you are really curious, then try booting a live session of Ubuntu 22.04. However, keep in mind that will be using the Canonical 5.15 kernel and not the mainline 5.15 kernel.

[Reddog1]

Believe me, this is common with linux kernels. All kernels are not created equal, and it very much depends on the distribution whether a specific kernel will contain the appropriate drivers (or version of the drivers, to be specific). You would think that a 5.13 kernel would have at least the same drivers available as a 5.10 kernel from a different distro, but it just isn't so. I've run into this repeatedly, because I install Linux on Apple hardware. In your case, the current Debian stable kernel (5.10) isn't identical to ubuntu (mint) kernels, either stable or the advanced (5.13). Maybe, Mint has caught up with 5.15. It is the same difference across all distributions. Sometimes arch will work when ubuntu/mint won't, and vice-versa. I've tried as many as 3 different distributions to get a working install on an Apple machine. This isn't exactly the fault of linux kernel developers, or the distribution-kernel staff. The problem is caused by hardware manufacturers not releasing the specs in a timely manner, if they release them at all. Broadcom and Nvidia are two of the major miscreants, but AMD is also guilty in being slow. Intel does a better job than any other manufacturer, but they aren't perfect either. Everybody caters to Windows.

[juannm]

Well, the issue progressed in an unexpected direction.

I read somewhere a suggestion to write the .iso with Rufus, which applies its own version of GRUB, or maybe its own settings, which may work better. This didn't make much sense to me, but nonetheless I tried and it worked! The official Mint 20.3 iso (not edge) is now able to boot past the GRUB screen, the live Mint session loads up, and I have been able to install it (with its old kernel 5.4 and all).

This tells me something crucial: There is something in how the ISO gets written to the USB that makes all the difference. The team behind Mint's USB Image Writer (which I had been using before Rufus) might be interested in checking what it is, because it can make all the difference for cases like mine.

To expand on this, however, using Rufus only made the official Mint 20.3 iso be able to boot up, but the same cannot be said about any of the other ISOs that I tried:

• Mint 20.3: worked
• Mint 20.3 edge: failed
• Ubuntu 20.04.4: failed
• Ubuntu 22.04: failed

where "failed" means the same every time: After choosing any entry (normal or failsafe, didn't matter) of the live USB GRUB startup options, the screen goes to black and the computer reboots on its own after 20 or 30 seconds.

Once installed (from the Mint 20.3 ISO that worked), I was able to test some different kernels. So far, only 5.4 has been able to boot up (5.4.0-113). None of the others worked, and I tried all of the kernels provided by the Mint Updater tool:

• 5.4: worked
• 5.8: failed
• 5.11: failed
• 5.13: failed
• 5.14-oem: failed

It's nice to have a working system for now, but I'm worrying about not being able to upgrade to future versions if a regression of some sort has stuck permanently in the kernel.

[SMG]

This tells me something crucial: There is something in how the ISO gets written to the USB that makes all the difference. The team behind Mint's USB Image Writer (which I had been using before Rufus) might be interested in checking what it is, because it can make all the difference for cases like mine.

You are the first person of which I have heard to mention they could not boot an ISO made with Mint's USB image writer. Usually, Rufus is recommended for those creating the image on Windows.

I have no guesses as to what might be happening with your different trials.

Once installed (from the Mint 20.3 ISO that worked), I was able to test some different kernels. So far, only 5.4 has been able to boot up (5.4.0-113).

Please give us information about your install by entering this command in a terminal:

Code: Select all

inxi -Fxxxrz

Click </> from the mini toolbar above the textbox where you type your reply and then place your cursor between the code tags and paste the results of the command between the code tags [code]Results[/code]. This will let us know how Mint sees your hardware.

Also, I do not see where you tried the kernel parameter I suggested for the newer kernels.

[juannm]

Yes, I have been using the Mint's USB image writer for years, because it is very good, just a small tool that does one thing and does it well. But it has been different this time.

The only practical differences I could see is that Rufus detects that the ISO file is a so-called "hybrid" and asks me to choose which mode I want, which is a curious feature, as I had never been asked about this difference:

Then, a second dialog warned that the required Syslinux version doesn't come included by default with Rufus, so it would need to download it:

This makes me think that indeed, Rufus is doing something clever with the writing of the images. It claims not being able to include all possible syslinux versions, which makes me think, do other image writers include them all? Because I had never seen such a message with other software such as the Mint USB writer or Balena Etcher.

Also, I do not see where you tried the kernel parameter I suggested for the newer kernels.

Sorry, I forgot to mention it, but yeah I tried different kernel params in the GRUB config (to be clear: adding them to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, followed by sudo update-grub).

I did try with explicitly setting nomodeset, i915.enable_psr=0, and pci=nommconf, while removing splash and quiet, to have some feedback. None of these made any difference, either separately or in various combinations; other kernels that are not 5.4 did not boot. They get stuck trying to load the kernel. For example, for the kernel 5.8, it would look like this:

Code: Select all

Loading Linux 5.8.0-63-generic ...
Loading initial ramdisk ...

And, after 30 seconds or so, the machine reboots on its own. However the kernel 5.4 does boot and all the familiar kernel startup messages appear on the screen for a split second, before the Mint login manager loads up.

My system info, when uploaded by the System Info tool from installed Mint 20.3, is not too different from the one generated by the same tool in LMDE5 live session:

• LMDE5: http://termbin.com/6s0v
• 20.3: https://termbin.com/va1s

And here is the result of running inxi -Fxxxrz:

Code: Select all

System:    Kernel: 5.4.0-113-generic x86_64 bits: 64 compiler: gcc v: 9.4.0 Desktop: Cinnamon 5.2.7 wm: muffin 5.2.1 
           dm: LightDM 1.30.0 Distro: Linux Mint 20.3 Una base: Ubuntu 20.04 focal 
Machine:   Type: Laptop System: LG product: 16Z90P-G.AD89B v: 0.1 serial: <filter> Chassis: type: 10 v: 0.1 serial: <filter> 
           Mobo: LG model: 16Z90P v: FAB1 serial: <filter> UEFI: Phoenix v: T2ZF0360 X64 date: 10/07/2021 
Battery:   ID-1: CMB0 charge: 33.7 Wh condition: 80.0/80.0 Wh (100%) volts: 7.5/7.7 model: LG LGES-LG type: Li-ion 
           serial: <filter> status: Discharging cycles: 4 
CPU:       Topology: Quad Core model: 11th Gen Intel Core i7-1165G7 bits: 64 type: MT MCP arch: Tiger Lake rev: 1 
           L2 cache: 12.0 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 44851 
           Speed: 464 MHz min/max: 400/4700 MHz Core speeds (MHz): 1: 451 2: 1096 3: 658 4: 518 5: 532 6: 1031 7: 1054 8: 735 
Graphics:  Device-1: Intel vendor: LG driver: N/A bus ID: 00:02.0 chip ID: 8086:9a49 
           Display: x11 server: X.Org 1.20.13 driver: fbdev unloaded: modesetting,vesa resolution: 2560x1600~93Hz 
           OpenGL: renderer: llvmpipe (LLVM 12.0.0 256 bits) v: 4.5 Mesa 21.2.6 compat-v: 3.1 direct render: Yes 
Audio:     Device-1: Intel vendor: LG driver: sof-audio-pci bus ID: 00:1f.3 chip ID: 8086:a0c8 
           Sound Server: ALSA v: k5.4.0-113-generic 
Network:   Device-1: Intel driver: iwlwifi v: kernel port: 3000 bus ID: 00:14.3 chip ID: 8086:a0f0 
           IF: wlp0s20f3 state: down mac: <filter> 
           Device-2: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152 bus ID: 2-2:2 chip ID: 0bda:8153 
           serial: <filter> 
           IF: enx00e04ccd5b4c state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 953.87 GiB used: 11.99 GiB (1.3%) 
           ID-1: /dev/nvme0n1 vendor: SK Hynix model: HFM001TD3JX013N size: 953.87 GiB speed: 31.6 Gb/s lanes: 4 
           serial: <filter> rev: 41000C20 scheme: GPT 
Partition: ID-1: / size: 491.15 GiB used: 11.96 GiB (2.4%) fs: ext4 dev: /dev/nvme0n1p7 
Sensors:   System Temperatures: cpu: 58.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
           1: deb http://packages.linuxmint.com una main upstream import backport #id:linuxmint_main
           2: deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse
           3: deb http://archive.ubuntu.com/ubuntu focal-updates main restricted universe multiverse
           4: deb http://archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
           5: deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
           6: deb http://archive.canonical.com/ubuntu/ focal partner
Info:      Processes: 267 Uptime: 1m Memory: 31.05 GiB used: 1.33 GiB (4.3%) Init: systemd v: 245 runlevel: 5 Compilers: 
           gcc: 9.4.0 alt: 9 Shell: bash v: 5.0.17 running in: gnome-terminal inxi: 3.0.38 

[juannm]

I wanted to be super-sure about my claims, discard possible mistakes on my side. So I went on and wrote again the LM 20.3 ISO file, from the newly installed machine, into the same USB drive as before, using Mint's USB image writer.

Confirmed: upon reboot, the USB's GRUB menu appears, where I can choose between "Start Linux Mint 20.3 Cinnamon 64-bit" and "Start Linux Mint 20.3 Cinnamon 64-bit (compatibility mode)". Neither of these options work; they just bring a black screen, and after 30 seconds the machine reboots. The USB LED blinked only for the first couple of seconds, then went silent, which means that no data was being read.

Then, I re-wrote the same ISO file with Rufus. The boot GRUB menu is the same. But this time, choosing the first option leads to a proper startup of the Mint live session: First, the screen goes to black, then the USB LED blinks almost constantly, indicating that there are actual reads going on, and after several seconds, the Mint logo appears on screen, followed by the live session. Installing from this session leads to a working system, no GRUB modifications needed.

This, especially the latest sentence, brings me to believe that the problem occurs strictly in the way the image was written; maybe Rufus is embedding some more compatible version of syslinux, or something in that vein.

But I think that 2 different issues are getting mixed here. Let's not forget that on top of all the above, there is the issue that none of the newer kernels are able to boot, regardless of using Rufus or not (except the 5.10.0-12-amd64 from LMDE5). So, while I'm happy that I've been able to install Mint 20.3 and can now work with the laptop, the issue remains that in the future it seems I won't be able to update to other newer versions, which is worrying...

[SMG]

The only practical differences I could see is that Rufus detects that the ISO file is a so-called "hybrid" and asks me to choose which mode I want, which is a curious feature, as I had never been asked about this difference:

I have not used Rufus, but it is my understanding that one must specify in Rufus whether they need the ISO to boot in UEFI mode or in BIOS mode. (That is the limit of my knowledge of Rufus--please do not ask me any hard questions about Rufus. )

The Linux Mint ISO tool creates an ISO that can do either UEFI or BIOS. You do not have to specify ahead of time which one you need. Perhaps that is what Rufus considers to be hybrid? I do not know and am just guessing.

My system info, when uploaded by the System Info tool from installed Mint 20.3, is not too different from the one generated by the same tool in LMDE5 live session:

Actually, there is a significant difference and it is a big problem. There is no graphics driver loaded with the 5.4 kernel. Running in software rendering mode makes the CPU work harder and run hotter.

Graphics with LMDE5 and 5.10 kernel:
Device-1: Intel TigerLake GT2 [Iris Xe Graphics] vendor: LG driver: i915 v: kernel
bus ID: 00:02.0 chip ID: 8086:9a49
Device-2: Chicony LG Camera type: USB driver: uvcvideo bus ID: 3-2:3 chip ID: 04f2:b6fa
Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting unloaded: fbdev,vesa
resolution: 2560x1600~60Hz s-dpi: 96
OpenGL: renderer: Mesa Intel Xe Graphics (TGL GT2) v: 4.6 Mesa 20.3.5
direct render: Yes

Graphics with LM20.3 and 5.4 kernel:
Device-1: Intel vendor: LG driver: N/A bus ID: 00:02.0 chip ID: 8086:9a49
Display: x11 server: X.Org 1.20.13 driver: fbdev unloaded: modesetting,vesa
resolution: 2560x1600~93Hz
OpenGL: renderer: llvmpipe (LLVM 12.0.0 256 bits) v: 4.5 Mesa 21.2.6 compat-v: 3.1
direct render: Yes

Confirmed: upon reboot, the USB's GRUB menu appears, where I can choose between "Start Linux Mint 20.3 Cinnamon 64-bit" and "Start Linux Mint 20.3 Cinnamon 64-bit (compatibility mode)". Neither of these options work; they just bring a black screen, and after 30 seconds the machine reboots. The USB LED blinked only for the first couple of seconds, then went silent, which means that no data was being read.

Then, I re-wrote the same ISO file with Rufus. The boot GRUB menu is the same. But this time, choosing the first option leads to a proper startup of the Mint live session: First, the screen goes to black, then the USB LED blinks almost constantly, indicating that there are actual reads going on, and after several seconds, the Mint logo appears on screen, followed by the live session. Installing from this session leads to a working system, no GRUB modifications needed.

As I indicated above, it is not working properly, but glad you were able to get Linux Mint installed with this method.

Have you checked to see if your system is running the most recent BIOS/UEFI available? My guess is there might be some type of setting in BIOS/UEFI that might be the source of the problem with booting from the ISO made with Mint's image write. Just a guess on my part and I do not know of anything specific which might cause the issue.

...there is the issue that none of the newer kernels are able to boot, regardless of using Rufus or not (except the 5.10.0-12-amd64 from LMDE5).

Are you dual-booting with Windows? If so, there are several items which come to mind which might be causing issues.

[juannm]

The only practical differences I could see is that Rufus detects that the ISO file is a so-called "hybrid" and asks me to choose which mode I want, which is a curious feature, as I had never been asked about this difference:

I have not used Rufus, but it is my understanding that one must specify in Rufus whether they need the ISO to boot in UEFI mode or in BIOS mode. (That is the limit of my knowledge of Rufus--please do not ask me any hard questions about Rufus. )

The Linux Mint ISO tool creates an ISO that can do either UEFI or BIOS. You do not have to specify ahead of time which one you need. Perhaps that is what Rufus considers to be hybrid? I do not know and am just guessing.

I researched a bit... never a bad moment to learn new things!

This post by the creator of Rufus has a lot of interesting insights: Why are there different options for creating bootable usb compared to a cd?

But more to the point, this phrase (from here) is what made it click for me:

How isohybrid works
Starting in version 3.72, ISOLINUX supports a "hybrid mode" which can be booted from either CD-ROM or from a device which BIOS considers a hard disk or ZIP disk, e.g. a USB key or similar. These isohybrid images contain in addition to the normal CD-based ISO9660 filesystem, a valid-looking DOS-style partition table. So if you simply "raw" copy an isohybrid processed image to a USB flash drive, the BIOS will boot the image directly.

So, this is how most if not all Linux distros publish their ISO files! They not only contain a good old ISO9660 read-only filesystem, but they are also post-processed with isohybrid to add a FAT32-style partition table, and that means that the file can be dd'ed bit-for-bit straight to a USB drive, and still be readable as a disk volume.

Rufus detects this fact, and asks if you want to dd the .iso file as-is to the USB (which would work, rendering a valid but read-only filesystem of some fixed size), this would be the "DD" mode it asks about. Or, it recommends to write it in "ISO" mode, which means opening up the .iso file, and copying its contents (I mean, the actual files) into a cleanly-formatted, read-write FAT32 USB partition.

In "ISO" mode, after copying the files from the .iso file, to make it bootable it adds its own Syslinux to the result, the exact same Syslinux that the contents of the original .iso would expect. That's why Rufus was asking me "hey, this .iso expects Syslinux 6.04/20191223, but I don't have it, do you want me to download it?".

I'm not sure how the Mint USB writer works, but seems that at the end of the day, all USB writers must work in a very similar way. Maybe the Mint writer does have the correct Syslinux version to start with, that's why it doesn't need to download anything from internet.

In any case, none of this things are enough to help me understand where the process goes differently and the Mint writes a non-booting image while Rufus writes one that boots. My only clue is that this Syslinux that Rufus downloaded and wrote, is somehow working better than the one the Mint writer uses, but even that sounds a bit far fetched.

Have you checked to see if your system is running the most recent BIOS/UEFI available? My guess is there might be some type of setting in BIOS/UEFI that might be the source of the problem with booting from the ISO made with Mint's image write.

Yes I tried the updater program that came with the machine, and also checked on the LG website, but sadly the BIOS seems to be in its latest version already.

...there is the issue that none of the newer kernels are able to boot, regardless of using Rufus or not (except the 5.10.0-12-amd64 from LMDE5).

Are you dual-booting with Windows? If so, there are several items which come to mind which might be causing issues.

Yes, I'd like to keep the original Windows partition that came with the computer, so I'm installing Linux on a different partition, which I made with GParted from the live USB itself, before running the install wizard. Which changes are you thinking about? For now, the only thing I changed from defaults in the BIOS, is disabling Secure Boot. Let me know if there are any other settings that typically cause issues, so I check their current value...

[SMG]

Yes, I'd like to keep the original Windows partition that came with the computer, so I'm installing Linux on a different partition, which I made with GParted from the live USB itself, before running the install wizard. Which changes are you thinking about? For now, the only thing I changed from defaults in the BIOS, is disabling Secure Boot. Let me know if there are any other settings that typically cause issues, so I check their current value...

There may be a setting in BIOS/UEFI for fast boot. You want to disable it or have it do whatever is the slowest boot option. That will make sure all the hardware components are registered properly during the boot up. I recently helped someone with a Dell computer and the options were not clear-cut. You can see them and my recommendation in this post.

There is also a power settings in Windows called "fast start-up" that you will want to disable How to turn off fast startup or hybrid sleep in Windows. I've actually participated on topics on this forum where having that enabled prevented the booting/installation of Linux Mint.

Thanks for all the info and the links about the ISOs. I learn something new all the time (and will probably have to read it a couple of times before all of it sinks in).

[juannm]

There may be a setting in BIOS/UEFI for fast boot. You want to disable it or have it do whatever is the slowest boot option. That will make sure all the hardware components are registered properly during the boot up.

There is also a power settings in Windows called "fast start-up" that you will want to disable How to turn off fast startup or hybrid sleep in Windows. I've actually participated on topics on this forum where having that enabled prevented the booting/installation of Linux Mint.

I had all of these options disabled already, I'm afraid. Went on search and capture for BIOS and Windows settings, and I can confirm that Secure Boot, Fast Boot, and other similar options were disabled. I also actually enabled "slow" boot, with a diagnostics screen option in the BIOS, that shows during 3 seconds the hardware info in the same style that older computers did... But more to the point, nothing changed the issues with booting different Kernels.

At the end this issue is a quite complex interaction between the kernel and the hardware. I moved to the Ubuntu ISOs, to try and see if I can install one of them, and now that I have been more aware of these issues, turns out they all (20.04.4, 22.04) fail with exactly the issue commented here:

https://bugs.launchpad.net/ubuntu/+sour ... ug/1842320

The solution of this comment worked for me: https://bugs.launchpad.net/ubuntu/+sour ... omments/48

If you have problems to boot live systems (from USB), I think it can be solved with mkusb

https://help.ubuntu.com/community/mkusb

because it makes the live system use GFXMODE set to 800x600

And it worked. I was able to boot up the live session of Ubuntu 22.04, which allowed me to install it locally and now it is working fine (and with proper drivers!).

Again, we are back at a USB writer program doing things somewhat differently that happens to work!

The fact that mkusb uses GFXMODE set to 800x600 seemed to make all the different for my machine and the "Out of Memory" error. I would suggest that, for maximum compatibility with present and future hardware, the Mint USB Writer is changed to do something similar.

Sadly I think that solution for this issue in Mint will get stale, at least for now... At this point it was urgent for me to have some Ubuntu-based system installed on this laptop, because I need it for working on the road during the whole of June, starting from this evening. So as much as I'd rather use Mint, I'll take whatever I have right now and keep on going with Ubuntu 22.04 for now.

SMG, A thousand thanks for your attention and your timely responses, really!
Kind regards

[mikeflan]

This has been very enlightening. I sure could use a summary of this topic. And I realize I am not the best person to do that, but here is an attempt for others to expound on.

In rare cases where a live install USB created by USB Image Writer does not boot properly, but instead creates a black screen boot loop, it might make sense to try another iso image writing program like Rufus, mkusb, or Balena Etcher. Rufus is a windows program that must be run in windows (or a virtual machine with windows). mkusb is Linux based and probably requires a PPA installation to install (see https://help.ubuntu.com/community/mkusb). I don't know about Balena Etcher.

[SMG]

The solution of this comment worked for me: https://bugs.launchpad.net/ubuntu/+sour ... omments/48

If you have problems to boot live systems (from USB), I think it can be solved with mkusb

https://help.ubuntu.com/community/mkusb

because it makes the live system use GFXMODE set to 800x600

And it worked. I was able to boot up the live session of Ubuntu 22.04, which allowed me to install it locally and now it is working fine (and with proper drivers!).

I don't quite understand how that solved your problem.

There is an option in grub to set and or change the GFXMODE. The default has that line commented out.

Code: Select all

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

Perhaps installing by the method you did it automatically un-commented and changed that line? You can run cat /etc/default/grub to see if that is what happened.

I see some people in that bug report mention changing the initramfs compression method worked for them as far as installing the image.

The issue seems to be only with certain high resolution laptops according to what people have written in the bug report.

The fact that mkusb uses GFXMODE set to 800x600 seemed to make all the different for my machine and the "Out of Memory" error. I would suggest that, for maximum compatibility with present and future hardware, the Mint USB Writer is changed to do something similar.

Considering the default is to have that line commented out, I would think making that change may not be best for everyone.