2012.2 install went fine. But

[Grandpa]

OK here it is www.pastebin.com/YCT2Ce49

[pinoc]

Hi Grandpa,

you said you edited the menu.lst during the installation, why would you do that? The live-session, installation-session, and first boot-session are all different setups having their own dedicated routines and one should not interfere at all here as this may cause unpredictable results. In fact, the installation steps on the KDE2012.02-iso are modified such that the boot menu has its final form only after the second reboot, so doing after a normal installation the boot menu will look like this:



already providing the titles you wanted. I wonder if you would have the same issues described earlier after a fresh and unmodified installation of 2012.02 since I have no idea what effects editing the menu.lst during the installation may have 

but maybe all this is not the reason for your problems and AS can find and help out looking through the pastebin-log. 

have a nice day!
-p.

[Just17]

the boot menu has its final form only after the second reboot

That is news to me 

On your pic there is no entry for the non-fb boot .......  because by default the entry has an error which prevents it being displayed on the Grub list.
This situation has lasted a long time.

Why would the user be given the opportunity to edit the menu.lst (boot entries) if doing so was going to cock things up?
I have one small FAT partition, about 100MBs, on which I have a Grub install. This is in the default list during install as "Windows". It is obviously wrong, and so it gets edited.
Also I edit the non-fb entry so it will display ......  replacing the hyphen with a space or undescore.

