Kernel Panic during 901 Boot

[Neo_78]

I am trying to boot a remastered DVD of Fatdog 901 in no-Efi mode that has been created using the usual remastering process in the control panel. The inital boot menu with the remastered boot entry loads, counts down 10 seconds, vmlinuz starts but then jumps back to the boot menu. And that cycle continues eternally...

If I choose the manual boot option and type "vmlinuz", the system proceeds to "Decompressing Linux... Parsing ELF... done / Booting the kernel" and then shows the following error message:

Code: Select all

Kernel panic -not syncing : VFS Unable to mount root fs on unknown block (0,0)

CPU: 2PID: 1Comm: swapper /0 Not tainted 6.1.42 #2
Hardware Name: Lenovo 80XL / LNVNB161216, BIOS 4WCN29WW 09/30/2017

Call Trace:...

The system boots normally without problems from a default 901 DVD.

Do you know how this can be fixed? Is there something that needs to be adjusted during the remastering process?

Thank you!

[Neo_78]

Testing this further, I created a new Remastered DVD using this time the EFI-boot option on the same system and then booting in UEFI instead of legacy mode. A very light modification just to test the remastering process in 901.

The EFI boot screen starts normally, it proceeds to the remastered boot option entry, but when I select it and proceed, I get the following error:

Code: Select all

Kernel panic - not syncing: No working init found. 
Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.

CPU: 3 PID: 1 Comm: swapper/0 No tainted 6.1.42 #2
Hardwarename: Lenovo 80XL/LNVB16126, BIOS 4WCN29WW 09/30/2017

Call Trace:
...

Did something change in the remastering process in version 901 compared to 814? I never experienced these issues on the same hardware in 814 or earlier.

Thanks for your guidance!

[Neo_78]

I am able to boot the remastered No-EFI DVD on an old Lenovo Thinkpad from the stoneage. So the issue with the remastering process in 901 appears to be hardware specific...

[jamesbond]

I tried remaster on my system and the ISO boots on qemu.

There are a few steps in the remaster process, at every step you can choose several options.
If you can write down steps and the choice that you take, that would be helpful, otherwise it is impossible to narrow down the causes. Be specific on what exactly you did.

Your kernel panic message means that the bootloader fails to load initrd. This can be caused because the initrd is corrupted, and the most common reason for the corruption, is because you're running out of space when building the SFS or the initrd.

The second most common reason (if boots directly from the remastered ISO) is that is that you edit the bootmenu and that somehow makes the initrd fails to load. But this only makes sense if you boot directly from the remastered ISO; if you just take the vmlinuz/initrd out of the ISO and then configure your existing bootloader, then the suspect will be that bootloader. Certain bootloader is known to fail to load huge initrd.

[Neo_78]

Thanks @jamesbond.

I did not change the bootmenu and left all defaults. vmlinuz and efiboot were copied from the DVD into /tmp and then selected respectively during the remastering process.

I think this might be related to the pulseaudio SFS that I loaded and included in the remastered image. One thing that I noticed was the extremely slow image creation process, which was always super quick in 814 but I also never included larger SFS files.

Is there an alternative way to install the pulseaudio packages?

Let me make another test run without the SFS file to narrow this down and I will report back with exact steps taken.

Thanks!

[Neo_78]

Hey @jamesbond, unfortunately I am still encountering this problem when I am trying to boot a remastered 901 EFI Fatdog image from DVD on this Lenovo laptop.

This particular laptop has 12GB of RAM. I used MemTest86 to ensure that the menory is not faulty and the test does not find any errors.

The laptop boots the default 901 DVD in Efi mode (no savefile) into RAM without problems. I then simply download Chrome / Firefox, from the menu, create an additional user, enable and configure the firewall. I do not install any additional SFS packages. So the modifications are very light. Vmlinuz and efiboot.img are copied from the default DVD into the /tmp folder. I then start the remastering process from the control panel, simply specify the locations of vmlinuz and efiboot.img in /tmp, check the EFI boot option, download the default microcode and do not implement any boot menu changes. So everything is pretty standard. The created iso image is saved in /tmp and I burn it on a DVD using pburn.

Booting from this remastered DVD, I get into the remastered boot menu where I select the remastered entry. I then encounter the following error:

Code: Select all

Booting 'Fatdog64 Remastered'

Loading...

