No KMS on Frugal installation on HDD(solved)

[jenkem_lover189]

The only way I can seem to get Fossapup64 to boot on USB is by launching it in No KMS mode, otherwise I get a black screen. I don't see the same option on the internal HDD where I have a frugal installation. This particular computer also got a black screen when trying to run Windows 7, but works completely fine with Windows Vista, so not sure what the issue is there.

If anybody knows how I can boot into No KMS on a frugal installation on HDD I'd be very grateful. I'd be able to edit stuff on there using the bootable USB in No KMS.

Cheers!

[rockedge]

The only way I can seem to get Fossapup64 to boot on USB is by launching it in No KMS mode, otherwise I get a black screen.

Hello! Not sure what you mean exactly with "KMS mode"?

Otherwise I think you are trying to find out how boot a frugal installed Fossapup64 from a HDD (hard drive). And you are able to boot Fossapup64 from a USB on the same computer?

What boot loader is on the HDD?

[jenkem_lover189]

I think it's Grub4DOS, but I can verify that for you; how would I check?

I can only boot with the USB if I select, fossapup64 9.5 - No Kernel Mode Setting. If I try to boot just fossapup64 9.5 from the USB I get a black screen and have to restart my computer.

My issue is that I don't get the option to select fossapup64 9.5 - No Kernel Mode Setting on my HDD installation (frugal), so I simply get the option to boot fossapup64 9.5, hence I get a black screen and essentially get relegated to using the bootable USB only.

[rockedge]

Can you post what the Grub4Dos boot stanza's look like? I have seen the black screen before and it had to do with graphics and screen resolution I think. But let's start with the kernel command line from the boot stanza's and what those look like.

[mikeslr]

Our posts 'crossed'. The part of this post below -=-=-=-=-=-=- was written before I knew that your boot-loader was grub4dos. As suggested below, somewhere on your USB-Key will be a file named menu.lst you can open in a text-editor. It will have a line beginning with the term 'kernel'. What exactly does that line say?

If to boot operating systems on your hard-drive using a boot-manager also on that drive, there will be somewhere (usually on the first partition) a boot-loader named either menu.lst or grub.cfg. Stanzas to boot into an operating system will each have a line beginning with 'linux' or 'kernel'. What does that line in the stanza to boot fossapup64 say?

-=-=-=-=-=-=-
From your post it would seem that the arguments used by the boot-loader used to boot Fossapup64 from the USB-Key are not the same as are used to attempt to boot Fossapup64 from the hard-drive. Consequently, It may also be helpful is you provide details regarding what you did to install to both the USB-Key and the hard-drive: what programs/applications were used. And particularly provide us with the "boot-menu" used on your USB-Key. Most likely, the boot-menu will either have the name menu.lst (if you used grub4dos) or grub.cfg (if you used grub2config/Unetbootin). If you used rufus to install to the USB-Key, I think it will be named grub.cfg. Advise which boot-manager was used if neither of those.

Opening a grub.cfg file in a text editor will reveal something like this:

menuentry 'Fossapup64 9.5 (sdd2/fossa95)'{
search --no-floppy --set=root --fs-uuid 0ac443f3-e694-488b-a66f-eb0e79c5573c
linux /fossa95/vmlinuz psubdir=/fossa95 pmedia=usbflash pfix=fsck
initrd /fossa95/initrd.gz
}

The title of a stanza in menu.lst would be slightly different and the line beginning with 'linux' above would use the term 'kernel' instead. My suspicion is that some argument on that line on the USB-Key is missing from its equivalent used to attempt to start Fossapup64 on the hard-drive.

[jenkem_lover189]

For sbd1 (the USB stick), there is a grub.cfg file that contains:

insmod part_acorn
insmod part_amiga
insmod part_apple
insmod part_bsd
insmod part_dfly
insmod part_dvh
insmod part_gpt
insmod part_msdos
insmod part_plan
insmod part_sun
insmod part_sunpc

loadfont /boot/grub/font.pf2
set gfxmode=800x600
set gfxpayload=keep

insmod efi_gop
insmod efi_uga

insmod all_video
insmod video_bochs
insmod video_cirrus
insmod gfxterm
insmod png
insmod jpeg
terminal_output gfxterm

insmod ext2
insmod f2fs
insmod ntfs
insmod exfat

insmod loopback
insmod iso9660
insmod udf

