> > In message <BLU0-SMTP1383C5798F6C577E5FFF368BA40 at phx.gbl>, > Ady <ady-sf at hotmail.com> wrote: > > >> With respect to all of the actually important stuff however, I may have > >> missed it all, but I don't recall having read or seen an explanation of > >> what Ady & everybody else finally figured out about all this... > > > >There was at least one email that requested to execute some fdisk > >commands on the problematic USB drives. I don't recall having seen > >the result. Without it, we can only have an educated guess by > >carefully reading your reports. > > If there is still information you need in order to fully get to the > bottom of this case, PLASE let me know what else you still need.As I wrote already, we don't really "need" more information. At some point I offered to continue with some additional steps, so to make your USB drives bootable in the future, with their full capacity, on your own control about what "Live" system to put in there. It's up to you. The code in Syslinux won't gain anything, just you.> > >Also the FAT VBR should indicate the "hidden sectors" (aka. "sectors > >before") with a corresponding 63. If the values don't match, strange > >things will eventually happen. > > OK. Are you saying that this critical matchup was NOT present in or on > the originals Clonezilla, UBCD, and OpenELEC USB sticks that I had in my > possession before I started this whole thread? You know, the ones that > booted find on other machines (but not on the GA-M55Plus-S3G) ?We have no specific information about those USB drives (not even an "fdisk -l" and similar commands), and we don't know exactly which BIOS settings were used in each test. We also don't know how exactly you wrote those USB drives with the specific tools (UBCD, etc.). In addition, The Syslinux Projext doesn't write the code for the BIOS of any of the tested mainboards. If we have to go one item at a time so to eliminate it from the potential culprits, we could be writing long emails for several more weeks. So, what exact combination is/was making this mess?; we don't know. We do know that using adequate BIOS settings and an adequate partition scheme, it boots.> > >Generally speaking, the BIOS itself has to support (understand) the > >values that are being used in the MBR. > > Yes. But what exactly did we determine that GA-M55Plus-S3G is failing > to support?We don't have information about the failing USB drives, and we don't know which BIOS settings are/were being used.> > >With the adequate values, the MBR and the VBR still need to contain > >the correct "executable" code. > > Yes, but I assume that was all OK at the outset, because again, those > three sticks were booting up just fine on other machines... just not > on the GA-M55Plus-S3G.Well, initially, the USB drives were still partially booting. At some point, they stopped *at all*. Remember my expression "We seem to go backwards". Assuming that the USB drive is still in the same condition (and assuming no "wear out" is part of the problem), then the BIOS settings changed during your tests. So, again, your other systems might have different BIOS settings, or their BIOS versions might be more tolerant or flexible for different CHS values, or... See my point?> > You have been very good and through in answering and describing all of > the many things that _could_ go wrong or that _might_ go wrong in > different situations & cases. And I thank you for that. But my > question was more specific: Have we determined what actually *did* > go wrong, in my case? I mean yes, I admit that early in this thread > I may perhaps have posted some info or test results that might possibly > have been either misleading or outright incorrect, due to my lack of > clear understanding the exact/true semantics of the various boot- > related setting in my BIOS, but I feel that I have a crisp and clear > understanding of those now, have confugured those properly now, and > yet two of the three USB sticks that I started with ... the two that > I did now overwrite during the course of these investigations... > *still* do not boot on the GA-M55Plus-S3G but still *do* boot on > other machines I own. So what exactly and specifically is ``wrong'' > with those two sticks (which contain UBCD & OpenELEC)? That was my > question.I am going to repeat what Genec requested at some point. Please post the result of (replace 'sdX' with the adequate device): 'fdisk -l -c=dos -u=cylinders/dev/sdX' and 'fdisk -l -u=sectors /dev/sdX' where 'sdX' is (are) the problematic device.> > >The test.img replaced the potential "unmatching bits" in your USB > >drive. The "hello world" (which is a testing module included in > >official Syslinux which can be used by anyone) was a way to test > >whether SYSLINUX itself had a problem with your mainboard. It also > >included an adequate installation of SYSLINUX so to avoid a problem > >in Clonezilla Live's script (which is already being improved). > > So to be clear, you are affirmatively asserting that Clonezilla (2.2.0 > and also 2.2.1) contains problematic "unmatching bits"? Which bits > exactly? Do we know? The "hidden before" number in its VBR is > different than where the Clonezilla partition actually ends up?We would be assuming. We don't know how some potential mismatch value got in there. There are too many "unknowns".> > >The first test.img proved that the USB drive can actually boot your > >mainboard, and that SYSLINUX works in it. The second test was to > >check whether Clonezilla can actually boot correctly (or if, instead, > >there are additional problems). > > So the question is: Do we know, specifically, what ``brokenness'' > existed/exists within Clonezilla that your test.img components > replaced/overrode. you know, in order to make the thing work in the > end?Only partially. But whatever could be incorrect in those USB drives, we can't blame it entirely on any particular "Live" software (Clonezilla, UBCD,...). In fact, currently there is no proof that any one of them had something to do with the issue.> > >Forcing LBA for the partition type was one of several considerations, > >which might or might not had helped. > > Is it worthwhile to conduct one more test in order to find out if that > part helped or made no difference?Regarding that detail in particular, currently I would say it is not worth it, IMHO. But if you want to at least provide the result of the aforementioned 'fdisk' commands...> > >If we could answer what exactly makes one mainboard boot OK and the > >other to fail in just one email, then I guess that entire websites > >and forums specifically dedicated to booting issues would be almost > >never visited. > > I am asking the more limited question: What do we now know, specifically, > that causes this board (GA-M55Plus-S3G) to *not* boot sticks that other > systems happily boot. >If you want to provide the result of the fdisk commands, perhaps we can eventually know what exactly is wrong; no promises. More importantly, eventually you might be able to actually use those USB drives again, without having to wonder whether they might stop working in some additional system, or whether some data in them might be lost. Regards, Ady.
Ronald F. Guilmette
2014-Jan-22 08:27 UTC
[syslinux] After USB boot problems on Gigabyte GA-M55Plus-S3G
In message <BLU0-SMTP46982596DE9C2639CEB6B078BA40 at phx.gbl>, Ady wrote:>I am going to repeat what Genec requested at some point. Please post >the result of (replace 'sdX' with the adequate device): > > 'fdisk -l -c=dos -u=cylinders/dev/sdX' >and > 'fdisk -l -u=sectors /dev/sdX' > >where 'sdX' is (are) the problematic device.I have done both of the above commands now, for each of the two USB sticks that I still have and that still don't boot on the Gigabyte motherboard. One of these has a recent vintage Ultimate Boot CD on it and the other has a recent vintage OpenELEC on it. In each case, I captured both stdout and stderr, together in one output file. Please find the following four files here: ftp://ftp.tristatelogic.com/private/ady/ ubcd.0 -- results of the first command shown above, when executed against the UBCD USB stick ubcd.1 -- results of the second command shown above, when executed against the UBCD USB stick oe.0 -- results of the first command shown above, when executed against the OpenELEC USB stick oe.1 -- results of the second command shown above, when executed against the OpenELEC USB stick If you have specific questions about my BIOS settings, please ask. In general, all settings are "good" for booting a bootable thing from a USB stick. How do I know? Because I had to get _some_ version of Linux running on the box in order to obtain the four command results you requested. And how did I do that? By putting ArchLinux(Live) onto one of my other USB sticks and then booting the GA-M55Plus-S3G from that stick. Regards, rfg P.S. I just now found the message you left for me in that FTP directory. Thank you for your kind invitation, but I do not do IRC.
Thomas Schmitt
2014-Jan-22 08:46 UTC
[syslinux] After USB boot problems on Gigabyte GA-M55Plus-S3G
Hi, Ronald F. Guilmette wrote:> what exactly did we determine that GA-M55Plus-S3G is failing > to support?It appears to be related to the choice of CHS addressing with the FAT filesystem. This opens the door for misperceived factors of heads per cylinder and sectors per heads. My current suspicion is that the partition end did not expose the effective factors in its end CHS address, so that the filesystem and the BIOS were not using the same factors. (Alternatively the FAT system could be in sync with the exposed factors, but the BIOS hates them because they are neither 64,32 nor 255,63.) Aha, your fdisk -l results are posted now: ubcd.0 : Geometry: 22 heads, 21 sectors/track, 1016 cylinders (because end CHS is 969, 21, 21) oe.0 : Geometry: 151 heads, 42 sectors/track, 1021 cylinders (because end CHS is 92, 150, 42) Both sticks show very unusual factors for heads and sectors which are hardly intentional. If BIOS gets confused like fdisk, then the failure to find files is quite plausible. ------------------------------------------------------------- Could you please exercise what is described for Linux in http://www.syslinux.org/doc/usbkey.txt and check whether mkdiskimage -4 /dev/sda 0 64 32 prepares a problematic stick for a normal installation of Clonezilla, which then boots ? This might involve the need to learn how to perform the advised mkdiskimage run on systems other than Linux. Such examples would be valuable for the wiki improvement. (What is a usual address of a stick on MS-Windows ? "E:" ?) I understand that the mkdiskimage option -4 is not what is advised in Gene's wiki enhancement. So please also check, whether it works without that option. http://manpages.ubuntu.com/manpages/maverick/en/man1/mkdiskimage.1.html Have a nice day :) Thomas
Mattias Schlenker
2014-Jan-22 08:49 UTC
[syslinux] After USB boot problems on Gigabyte GA-M55Plus-S3G
Am 22.01.2014 09:27, schrieb Ronald F. Guilmette:> In message <BLU0-SMTP46982596DE9C2639CEB6B078BA40 at phx.gbl>, Ady wrote: > >> I am going to repeat what Genec requested at some point. Please post >> the result of (replace 'sdX' with the adequate device): >> >> 'fdisk -l -c=dos -u=cylinders/dev/sdX' >> and >> 'fdisk -l -u=sectors /dev/sdX' >> >> where 'sdX' is (are) the problematic device. > I have done both of the above commands now, for each of the two USB > sticks that I still have and that still don't boot on the Gigabyte > motherboard.-l just lists. Ady wants to see the geometry of the affected drives. Regards, Mattias -- Mattias Schlenker - Redaktion + EDV-Beratung + Linux-CD/DVD-Konzepte August-Bebel-Str. 74 - 04275 LEIPZIG - GERMANY Bitte fuer geschaeftliche Telefonate vorzugsweise die VoIP-Telefonnummer +49 341 39290767 verwenden, da ich diese aufs Mobiltelefon routen kann!