Non Booting PCLinuxOS liveCD

[Just17]

OH crikey!

That needs reading a few times  

***

First part:  Hybrid USB ......  so the boot works (isolinux), the initrd launches and runs and the search for the loop image fails, because it did not search all the locations it should have.

That would appear to be a particular failure which might be more amenable to investigation, as it is specific.

It makes me wonder if a disk has to be enumerated in the UEFI/BIOS before it will allow the machine to be booted from it.
That does not explain why it does not search the higher numbered partitions (above sdb5) which it did on sda.

To be honest that behaviour seems to be a bug to me.

PCLOS has settings to allow some 99 partitions to be searched on any HDD, IIRC. (No I did not test above twenty something )

So the question is .....  what is causing the search to be aborted?

One thing that *MIGHT* do it would be a problem reading sdb6.

What about unplugging sdb temporarily to see if it checks sdc fully and moves past sdc5 and then on to sdd? OK they will have new device designations, but you know what I mean.

If the same thing happens on both disks ....  stopping at sdx5 then that would imply a limitation in EUFI I think.

If that was so then one might have to ask if this is peculiar to that manufacturer or if it is a general limitation of UEFI.

Conjecture of course 

[Old-Polack]

OH crikey!

That needs reading a few times  

***

First part:  Hybrid USB ......  so the boot works (isolinux), the initrd launches and runs and the search for the loop image fails, because it did not search all the locations it should have.

That would appear to be a particular failure which might be more amenable to investigation, as it is specific.

It makes me wonder if a disk has to be enumerated in the UEFI/BIOS before it will allow the machine to be booted from it.
That does not explain why it does not search the higher numbered partitions (above sdb5) which it did on sda.

To be honest that behaviour seems to be a bug to me.

PCLOS has settings to allow some 99 partitions to be searched on any HDD, IIRC. (No I did not test above twenty something )

So the question is .....  what is causing the search to be aborted?

One thing that *MIGHT* do it would be a problem reading sdb6.

What about unplugging sdb temporarily to see if it checks sdc fully and moves past sdc5 and then on to sdd? OK they will have new device designations, but you know what I mean.

If the same thing happens on both disks ....  stopping at sdx5 then that would imply a limitation in EUFI I think.

If that was so then one might have to ask if this is peculiar to that manufacturer or if it is a general limitation of UEFI.

Conjecture of course  

I thought you'd like that.

Both /dev/sda and /dev/sdb are external drives, in self powered cases, so removing one is as simple as rebooting and hitting the off switch before the machine posts. Doing just that, with the hybrid image USB stick in place, no burned disk in the optical drive tray, the boot menu from the USB stick is presented, the second option for no splash screen chosen, and all proceeds to the loop image check, as before, but with the previous /dev/sdb removed from the mix, all of the partitions on both remaining drives are checked and the image on the USB stick is discovered, whereupon the boot process continues to the full GUI login.

The hybrid image burned to USB stick works as advertised, in this configuration.

I find it interesting how fdisk perceives the USB stick in this state.

Code: [Select]

Disk /dev/sdd: 15.6 GB, 15606349824 bytes
64 heads, 32 sectors/track, 14883 cylinders, total 30481152 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5d18f039

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *           0      999423      499712   17  Hidden HPFS/NTFS

Disk /dev/sdd1: 511 MB, 511705088 bytes
64 heads, 32 sectors/track, 488 cylinders, total 999424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5d18f039

     Device Boot      Start         End      Blocks   Id  System
/dev/sdd1p1   *           0      999423      499712   17  Hidden HPFS/NTFS

This doesn't do much to solve the problem of why the burned CD doesn't find/see the configuration file, isolinux.cfg, but it's interesting in its own right.

The drive not being searched properly is a 1 TB Seagate drive, originally partitioned with the old version of fdisk, but with additional partitions added by the new (4KB sector aware) version of fdisk. While everything seems to work all right on the drive, I have noted infrequent oddities at various times concerning its partitions, and the main reason I purchased the newer 2 TB drive was to offload everything from the 1 TB drive, then repartition it from scratch using only the newer version of fdisk. I'm just guessing, but evidence would seem to support that this intermingling of partitions from two completely different versions of fdisk is what is causing the loop image search problem, when it is present.

However, just to add a bit of additional confusion to the full story, I normally boot, and install from, liveHDD images on the 13th partition of the 1 TB drive, and have never seen the truncated loop image search when booting from any of a dozen or more possible boot menu entries from that partition's /grub/menu.lst. For a while, I was even booting from three different hybrid .iso images also stored on that partition.