background_image /boot/splash.png
set timeout=10

# https://help.ubuntu.com/community/Grub2/Displays
color_normal=cyan/black
#menu_color_highlight=black/light-gray
menu_color_highlight=yellow/red
menu_color_normal=light-gray/black

menuentry "fossapup64 9.5" {
linux /vmlinuz pfix=fsck pmedia=cd
initrd /initrd.gz
}

menuentry "fossapup64 9.5 - Copy SFS files to RAM" {
linux /vmlinuz pfix=copy,fsck pmedia=cd
initrd /initrd.gz
}

menuentry "fossapup64 9.5 - Don't copy SFS files to RAM" {
linux /vmlinuz pfix=nocopy,fsck pmedia=cd
initrd /initrd.gz
}

menuentry "fossapup64 9.5 - RAM only" {
linux /vmlinuz pfix=ram,fsck pmedia=cd
initrd /initrd.gz
}

menuentry "fossapup64 9.5 - No X" {
linux /vmlinuz pfix=nox,fsck pmedia=cd
initrd /initrd.gz
}

menuentry "fossapup64 9.5 - No KMS (Kernel modesetting)" {
linux /vmlinuz nomodeset pfix=fsck pmedia=cd
initrd /initrd.gz
}

menuentry "fossapup64 9.5 - Ram Disk SHell" {
linux /vmlinuz pfix=rdsh pmedia=cd
initrd /initrd.gz
}

menuentry "Shutdown" {
halt
}

menuentry "Reboot" {
reboot
}

For sda1, the fat32 partition of the internal drive where the bootloader is, there is a grub.cfg file containing the following:

#
set default=0
set timeout=5

set menu_color_normal='yellow/blue'
set menu_color_highlight='black/cyan'

if [ $grub_platform = 'efi' ]; then
loadfont /boot/grub/fonts/DejaVuSansMono18.pf2
set gfxmode=auto
terminal_output gfxterm
fi

menuentry "Puppy fossapup64 9.5" {
insmod ext2
search --no-floppy --fs-uuid --set bd8e6078-8438-4eb6-8c52-3c1ea8aad8f9
echo "Loading vmlinuz"
linux /PuppyDirectory/vmlinuz pmedia=atahd pdrv=bd8e6078-8438-4eb6-8c52-3c1ea8aad8f9 psubdir=/PuppyDirectory pfix=fsck,fsckp TZ=GMT0
echo "Loading initrd.gz"
initrd /PuppyDirectory/initrd.gz
}
if [ $grub_platform = 'efi' ]; then
menuentry 'System BIOS setup' {
fwsetup
}
fi
menuentry "Shutdown computer" {
halt
}
menuentry "Reboot computer" {
reboot
}

Apologies for horrendous formatting!

[mikeslr]

Notice the grub.cfg on the USB-Key has this Stanza:

menuentry "fossapup64 9.5 - No KMS (Kernel modesetting)" {
linux /vmlinuz nomodeset pfix=fsck pmedia=cd
initrd /initrd.gz
}
nomodeset colored blue above for emphasis.

Currently, the stanza on the hard-drive reads:

menuentry "Puppy fossapup64 9.5" {
insmod ext2
search --no-floppy --fs-uuid --set bd8e6078-8438-4eb6-8c52-3c1ea8aad8f9
echo "Loading vmlinuz"
linux /PuppyDirectory/vmlinuz pmedia=atahd pdrv=bd8e6078-8438-4eb6-8c52-3c1ea8aad8f9 psubdir=/PuppyDirectory pfix=fsck,fsckp TZ=GMT0
echo "Loading initrd.gz"
initrd /PuppyDirectory/initrd.gz
}