Error: out of memory.

Booting...

Press any key to continue...

Pressing any key will then show the previously mentioned error:

Code: Select all

Kernel panic - not syncing: No working init found. 
Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.

CPU: 3 PID: 1 Comm: swapper/0 No tainted 6.1.42 #2
Hardwarename: Lenovo 80XL/LNVB16126, BIOS 4WCN29WW 09/30/2017

Call Trace:
...

I never encountered this problem with the same laptop in FatDog 814 following the exact same remastering process, which always booted without problems.

Does the laptop not have enough RAM or is the hardware not compatible with the new Linux Kernel 6+ ? Why does the remastering process work with the same hardware in version 814 but fails in 901?

I would appreciate your help to find the root cause of this issue.

Thank you!

[Neo_78]

Investigating this error further, I found a bug report in Ubuntu where a large number of users reported the same problem in their live systems when upgrading from Ubuntu 21 to 22 (kernel version changed from 5 to 6 like Fatdog):

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

https://bugs.launchpad.net/oem-priority ... mments/125

https://www.kubuntuforums.net/forum/cur ... fi-problem

So it looks like the created initrd is much larger in kernel version 6 and the boot loader is therefore running out of memory.

Do you have a suggestion how to effectively reduce the initrd size in Fatdog 901 to solve this problem? Different compression method? Remove non-essential kernel modules?

I appreciate your feedback and ideas!

[jamesbond]

@Neo_78 What is the bootloader you use, and what version? Older grub has a maximum limit of 462MB, I have mentioned this ages and ages ago, c.f. https://oldforum.puppylinux.com/viewtopic.php?t=112372

The solution is to upgrade your bootloader.

If you choose to reduce the size of initrd instead, you need to uninstall packages before you remaster. Run the gslapt package manager to have a feel of the size of the installed applications, then remove those that you don't need, and remaster again.

[Neo_78]

Thanks @jamesbond.

I guess, this would be the boot loader version:

Code: Select all

grub-install --version
grub-install (GRUB) 2.03

Is there a safe way to update Grub from inside Fatdog64 running in RAM?

How do you reliably determine the predetermined memory limit of a specific Grub version that the initrd will have during boot?

I checked the size of initrd on the default 901 DVD using right-click -> properties 573M, which is much smaller than the initrd on my remastered DVD (937M).

How do you reliably determine the expected size of your initrd after implementing all changes but before having to actually run the remaster process in the control panel?