[Just17]

While trying to avoid most of the confusing issues () it seems the failure to do a proper search is down to the structure of one of the searched HDDs.

So I think that can be put aside for now.

***

It appears that the present isolinux is working OK on what it sees as a HDD, but not on an optical drive.

***

That being true, then the error location has been narrowed considerably.

I suppose to lock down the above, it would be helpful to see the results of a Hybrid image burned to a partition of a HDD.
If the problem is only with optical media then it should boot in similar fashion to the USB stick.

BTW ..... was the Hybrid on the USB stick on a partition rather than on the full disk?

Maybe it would be useful to ensure it boots OK from both situations .....  if possible to do.

***

However, just to add a bit of additional confusion to the full story, I normally boot, and install from, liveHDD images on the 13th partition of the 1 TB drive, and have never seen the truncated loop image search when booting from any of a dozen or more possible boot menu entries from that partition's /grub/menu.lst. For a while, I was even booting from three different hybrid .iso images also stored on that partition.

Were any of the selections booted located on a partition of the same HDD greater than sdb5?
(...  or maybe because the initial boot was successful on sdb13(?) the problem was overcome by a different means of accessing the partition ....? )

***

So, if any further tests you manage to perform, come out as expected, the failure is down only to the optical drive.

Which would bring me back to this:

This board would not boot to the generic CD-ROM setting, but on further inspection, I found an option to boot from the TSSTcorp CDDVDW SH-222BB device, specifically. It would seem the newer BIOS version is more precise, and therefore more picky, about how code is actually executed.

No DEFAULT or UI Configuration Found

I came across a remark about this error (not UEFI related). It concerned a USB boot ......

It is likely that your BIOS is not looking at the USB drive to boot first. Go into the BIOS and set the boot order so that the USB device will be detected and boot first. There are also legacy USB settings in most BIOS's so that if set inappropriately the system cannot boot from USB. You need to investigate these options before you go any further.

I know you mentioned different boot order etc but cannot find what you wrote while typing this 

In some BIOSs there is a delay factor to be edited which might help ....  as it seems the optical is not being read for the boot files .....  or I am getting a bit mixed up again .....

Maybe more investigation of the settings in the UEFI/BIOS would suggest more edits to it .....

...  getting lost methinks ....

[Old-Polack]

While trying to avoid most of the confusing issues () it seems the failure to do a proper search is down to the structure of one of the searched HDDs.

So I think that can be put aside for now.

***

It appears that the present isolinux is working OK on what it sees as a HDD, but not on an optical drive.

***

That being true, then the error location has been narrowed considerably.

I suppose to lock down the above, it would be helpful to see the results of a Hybrid image burned to a partition of a HDD.
If the problem is only with optical media then it should boot in similar fashion to the USB stick.

BTW ..... was the Hybrid on the USB stick on a partition rather than on the full disk?

If you look at the fdisk results, you see the "partition" shown for both entries starting at sector 0, which would normally be reserved as the MBR, so the image must be burned to the drive itself and not an actual partition... without an MBR there is no location for a partition table.

Maybe it would be useful to ensure it boots OK from both situations .....  if possible to do.

***

However, just to add a bit of additional confusion to the full story, I normally boot, and install from, liveHDD images on the 13th partition of the 1 TB drive, and have never seen the truncated loop image search when booting from any of a dozen or more possible boot menu entries from that partition's /grub/menu.lst. For a while, I was even booting from three different hybrid .iso images also stored on that partition.

Were any of the selections booted located on a partition of the same HDD greater than sdb5?

All were/are on the same 13th partition, depending on how the OS sees the drive, /dev/sdx13

(...  or maybe because the initial boot was successful on sdb13(?) the problem was overcome by a different means of accessing the partition ....? )

***

So, if any further tests you manage to perform, come out as expected, the failure is down only to the optical drive.

Which would bring me back to this:

This board would not boot to the generic CD-ROM setting, but on further inspection, I found an option to boot from the TSSTcorp CDDVDW SH-222BB device, specifically. It would seem the newer BIOS version is more precise, and therefore more picky, about how code is actually executed.

No DEFAULT or UI Configuration Found

I came across a remark about this error (not UEFI related). It concerned a USB boot ......

It is likely that your BIOS is not looking at the USB drive to boot first. Go into the BIOS and set the boot order so that the USB device will be detected and boot first. There are also legacy USB settings in most BIOS's so that if set inappropriately the system cannot boot from USB. You need to investigate these options before you go any further.