You can copy it with a new Title such as menuentry "Puppy fossapup64 9.5 - No KMS (Kernel modesetting)"{
and change the linux line to read:
linux /PuppyDirectory/vmlinuz nomodeset pmedia=atahd pdrv=bd8e6078-8438-4eb6-8c52-3c1ea8aad8f9 psubdir=/PuppyDirectory pfix=fsck,fsckp TZ=GMT0 #### colored for emphasis only

or just add nomodeset to the current stanza.

Following are a couple of observations:
I suspect that you used Unetbootin to install grub2 to your USB-Key because the stanzas all have the argument ' pmedia=cd'. It should read 'pmedia=usbflash. Sometimes identifying the media as a cd when it isn't prevents booting. But as it hasn't in your case, perhaps it's best to not 'fix it'.
All the Stanzas on the hard-drive's grub.cfg identify the media as a hard-drive, i.e. pmedia=atahd. That's normal since currently that's the default. However,
read this post, https://www.forum.puppylinux.com/viewto ... 183#p97183 and that thread and decide whether you may be better off if a Puppy on your hard-drive operated as if it were on a USB-Key. The post explains how to make the change.

p.p.s. Not that Fossapup64 is a bad system. It's one of my 3 favorites. But by now it's 3 years old; and my Fossapup64 has been substantially updated. So before you get 'deep into the weeds', do you have any computing interests other than an ordinary User may have? We'll be glad to recommend other, perhaps newer, Puppys.
FYI, several updates to Fossapup64 have been published. The two best known, most commented by fans, are F96-CE4, viewtopic.php?t=8392, and Fossa64-Mid, viewtopic.php?p=94956#p94956. Each has advantages and disadvantages.
You should also know that every Puppy includes an invaluable tool for finding out the particulars of the computer it is run from: Menu>System>Pup-Sysinfo.
And, by the way, to the Forum.

[jenkem_lover189]

or just add nomodeset to the current stanza.

I did this and it worked! I've been at this for weeks messing with different OSes, removing RAM sticks, swapping SATA cables, etc. Thank god for Linux and users like yourself!

do you have any computing interests other than an ordinary User may have? We'll be glad to recommend other, perhaps newer, Puppys.

Honestly, I just wanted to get this old computer up and running to mostly modern standards. I'll probably be using it mainly for some web surfing and media, which is why I got the PVM it's hooked up to. I didn't realise how much incompatibility there is between this old hardware and the software that is available now.
Seems like such a simple fix, but honestly I can't thank you enough, even though it looks so simple I wouldn't have figured it out by myself. Now I'm more interested in understanding why I have to use nomodeset, something to do with legacy graphics hardware and issues with software?

Also, I don't really understand how Fossapup64 9.5 works, why does it load into RAM even when installed on a HDD? I'm kind of intrigued how it actually operates. I only installed it because I was told it's good for old systems, and I'd always wanted to check out a Linux OS. Doesn't seem so bad on the other side, bit more flexible than Windows in my extremely short experience. Still trying to find my way around and coming to terms with the more hands off approach. I don't know if I'll do much with it to be honest, considering my use case.

[williwaw]

why does it load into RAM even when installed on a HDD?

it's the basic way puppy works no matter which kind of media it is installed to.

Unlike Windows or large Linux distributions that install thousands of individual files on your drive, Puppy puts only a few compressed files that are like “Zip” files in Windows (this method is called a “Frugal” install for the efficient way it uses the computers resources). When Puppy boots up, the SFS files are copied into ram memory and Puppy runs completely from ram.. The original compressed files are “read only” so they always remain in like new condition. This goes a long way into making Puppy more stable, secure and bullet proof than other operating systems.

When you make changes, download files, add programs or create documents, etc. they are saved into another file/folder called the save file or save folder.

viewtopic.php?t=5314

viewtopic.php?t=6526

[mikeslr]

Just to 'flesh-out' williwaw's post a bit. But note two things (1) this is a 'lay-man's view' and (2) written before my first cup of coffee; so details are 'fuzzy' and I'm not in the mood to hunt for my posts which explored this for those details.

Puppys are very good at managing RAM. They divide RAM into 'active -- my term' and 'Cache'. The files copied into RAM at boot-up are copied into Cache and indexed. Only those actually needed are copied into 'active' as and when needed, and dropped when not. You can see what's happening by opening Menu>System>PupSys-Info Click it's Menu>Devices>Memory. You'll note that PupSys-Info reports the amount 'Cached' distinguishing it from 'Actual'. I think 'Active' is a more accurate term: cache basically being RAM used as 'Storage', while 'Actual' is actively changing as you make changes and programs run.

My recollection is that loading the Libreoffice-Suite.sfs [215 Mbs compressed in Storage, decompressing would use about 640 Mbs] only reduced the Active RAM by 37 Mbs. Of course, if I opened, say, LibreOffice Writer and began to create or modify a document 'Active' RAM would have to be used for the components needed and the document being created.

The SaveFile or SaveFolder you create to preserve changes --customizations, settings, applications you install-- is not copied into RAM. It is only mounted and indexed.

As to why Puppys work the way they do: Barry Kauler created the first Puppy about 20 years ago; perhaps borrowing some from Knoppix Linux. At that time the hard-drives were occupied by the Windows OS, and sold with about 128 Mbs of RAM. Adding another 128 cost almost as much as the computer. There was no easy way to use any other operating system with that computer --microsoft would have preferred none-- except that to install Windows computer manufacturers had to purchase a 'master cd' and run it. So, a computer's bios had to allow running an installation CD. The original Puppys took advantage of that 'loop-hole' and ran entirely from a CD --using the computer's peripherals [Keyboard, mouse, sound-card, monitor] and RAM: neither needing or using the hard-drive. Skipping the steps which lead to today's Puppy, today when you 'install' a Puppy to a hard-drive you'll find on the hard-drive exactly the same system files as if it had been written to a CD. Only the modules needed to permit booting (from a USB/Hard-drive vs. CD/DVD) differ.

[wiak]

Also, I don't really understand how Fossapup64 9.5 works, why does it load into RAM even when installed on a HDD?

That's more of a legacy from days gone by. I have no idea why the default is still to load into RAM since most modern computers use fast hard drives and it is a waste of RAM. However, on your older computer there may be an advantage still since the hard drive on your machine may be very slow in which case it will be more responsive with the sfs files loaded into RAM first prior to actually being used. The drawback is that you will have less RAM available for actual operations thereafter - a kind of no-win situation compromise really. Personally I never load any OS sfs files into RAM prior to use (though have that non-default option in KL distros I use) since my hard drive is fast enough and I consider RAM to important a resource.

I believe Puppy Linux distro does not NEED to first load its sfs files into RAM before using them. It has (from recollection) a pfix=nocopy grub kernel line option that could be used to prevent that RAM sfs storage happening, but maybe, yes, on really old computer that will not work so well. Depends.

[mikeslr]

Wiak, of course, is correct. You can prevent the contents of Puppy's "core.sfs" --the one which contains the file and windows manager, and usually all or most user-applications and 'infra-structure tying everything together-- from being copied into RAM by including the 'nocopy' argument in the boot instructions. Your 'linux' line now has the argument pfix=fsck,fsckp. That can be changed to pfix=nocopy. I think it can also be changed to pfix=fsck,fsckp,nocopy. I'm not sure how many arguments, separated by ',' can follow pfix=.

fossapup64's "core.sfs" --AKA 'base.sfs-- is the one named puppy_fossapup64_9.5.sfs.

But as wiak also noted that may be a disadvantage if your hard-drive is slow. The 'Rule of Thumb' is that operating from RAM is at least 10 times faster than having read from a Sata drive. As I wrote elsewhere Puppys are very good at managing RAM. See the more technical discussion here, https://www.forum.puppylinux.com/viewto ... 91#p100591.

There is no 'absolutely best cure-all'. Every choice is a trade-off. But the choices provide the User with great flexibility. Using the nocopy argument, only the files essential to providing functionality and access to applications are in RAM. Using the pfix=ram argument means everything will be in RAM and after boot-up from a USB-Key, the Key can be unplugged. See this thread, https://www.forum.puppylinux.com/viewtopic.php?t=9384.

There's another choice you may want to consider: ozsouth's remaster of Fossapup64 named Fossa64-mid. https://www.forum.puppylinux.com/viewto ... 956#p94956. It's core.sfs is smaller and its components are newer. A User has the choice of 'fleshing it out' with whatever applications ran in the original.

[bigpup]

Using the pfix=ram argument means everything will be in RAM and after boot-up from a USB-Key, the Key can be unplugged.

Puppy Linux installed on a USB stick as a frugal or live install.
Puppy Linux always loads al the Puppy OS SFS files into RAM. That is normal operation.

pfix=ram tells the boot process to not load the Puppy save file/folder.

Now if the save file/folder is on the USB stick.

This would allow removal of the USB stick, because the USB stick does not need to be connected, it is not accessing the save.

The save file/folder is never loaded into RAM
But in normal boot. The drive it is on is mounted and always needs to be, so it is read/write capable at all times.

If the save file/folder is on a different drive from the USB stick booting from and normally using the save..

When completely booted to desktop.
The USB stick could be removed.
The save is accessed from a different drive.