During the remaster process, there is a screen that mentions the folders that will be included: /aufs/pup_rw and /aufs/pup_ro. However, if you right click properties in the file manager, it will show a substantial size difference compared to listing the directory sizes in the terminal with du /aufs/* -shc. What is the most reliable way to determine the size of specific directories to estimate final initrd size?

Another point is the compression option during the remastering process which is set to-comp xz. Is that the format with the highest compression level and hence smallest expected file size? Or are there ways for even higher compression and smaller file sizes?

Thanks for your feedback!

[jamesbond]

Thanks @jamesbond.

I guess, this would be the boot loader version:

Code: Select all

grub-install --version
grub-install (GRUB) 2.03

Nope, that's the version of grub in Fatdog that you're running.
How did you install the bootloader in the first place?

Is there a safe way to update Grub from inside Fatdog64 running in RAM?

How did you install the original bootloader in the first place?
What's the partition layout?
Are you using BIOS or EFI?

How do you reliably determine the predetermined memory limit of a specific Grub version that the initrd will have during boot?

Most version of grub has 462MB memory limit except the ones that have been patched.

I checked the size of initrd on the default 901 DVD using right-click -> properties 573M, which is much smaller than the initrd on my remastered DVD (937M).

That's a shocker. If you only add chrome and firefox, the initrd shouldn't ballon that much. Can you upload your remastered version somewhere so I can take a look (obviously scrub your personal data first before uploading).

How do you reliably determine the expected size of your initrd after implementing all changes but before having to actually run the remaster process in the control panel?

There is no reliable way to do it, because nobody can tell you how much of your data is actually compressible. All you can do is estimate. XZ compression will generally shave 40-50% of the original size, but the only way to know for sure is to actually run the remaster and see how big the result is.

During the remaster process, there is a screen that mentions the folders that will be included: /aufs/pup_rw and /aufs/pup_ro. However, if you right click properties in the file manager, it will show a substantial size difference compared to listing the directory sizes in the terminal with du /aufs/* -shc. What is the most reliable way to determine the size of specific directories to estimate final initrd size?

I'm not sure I understand the question.

Another point is the compression option during the remastering process which is set to-comp xz. Is that the format with the highest compression level and hence smallest expected file size? Or are there ways for even higher compression and smaller file sizes?

XZ is the best there is.

[Neo_78]

This laptop does not have any partitions as there are no hard drives connected. I simply EFI boot Fatdog 901 from the default DVD into RAM mode (no savefile).

If you want to reproduce the initrd size, simply download Chrome and Firefox via the menu installers, create a normal user account, run the remastering process, select EFI boot option, download microcode, select standard initrd, default compression, don't change anything in the boot menu file and create the iso image. The remastered initrd will be substantially larger compared to the default version and that issue started in version Fatdog 901.

[jamesbond]

This laptop does not have any partitions as there are no hard drives connected. I simply EFI boot Fatdog 901 from the default DVD into RAM mode (no savefile).

OK, so the only bootloader there is, is the only on the DVD - created by the remastering process. This bootloader should have no problem loading large initrd.

If you want to reproduce the initrd size, simply download Chrome and Firefox via the menu installers, create a normal user account, run the remastering process, select EFI boot option, download microcode, select standard initrd, default compression, don't change anything in the boot menu file and create the iso image. The remastered initrd will be substantially larger compared to the default version and that issue started in version Fatdog 901.

I just downloaded firefox and chrome. Combined size of the packages is around 200MB. So if you remaster with these two, the size should only grow by about 200MB. But the menu installers actually leave a copy of the the installed packages in /root, for future use. Did you delete these copies? If you didn't, then when you remastered you effectively included two copies of the firefox+chrome - the one you've installed, and the packages in /root. That would add about 400MB to the initrd - which is about the size you got. And no, this is a not new behaviour in 901. It certainly has been like that in 814 and all previous versions of 800 series (perhaps even in 700, I can't remember).

[fatdoguser]

@Neo_78

You might consider using a two stage boot Neo. That's what I do all of the time. A small initrd (that boots quickly into cli) and then 'load' ... whatever, such as a large/remastered fd64.sfs (mines around 1.5GB in size). For my second stage load I simply use a sym link to the fd64.sfs on HDD, but if you have enough ram and a slower storage device (such as a DVD) you can alternatively copy it into ram. Or if you don't mind leaving the DVD in place, and tolerate initial slower start up of programs such as chrome, libreoffice ... whatever then you could also just sym link it to the DVD version and once programs/files had been read/used once they'd likely remain cached and quicker to start on subsequent runs (which is the most memory efficient way, as only what gets used is read into ram).

If you open fatdog help and search for 'bulldog' and select the 'kernel command line parameters' option, there's a plethora of choices. The simplest in your case may be to add a 'basesfs' parameter. Don't burn the large initrd to DVD as-is, first process it by clicking on it to open it up, and then drag/drop the fd64.sfs within that to outside of initrd, and then close the initrd (that will be a lot smaller without the integral fd64.sfs), and add the basesfs option to the boot command line ... and only then burn the modified boot menu, initrd and fd64.sfs to a DVD. Or if you use a usb as a location for 'saves' then the fd64.sfs could be stored on that.

basesfs=ram:.... will copy the fd64.sfs into ram, so the usb can be unplugged once booted, basesfs=direct:.... will leave it and only copy into ram files as/when needed, has to be left plugged in, is the more memory efficient.

After that you add the uuid of the device (blikd command will reveal that), and the filename, so you end up with something like

basesfs=direct:uuid:adfafa-123-657-aaa:/fd64.sfs

perhaps also with a savefile or folder savefile=direct:uuid:uuid:adfafa-123-657-aaa:...... additional parameter alongside that.

There's a package in gslapt called isomaster (IIRC) that can be used to 'edit' a ISO' contents before using something like pburn to burn that to a DVD

Far from a simple single click 'remaster' click and run, more effort required, but a useful learning/understanding exercise such that its 'simpler' next time around.

With 12GB I'd guess you have enough that the dvd and usb could be unplugged (copy to ram, store changes in ram, set event manager to only save on demand) which is the way I suspect you'd prefer.

My own is .... along those lines, except I boot a kernel (vmlinuz) that I've compiled myself directly from kernel.org, and where that boots to a vesa framebuffer. I then overlayfs mount fd64.sfs - where Xvnc is started within that, using spot, so X runs as spot not root, and I then fbvnc into that. And where the overlayfs is set up such that the fd64.sfs is sym linked. I boot to cli first rather than fully automating the startup, so I can sym link in either the original fd64.sfs or my own 'remastered' one, or anything else instead ... as the basesfs. One downside of that is that I have to specify what sfs's get loaded at bootup, aufs dynamic load/unload of sfs's isn't a option as the kernel is built without aufs patches. Another downside is that as X runs as spot you have to su into admin type gui functions. I delete /etc/shadow however so can't even do that, has to be done from another tty using cli, such as chrooting into the chroot as root and running DISPLAY=:0 fatdog-control.panel.sh. On the plus side, I can multi-boot (concurrently) different base systems at the same time on different tty's, and/or vnc into other systems (gui servers). Often have my phone as a vnc server running alongside a local fatdog, and another hard wired/high powered box vnc fatdog session as general browsing etc. is a lot quicker given my laptop is relatively old/slow.

[Neo_78]

@jamesbond yes, I always delete the created packages of both browsers in /root before running the remastering process.

Thanks @fatdoguser. That's an interesting possibility. Let me test that!

[jamesbond]

I created a remaster with devx and nls included, with lz4 compression. I chose the default humongous initrd. This ends up creating a ~2.6GB remaster ISO. This is of course an extreme example. I wouldn't recommend anyone to create a remaster of this size, but this is good for experimenting.

I then tried to boot this remaster on qemu using UEFI (this used grub2 bootloader) - and it failed, with error message "out of memory". Next I tried to boot using BIOS (this used syslinux bootloader) - and it failed too (silently, it just rebooted itself over and over).

Next, I did another remaster, with identical settings, except that I chose "medium initrd" this time. The ISO size is the same, ~2.6GB. This time, however, the boot worked, both with UEFI and BIOS (qemu RAM size was set to 8GB).

So a note for anyone creating huge remasters, please don't use humongous initrd as the bootloaders have size limitations (exactly what's the limit we're not sure yet, that needs further investigation). Thank you for your report @Neo_78,

[fatdoguser]

I created a remaster with devx and nls included, with lz4 compression. I chose the default humongous initrd. This ends up creating a ~2.6GB remaster ISO. This is of course an extreme example. I wouldn't recommend anyone to create a remaster of this size, but this is good for experimenting.

I then tried to boot this remaster on qemu using UEFI (this used grub2 bootloader) - and it failed, with error message "out of memory". Next I tried to boot using BIOS (this used syslinux bootloader) - and it failed too (silently, it just rebooted itself over and over).

Next, I did another remaster, with identical settings, except that I chose "medium initrd" this time. The ISO size is the same, ~2.6GB. This time, however, the boot worked, both with UEFI and BIOS (qemu RAM size was set to 8GB).

So a note for anyone creating huge remasters, please don't use humongous initrd as the bootloaders have size limitations (exactly what's the limit we're not sure yet, that needs further investigation). Thank you for your report @Neo_78,

@jamesbond Isn't Fatdog initrd actually a initramfs? Where a tmpfs is mounted: mount -t tmpfs nodev /aufs/pup_init, and the initramfs is uncompressed directly into that: zcat initrd.gz | cpio -i (or similar).

On my 4GB laptop something like 600MB is grabbed by the video, leaving 3.4GB remaining. Typically half of that is flagged as available for 'front end' [1], so my tmpfs is 1.7GB. So if I tried to load a cpio (extracted initrd.gz) of > 1.7GB ... it would hit a no-space-left situation ... and crash/lock-up. When the fd64.sfs is outside of initrd (? medium initrd) then the initrd content is more inclined to 'fit' into that tmpfs. Whether the fd64.sfs can then also be copied into ram or not depends upon remaining available cache/pages space but where if it doesn't fit the system can still boot, but has to read uncached fd64.sfs contents into ram/cache from disk on a as and when (file by file) basis.

[1] https://www.kernel.org/doc/html/latest/ ... tmpfs.html

The limit of allocated bytes for this tmpfs instance. The default is half of your physical RAM without swap. If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory.

[Clarity]

Hello @jamesbond
Can you PM or post the QEMU stanza you tested for UEFI (I'm also assuming you have audio enabled), please?
Thx

[jamesbond]

So a note for anyone creating huge remasters, please don't use humongous initrd as the bootloaders have size limitations (exactly what's the limit we're not sure yet, that needs further investigation).

Upon further investigation: the size limit is actually 895MB give or take. This can be increased by re-compiling grub, but ... why?

@jamesbond Isn't Fatdog initrd actually a initramfs?

Yes

Where a tmpfs is mounted: mount -t tmpfs nodev /aufs/pup_init, and the initramfs is uncompressed directly into that: zcat initrd.gz | cpio -i (or similar).

Yes, except all of the above is done directly by the bootloader + kernel, no usespace is involved.

On my 4GB laptop something like 600MB is grabbed by the video, leaving 3.4GB remaining. Typically half of that is flagged as available for 'front end' [1], so my tmpfs is 1.7GB. So if I tried to load a cpio (extracted initrd.gz) of > 1.7GB ... it would hit a no-space-left situation ... and crash/lock-up.

Your limit is actually only 850MB (half of 1.7GB), see https://www.lightofdawn.org/blog/?viewDetailed=00128 for the details.

When the fd64.sfs is outside of initrd (? medium initrd) then the initrd content is more inclined to 'fit' into that tmpfs. Whether the fd64.sfs can then also be copied into ram or not depends upon remaining available cache/pages space but where if it doesn't fit the system can still boot, but has to read uncached fd64.sfs contents into ram/cache from disk on a as and when (file by file) basis.

Correct, except the determination whether to load fd64.sfs to RAM or not, is __explicit__, not automatic.

Hello @jamesbond
Can you PM or post the QEMU stanza you tested for UEFI (I'm also assuming you have audio enabled), please?
Thx

To tell qemu to boot using UEFI, you just need to tell it to use UEFI BIOS instead of the regular BIOS. That's all. In Fatdog64, the easiest way to do it is to type qemu-system-x86_64 -bios uefi-bios.bin but this is because Fatdog64's qemu has been configured that way.

In other Linuxes, all you need to do is to install (or download) UEFI BIOS (usually known as OVMF, for example from this place: https://github.com/ilobilo/ovmf-binaries ) and then just point qemu to use that using the -bios parameter, like qemu-system-x86_64 -bios /path/to/OVMF_X64.fd. As for the qemu's other features (sound, etc) - they're identical whether you use regular BIOS or UEFI BIOS.

[Neo_78]

Thanks for your feedback @jamesbond.

So the temporary solution would be to use the "medium initrd" option during the remastering option instead of the default, large "humongous initrd"?

https://distro.ibiblio.org/fatdog/web/f ... nitrd.html

What are the exact implications of booting with the "medium inird"? Are there any essential Kernel modules missing that might limit the functionality of the running system?

Did anything in Kernel version 6 change regarding module size that explains the observed size limitation?

[Clarity]

... In Fatdog64, the easiest way to do it is to type qemu-system-x86_64 -bios uefi-bios.bin but this is because Fatdog64's qemu has been configured that way. ...

Yeah, this is what I wanted to see.

Thanks!

I will try a remaster and attempt remastered ISO file booting in the following (which boots in current/past FATDOGs)

• SG2D

• Ventoy

• iVentoy PXE

• QEMU direct

• QEMU VM booting Ventoy/SG2D's USB

.
Results will be added in a table like this

Forum	------ Bare-Metal ------	------- QEMU (VM) -------	PXE

Distro	Ventoy	SG2D	Native	Ventoy	SG2D	PXE
Fatdog64-901	Y	Y	Y	Y	Y	Y
Remaster-901

Legend for 'N' (No) in table

• (1) - Drops out to GRUB prompt

• (2) - Stops at Console w/o Desktop

• (3) - TRAP/Abend during boot

• (4) - IMG Not Supported by Launcher

• (5) - Requires session-save parm, manually added, to GRUB2 Menu stanza for boot

[fatdoguser]

Thanks for your feedback @jamesbond.

So the temporary solution would be to use the "medium initrd" option during the remastering option instead of the default, large "humongous initrd"?

https://distro.ibiblio.org/fatdog/web/f ... nitrd.html

What are the exact implications of booting with the "medium inird"? Are there any essential Kernel modules missing that might limit the functionality of the running system?

Did anything in Kernel version 6 change regarding module size that explains the observed size limitation?

Hi @Neo_78
There are a plethora of ways in which to structure/boot Fatdog. Humongous has the main filesystem (as stored in fd64.sfs) contained within the initrd file.

The bootloader reads the vmlinuz (Linux Kernel) and initrd into memory and then runs the vmlinuz which then runs the initrd that prepares the fd64.sfs and then runs that (via a switch-root, that is somewhat similar to a chroot).

The difference between having fd64.sfs in the initrd or elsewhere is that it doesn't have to be found. Useful for if you use the likes of PXE (boot via your network card) to boot Fatdog.

Much of choice of the style of structure/boot is directed by how you prefer to run things, how much ram you have, whether you want to save changes or not, or optionally save or not, whether you want to be able to dynamically load/unload sfs's (additional programs) ...etc.

Generally there are no differences to whether you opt to have fd64.sfs in the initrd, or not. Either way generally works, excepting for instance if you were using PXE to boot.

For the humongous there's a risk on systems with lower memory where everything is being run in ram of running out of ram space earlier than other choices. When fd64.sfs is inside the initrd that also gets copied as part of initrd into ram at bootup. When the initrd is then extracted in ram, there's another copy of fd64.sfs. If during operation all files were changed, such as if you 'touched' all file dates, then yet another copy of all of the files will be created in the save area. All running in ram however and things will be quicker than if a mechanical HDD driver was being used as part of the setup.

At the other end you could just run with a small initrd, have no fd64.sfs - but instead have all of the fd64.sfs filesystem pre-extracted into a HDD folder, that is then chroot into, in which case no save folder/file is required as changes are preserved as/when they occur. If you preferred not to have changes preserved, then instead you could extract the fd64.sfs into zram and use that, or perhaps use admin processes that made backup copies of the system and restored that after (or before) each session.

Flexibility of choices. There is no single right or wrong way. A common choice is to set up a layered filesystem where the fd64.sfs is at a lower/bottom layer and is read only, with another layer where all changes are recorded, and where those changes are either preserved, or not, according to your preference. Generally having fd64.sfs outside of initrd is perhaps the more common/better approach - very generally, but also very subjectively. Save areas can be a file, folder, in ram on disk ...etc. again flexibility of choices.

The size limitations haven't in themselves generally changed, however as newer versions of programs come out ... time passes, so code (size) tends to increase, needs more ram/space/processing power. Earlier Fatdog versions might have required 200MB, that has progressively increased and nowadays requires more than twice that, as more programs code/drivers/firmware etc. have been added over time. It's somewhat proportional however, if not even a relatively reducing factor, in 200MB days maybe 1GB of ram was the more common, whereas now at 450MB 16GB of ram is common.

In Fatdog extracting/moving fd64.sfs out of the initrd is easy, you just click on initrd and it opens up, and you can drag/drop (move) fd64.sfs out of that, and then click the close option and the initrd is repacked without the fd64.sfs inside it. That new initrd along with the fd64.sfs should then be used to boot with (which means you have to add additional boot parameters to point to where the fd64.sfs is located).

[Neo_78]

Thanks for your explanation @fatdoguser

[Clarity]

Results after a Remaster of a pristine v901 with a reasonable fleet of updates and add-ons via package manager. Completed remaster with firmware and humongous features. PXE test not done as of yet.
(BTW: Could someone add 'tldr' to FD repo, please? BTOP works fine)

Comment: Maybe launching via Ventoy and SG2D are masking a problem. Being launched via either not only gets to desktop but ALL FD features behave as expected.

Forum	------ Bare-Metal ------	------- QEMU (VM) -------	PXE

Distro	Ventoy	SG2D	Native	Ventoy	SG2D	PXE
Fatdog64-901	Y	Y	Y	Y	Y	Y
Remaster-901 (738MB)	Y	Y	Y	Y	Y

Legend for 'N' (No) in table

• (1) - Drops out to GRUB prompt

• (2) - Stops at Console w/o Desktop

• (3) - TRAP/Abend during boot

• (4) - IMG Not Supported by Launcher

• (5) - Requires session-save parm, manually added, to GRUB2 Menu stanza for boot