I know you mentioned different boot order etc but cannot find what you wrote while typing this 

Not sure of what you are referencing here. My current UEFI/BIOS has more highly refined selection options than any previous legacy BIOS motherboard has had. On all previous BIOS the setting for CDROM would boot to whatever optical drive was present. In the motherboard manual, there is no mention of a specific optical device being offered as an option, yet it exists in the running BIOS, and when it is shown, the CDROM selection does not work at all. The option for the precise device does work. I suspect the BIOS is newer than the printed manual, and I would guess that if I had two optical drives, (which I do not) I would be able to choose the order which they would be checked for a bootable disk, similar to choosing which hard drive to boot first. That is the only logical reason I can come up with for spelling out the specific optical device.

In some BIOSs there is a delay factor to be edited which might help ....  as it seems the optical is not being read for the boot files .....  or I am getting a bit mixed up again .....

Maybe more investigation of the settings in the UEFI/BIOS would suggest more edits to it .....

...  getting lost methinks ....

Getting me lost, at least.

All my MBs, for many years have been Award BIOS boards. Learning to work within a BIOS is like learning an OS itself. I hate Phoenix BIOS layout, and avoid it at all costs. Award was bought by Phoenix, but wisely they left the layout as it was when it was independently owned. I've only encountered an AMI BIOS once or twice, on machines owned by friends.

That said, and this being an Award UEFI/BIOS, it is mostly familiar, but also includes new territory with many option choices I have yet to explore. I'm just learning it as I need it.

[Just17]

I *think* what I was trying to say is that the position of the optical drive in the list of bootable devices might make a difference ......  according to my interpretation of the quote.

In some BIOSs there would be a second listing, which IIRC defines the devices which are allowed to boot.

I know there were some weird settings in the UEFI I came across that I did not understand, but which definitely impacted on the booting. I did not take any notes so cannot make any enlightening comment 

[Old-Polack]

I *think* what I was trying to say is that the position of the optical drive in the list of bootable devices might make a difference ......  according to my interpretation of the quote.

In some BIOSs there would be a second listing, which IIRC defines the devices which are allowed to boot.

I know there were some weird settings in the UEFI I came across that I did not understand, but which definitely impacted on the booting. I did not take any notes so cannot make any enlightening comment 

I have two separate lists, one for device boot order, which is currently set at USB HDD, TSSTcorp CDDVDW SH-222BB, Hard Disk, in that order. Previously I had the TSSTcorp CDDVDW SH-222BB first on the list followed by the USB HDD, then Hard Disk. In the second list, is the order that the individual hard drives are set to boot. If there is boot code in the first listed hard drive's MBR, that will be the boot drive. If not, the second drive in the list will be scanned for boot code in the MBR, and so on.

Both lists are pretty straight forward, and except for the total number of options being greater, pretty much the same as the older legacy Awqard BIOS.

[Just17]

OK, a short re-cap of what is happening from my perspective ..... using a PCLOS ISO ..

A liveCD will not boot.
A hybrid liveUSB will boot.
A hybrid liveHDD will boot.

The liveCD will boot if the command is entered manually at the prompt.

Other bootable media (Win disc) will boot.

As you mentioned much earlier, it appears that the BIOS is not searching for the required boot files in their present location, but does find them from the manually entered command. It also correctly searches for the loop image if the initial boot is handled by liveUSB.

I am having difficulty imagining why this should be the case.
If it is a naming problem (isolinux/syslinux) then sure it should manifest itself when using the manual command.

Is there any means of introducing a delay in the BIOS recognition or test of the attached devices which might overcome an initial failure to get the result of a search due to the slowness of an optical media search? (might be due to the compression used? maybe an ISO created with lower compression could be checked)

Just a thought that it might be timing out before it finds the needed files ....... and things would have settled by the time you entered the command manually.

If, like the older BIOS, there is a means of selecting a slower 'BIOS' and POST ....  by checking memory and devices for instance .....  maybe this would make a difference, if it is a timing issue.

Just thinking out loud while attempting to make sense of the failure to boot automatically while booting correctly manually ........

[wedgetail]

I know I am late, but did this ever get sorted? I got lost on the last page but it seems there could have been more?        

[Just17]

I guess O-P passed the PC on to a friend without coming to any definitive conclusion.

As I last posted, it appeared to me that the optical media was not 'ready' to be read initially, but was properly accessible after a little time which allowed the manual entry of the command to work.

The UEFI boot process is much quicker than the legacy BIOS and this might be what has influenced it.