In addition I might add, that editing the entries from the default "linux" will cause some oddities when new kernels are installed (or at least used to, as I haven't installed a new kernel for some time).

[pinoc]

the boot menu has its final form only after the second reboot

That is news to me 

On your pic there is no entry for the non-fb boot .......  because by default the entry has an error which prevents it being displayed on the Grub list.
This situation has lasted a long time.

Why would the user be given the opportunity to edit the menu.lst (boot entries) if doing so was going to cock things up?
I have one small FAT partition, about 100MBs, on which I have a Grub install. This is in the default list during install as "Windows". It is obviously wrong, and so it gets edited.
Also I edit the non-fb entry so it will display ......  replacing the hyphen with a space or undescore.

In addition I might add, that editing the entries from the default "linux" will cause some oddities when new kernels are installed (or at least used to, as I haven't installed a new kernel for some time).

thanks for the info on the missing non-fb entry, wasn't aware of that and will try to fix it on the next iso.
-p.

[AS]

About BOOT_IMAGE, all I have found is:

http://forums.debian.net/viewtopic.php?f=10&t=32405

   From a quick google search it looks like something that was introduced by KNOPPIX and its clones to point the kernel to a compressed image file on a LiveCD. You should have no need for it on any modern system.

and:
/usr/src/linux-3.2.7/Documentation/x86/boot.txt

In addition, some boot loaders add the following options to the
user-specified command line:

  BOOT_IMAGE=<file>
        The boot image which was loaded.  Again, the meaning of <file>
        is obviously bootloader-dependent.

A "grep" of the whole kernel source tree, doesn't return any reference about BOOT_IMAGE, same for initscripts related files, rc.sysinit, linuxrc .... therefore, from my point of view BOOT_IMAGE is just a label ... actually unused from PCLinuxOS.

[Old-Polack]

Hi Grandpa,

you said you edited the menu.lst during the installation, why would you do that? The live-session, installation-session, and first boot-session are all different setups having their own dedicated routines and one should not interfere at all here as this may cause unpredictable results. In fact, the installation steps on the KDE2012.02-iso are modified such that the boot menu has its final form only after the second reboot, so doing after a normal installation the boot menu will look like this:


already providing the titles you wanted. I wonder if you would have the same issues described earlier after a fresh and unmodified installation of 2012.02 since I have no idea what effects editing the menu.lst during the installation may have 

but maybe all this is not the reason for your problems and AS can find and help out looking through the pastebin-log. 

have a nice day!
-p.

I do. It ultimately ends up looking like this;



Sorry for the blur, but it's a real camera quick shot of my actual boot menu, taken just a few minutes ago, specifically for this posting. When scrolled, one will find 57 total boot choices, all of which are functional. Every entry, except the chainloader ones, was edited during the installation process as outlined previously. The new installation's grub is installed to the new / partition, and the first menu.lst stanza copied to the boot partition's master menu.lst. The chainloader entries were added to my master menu.lst through manual editing of the file, as root.

If I didn't edit the boot stanza's of each installation, it might be a bit hard to choose which of the 57 linux menu options would boot the specific installation I desired at the moment. With multiple installations of the same version of PCLinuxOS, with different installed apps and purposes, I really don't think that relying on the default naming policy of the installation scripts would work well for me.

[pinoc]

 
I guess there is only one PCLinuxOS boot menu like this in the world

[AS]

I guess there is only one PCLinuxOS boot menu like this in the world

  ... mine actually do have 9 items ...  

[AS]

back on Grandpa issues    from his computer dmesg:

Malformed early option 'acpi'

I will discuss this one on a separate thread, because don't want hijack this thread.

DMI: Gateway DX4720-03/MS-7399, BIOS A7399NG2.202 08/06/2008

That's the current installed BIOS version, there exist an update but refer explicitly to CPU Q8200, I think it would not be beneficial here:
http://support.gateway.com/us/en/product/default.aspx?tab=5&modelId=2287

Kernel command line: apm=off acpi=off mce=off barrier=off ide=nodma idewait=50 i8042.nomux psmouse.proto=bare irqpoll pci=nommconf BOOT_IMAGE=PClinuxOS_2012.2 root=UUID=9b10f7c2-e1ce-4d55-bc27-e900b6849be2 splash=verbose nokmsboot vmalloc=256M pci=nommconf acpi=on resume=UUID

the kernel parameters actually in place (this was from "safeboot" selection)

Misrouted IRQ fixup and polling support enabled
This may significantly impact system performance

One of the parameters, irqpoll ?,  is properly recognized but note that this will affect overall performance.


there are a few entries like this, don't know it this is a fix or a bug.

pci 0000:00:03.1: PME# supported from D3hot D3cold
pci 0000:00:03.1: PME# disabled

Googling around it seems that the machine do have some issue around apic, but it's not visible right now.

Grandpa,
edit your /boot/grub/menu.lst and add as last three stanzas the followings: (use copy & paste)

Code: [Select]


title TEST-NOLAPIC
kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=TEST-NOLAPIC root=UUID=9b10f7c2-e1ce-4d55-bc27-e900b6849be2 splash=verbose nokmsboot vmalloc=256M resume=UUID=4d65bcd3-0be1-49e9-b9d5-9fb09f4749a5 vga=788 noapic
initrd (hd0,4)/boot/initrd.img

title TEST-NOAPIC
kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=TEST-NOAPIC root=UUID=9b10f7c2-e1ce-4d55-bc27-e900b6849be2 splash=verbose nokmsboot vmalloc=256M resume=UUID=4d65bcd3-0be1-49e9-b9d5-9fb09f4749a5 vga=788 nolapic
initrd (hd0,4)/boot/initrd.img

title TEST-MCE
kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=TEST-MCE root=UUID=9b10f7c2-e1ce-4d55-bc27-e900b6849be2 splash=verbose nokmsboot vmalloc=256M resume=UUID=4d65bcd3-0be1-49e9-b9d5-9fb09f4749a5 vga=788 mce=off
initrd (hd0,4)/boot/initrd.img


save, reboot, test all new entries one at a time, if you are able to boot, post again the file /var/log/dmesg

[pinoc]

and I have only 3 entries in the boot menu, but 18 virtual machines...  

[Old-Polack]

and I have only 3 entries in the boot menu, but 18 virtual machines...  

Trust me, you don't even want to know how many of those I have. 

[AS]

and I have only 3 entries in the boot menu, but 18 virtual machines...  

Trust me, you don't even want to know how many of those I have. 

I have only 15 ... 

[Grandpa]

OK!  I copied and pasted what you wanted.  The first two would boot.  The third would not.  It ended in a kernel panic.  The last lines looked like the ones I posted before.  The first one seemed to boot the fastest with less pauses.  The second one had more pauses and more lines.  But they both booted and the mouse connected to the kvm switch worked fine.  I am booting with the first one right now.
My dmesg is here  http://pastebin.com/XiFVd4EB

[Just17]

Grandpa,
edit your /boot/grub/menu.lst and add as last three stanzas the followings: (use copy & paste)

Just in case it causes confusion .......  check the title of the stanzas against the boot option used ......

[AS]

OK!  I copied and pasted what you wanted.  The first two would boot.  The third would not.  It ended in a kernel panic.  The last lines looked like the ones I posted before.  The first one seemed to boot the fastest with less pauses.  The second one had more pauses and more lines.  But they both booted and the mouse connected to the kvm switch worked fine.  I am booting with the first one right now.
My dmesg is here  http://pastebin.com/XiFVd4EB

The dmesg refers to the first one, (unfortunately I have inverted the titles between the first and the second)

Kernel command line: BOOT_IMAGE=TEST-NOLAPIC root=UUID=9b10f7c2-e1ce-4d55-bc27-e900b6849be2 splash=verbose nokmsboot vmalloc=256M resume=UUID=4d65bcd3-0be1-49e9-b9d5-9fb09f4749a5 vga=788 noapic

The dmesg look good, at least I can't see anything very wrong, it report the following, but you can safely ignore it.

[Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

Now, try to test both entries (TEST-NOLAPIC and TEST-NOAPIC) for a couple of days or so, theoretically the second one should be less intrusive ... (which really use nolapic flag),  report back any adverse effect.

You can safely delete the last one, titled TEST-MCE, from menu.lst.