Just conjecture on my part of course 

[Old-Polack]

Nope, never did find an answer. The problem is specifically that on the initiation of reading the burned CD the syslinux/isolinux boot code needs to read from the /isolinux/isolinux.cfg file to read the boot stanzas and set up the graphic boot menu for presentation to the user. Either it is not finding /isolinux/isolinux.cfg, or it is finding it but not finding /isolinux/gfxboot.com, or not being able to read isolinux.cfg to see that gfxboot.com is the file it should be looking for. Below is the actual isolinux.cfg from the burned disk, with the ui gfxboot.com reference highlighted. This should be what the error message;

ISOLINUX 3.85 2010-02-20 ETCD Copyright (C) 1994-2010 H. Peter Anvin et al
No DEFAULT or UI configuration directive found.
Boot:

...says it can't find.

-------------------------- start isolinux.cfg ------------------------------------

default LiveCD
prompt  1
timeout 90
ui gfxboot.com bootlogo
label LiveCD
    kernel vmlinuz
    append livecd=livecd initrd=initrd.gz root=/dev/rd/3 acpi=on vga=788 keyb=us vmalloc=256M nokmsboot splash=silent
label LiveCD - No Boot Splash
    kernel vmlinuz
    append livecd=livecd initrd=initrd.gz root=/dev/rd/3 acpi=on vga=788 keyb=us vmalloc=256M nokmsboot splash=verbose
label Video safe mode - FBDEV
    kernel vmlinuz
    append livecd=livecd initrd=initrd.gz root=/dev/rd/3 acpi=on vga=788 keyb=us vmalloc=256M nokmsboot splash=silent fbdev
label Safe boot
    kernel vmlinuz
    append livecd=livecd initrd=initrd.gz root=/dev/rd/3 acpi=off vga=normal keyb=us vmalloc=256M noapic nolapic nopinit fbdev
label Console
    kernel vmlinuz
    append livecd=livecd 3 initrd=initrd.gz root=/dev/rd/3 acpi=on vga=788 keyb=us vmalloc=256M nokmsboot splash=silent
label Copy to RAM
    kernel vmlinuz
    append livecd=livecd copy2ram initrd=initrd.gz root=/dev/rd/3 acpi=on vga=788 keyb=us vmalloc=256M nokmsboot splash=verbose
label Install PCLinuxOS
    kernel vmlinuz
    append livecd=livecd initrd=initrd.gz root=/dev/rd/3 acpi=on vga=788 keyb=us vmalloc=256M nokmsboot splash=silent install
#label LegacyKernel
#    kernel vmlinuz2
#    append livecd=livecd initrd=initrd2.gz initrd=initrd.gz root=/dev/rd/3 acpi=on vga=788 keyb=us vmalloc=256M nokmsboot
#label Memtest
#    kernel memtest

-------------------------- end isolinux.cfg ------------------------------------

Rather than getting dropped to a shell, one gets the Boot: prompt, which will accept nothing other than a typed in boot stanza, starting with vmlinuz. It will not accept any directive pointing it to any configuration file, like one could do with a grub> prompt. Typing in the parts of the second stanza highlighted in red will successfully boot the liveCD.

The fact that the error message comes from ISOLINUX 3.85 2010-02-20 would indicate a problem within the disk, or image, yet the image burned to a USB stick does work, as does the disk, with non UEFI legacy BIOS machines.

The two UEFI/BIOS machines will boot Windows install disks, the openSUSE 12.1 liveCD, UBCD 4.1.1, and UBCD 5.1.1 burned disks, using the same settings that are used with the PCLinuxOS disks that fail to boot correctly. Just to repeat, and clarify, none of the PCLinuxOS burned liveCD disks, that I have, going as far back as the 93a release, will boot normally on either of these machines, (they all boot with the manually typed boot stanza) but all boot normally on legacy BIOS machines.

That pretty much recaps the whole thread, and nothing has changed.

[gseaman]

This message apparently occurs when a livecd powers down before there is a chance to boot. (So, I've read.) Some bios have the opportunity to change the setting in the bios from power saving mode to SATA, or from SATA to ATA. Why this occurs, when it didn't before, I don't know.

Code: [Select]

No DEFAULT or UI configuration directive found
Galen

[wedgetail]

Ooops, I take my words back, in the 64 bit isolinux.bin it is a single message. Using ark it was easy just to scan. I will have to back and check 32 bit.
Checking I do find that it exists, ie the message do come from isolinux.bin.

I deleted my previous post it was far too way out.  

[Old-Polack]

This message apparently occurs when a livecd powers down before there is a chance to boot. (So, I've read.) Some bios have the opportunity to change the setting in the bios from power saving mode to SATA, or from SATA to ATA. Why this occurs, when it didn't before, I don't know.

Code: [Select]

No DEFAULT or UI configuration directive found
Galen

Not disputing that may be the case sometimes, but why would our liveCDs behave differently from other liveCDs, if that was the case here. Were it a power saving mode, it should do that to all bootable CDs equally. I'm also rather confused by the relationship you propose between PSM SATA and ATA. Choosing a setting to differentiate between ATA/IDE and SATA makes sense, but some form of power saving mode wouldn't, or shouldn't, have any reason to particularly care about whether the drives were SATA or ATA, or if it did, would still be a totally different and separate setting.

FYI:

The first setting in the Integrated Peripherals screen for this BIOS turns the OnChip SATA Controller on or off, and is set to [Enabled]
The OnChip SATA Type gives the choices Native IDE, RAID, or AHCI. This is set to AHCI  which allows hot plugging of drives and Native Command Queuing.
That's followed by a switch to enable the SATA3.0 6Gb/s function, which is also set to {Enable}
After that it has much the same for USB functions. Nothing in that section has any mention of anything to do with power settings.

I can't find anything on this board that deals with saving power. Where there are power settings is in the MB Intelligent Tweaking (M.I.T.) section, which is all about overclocking and increasing power to the CPU, RAM and such, which, being intelligent, I keep my sticky finger out of, and stay the hell away from. 

[wedgetail]

Old-Polack
Oi, oi I will change the focus

Created an isohybrid version of pinoc's latest MiniMe and used dd to write the image to the USB stick. On reboot, it did not fail with the expected error message, but rather offered the normal boot menu options. Selecting the no splash 2nd menu item, all goes as normal until it reaches the searching for loop image stage. First it checks /dev/sr0, then /dev/sda1 through /dev/sda11, and /dev/sdb1 through /dev/sdb5, then gives a final [OK] and drops to a limited shell after announcing it could not find the image.

The problem with this is that there are 17 partitions on /dev/sdb, followed by 9 partitions on /dev/sdc, and finally by /dev/sdd on which the hybrid image is actually burned. The image search ended prematurely, and did so at exactly the same place on five successive attempts.

I next burned the hybrid image to disk, thinking the hybrid additions would allow the normal boot menu to appear, but on reboot got the old familiar;

ISOLINUX 3.85 2010-02-20 ETCD Copyright (C) 1994-2010 H. Peter Anvin et al
No DEFAULT or UI configuration directive found.
Boot:

Went back into BIOS and set the USB HDD as first boot device, and the optical drive as the second boot device, left the burned disk in the tray and reinserted the USB stick drive. The end result is that the USB stick image brings up the boot menu, all goes as normal until searching for the loop image, which it now finds on /dev/sr0, (the burned disk, and first item searched) and a normal boot to a live session is achieved.

I am not sure if this is relevant to your new boot system, but the overrun looks too familiar.
I have experienced that overrun in the search more times than I have count on.  When I first came accross your topic here, this stuck in my head but I half dismissed it on the grounds that I could not remember what my problem was.

 I think I remember it was at a time when I was battling with liveHDD generation and Just17 spent a fair bit of time helping with troubleshooting, thinking it was a problem in the liveHDD generator. I will have to find my notes now it is too much of a coincidence, had something to do with USB sticks as well. My memory is bad however as 3 things conspired, one the recent bootloader.pm.

In my case the search string could be over 40 partitions any attempt to try and install to HDD from a liveHDD would fail. no go.  Then it got narrowed down to around 10-11 partitions so to install I would remove a harddrive or two and re-insert them later.  kjpetrie then found the counter in bootloader.pm with a limit of 10 changing that to 99 as Just17 and I have finished testing modified liveCD copies of the 2012.12 ISOs this has fixed my problem with getting the search string over 10.

I will do an experiment make a liveHDD from an unmodified liveCD and try and install on a high numbered drive, will be back ....

[Old-Polack]

wedgetail:

I'm well aware of the bootloader.pm issue, and yes, it does have an effect when loading the USB stick with the dd hybrid image, but that is not the main problem. The USB stick works perfectly on either machine if the 1 TB external drive is turned off temporarily, or isn't attached at all, in the case of the second machine. The problem remains with the burned CD disks from PCLinuxOS images.