[syslinux] Advice/directions to users of Syslinux

[Ady]

> Hi,
> 
> Ady wrote:
> > I personally don't like this "hiding" [of CHS], but I understand
> > their reasons to do so.
> > 
> > I think that the "USB-Geometry" section in the wiki should try to 
> > point to the same kind of users.
> 
> But it is in wiki page Hardware_Compatibility.
> Check out the neighborhood.
> If there is a place to - for once - state how a "normal" partition
> table should look like, then there.
> 
> The user of partitioning tools shall rather be directed to
> the text which currently evolves at
>   http://www.syslinux.org/wiki/index.php/User:Scdbackup#New_Common_Problems_Bad_Heritage_on_MS_DOS_disk
> and only at the end of that section, there will be a link
> to Hardware_Compatibility#USB-Geometry.
> 
> 
> > Once the user chooses the partitioning tool, he has to change the 
> > geometry to make it adequate. Whether the alignment is one or the 
> > other, it shouldn't matter (in the context of the Syslinux wiki, and 
> > trying to improve bootability).
> 
> We have strong evidence meanwhile that Ronald's two problem sticks
> both bear deceiving H and S in their end CHS. See
>   ftp://ftp.tristatelogic.com/private/ady/ubcd.0
>      end CHS is  969, 21, 21
>   ftp://ftp.tristatelogic.com/private/ady/oe.0
>      end CHS is  492, 150, 42
> 
> We do not know for sure whether changing the end CHS of
> ubcd to 242,254,63 would fix it.
> But i think everybody will agree that "22 heads, 21 sectors/track"
> is not the best start for a SYSLINUX installation.
> 
 
Perhaps I am not being clear enough.

The common user should avoid playing with individual values for 
START, length or END of partitions or filesystems.

The common user should set a "commonly-used" geometry in fdisk (or 
similar), and maintain it.

Let me put it this way, for a user having problems with the 
partitioning scheme:
1_ Use Nx255x63 geometry in fdisk
2_ create new partition table
3_ create new partition
4_ format.
5_ move on to whatever you want to do.

I already posted in a prior email about 10 or so steps for Ronald, 
with more details, in a more-or-less generic style.

This is what user-friendly partitioning tools are doing.

Nowadays, the default is MiB alignment in almost all user-friendly 
partitioning tools. The user has no idea about specific CHS values, 
LBA or sectors. The user introduces the MB he wants.

The only reason I start (after a backup) with (re)setting the 
geometry is because we are assuming that this could also be part of a 
booting problem.

So, instead of troubleshoot 10^n items, each one at a time, the 
common non-technical eager (impatient) user could receive the "let's 
start anew, with a simple procedure; whatever the source of the 
problem".

I am, perhaps, going to an extreme example, since most problems have 
simpler solutions (like editing syslinux.cfg). But I am trying to 
communicate my point clearer than before, and sometimes presenting 
extreme examples are more useful for such purpose than "middle-ground 
typical" cases.

So, again, instruct the user to correct the geometry to 
"commonly-used values", and leave the rest of the details to the 
partitioning tool default behaviors.

The common user has no intention to start playing with each starting 
point, LBA matching CHS, and whatnot.

A sort of KISS starting point to at least solve the main initial 
problem, for the common non-technical user.

> 
> 
> > In a very broad view, there are effectively two options so to improve 
> > bootability:
> > _ Nx255x63, one-and-only partition with MiB alignment
> 
> I hope for the partitioning tools to guide the user.

Exactly my point.

> 
> But MiB alignment does not match 255x63 cylinders. (Or at least
> only in very large steps. They share no prime factors except
> the block size.)
 
It doesn't matter. My test.img for Ronald had Nx255x63 geometry, and 
STARTing LBA of 2048.

The partition in my test.img ENDed together with the image, but, 
generally speaking, I would not do it that way. For MiB alignment, it 
would end at an entire MiB value, independently of the geometry. The 
partitioning tool would translate MiB to LBA, and then to CHS too.

> 
> 
> > _ ZIP-like geometry, optionally / alternatively using the fourth 
> > partition only.
> 
> That would be option -4 of mkdiskimage.

Correct.

 
> > IMHO, getting into more details with specific CHS values and examples 
> > might derail and/or discourage users, who, after all, just want to 
> > boot their USB and move on.
> 
> Thus the careful escalation of detail.
 
Perhaps, but it might not get to SYSLINUX. It might fail before even 
getting to SYSLINUX in the boot process.

And, not every fail in SYSLINUX is related to inadequate 
partitioning.

And, not every inadequate partitioning scheme has to be somehow 
connected to SYSLINUX. In fact, they aren't. Never.

In other words, the user should not make this kind of relations 
between boot failure, inadequate partitioning and Syslinux.

We are trying to provide useful information, but there is no 
"Syslinux-fault" here. And this should be completely clear to the 
reader (common user).

> 
> > I would say that for Windows users the problem might be, 
> > independently of the geometry, discovering that the USB drive might 
> > contain additional partitions in 
> > the first place (note: Windows normally won't let the user see more 
> > than one partition in USB removable flash drives).
> 
> Even more reason to give them an example with mkdiskimage
> which can be executed more or less blindly.
 
Examples are very welcome and very needed.

But, I don't get it. A Windows user would look for:
_ RUFUS (and site)
_ rmprepusb (and site)
_ 911cd.net
_ reboot.pro
_ user-friendly partitioning tools (and there are a lot)
_ more alternatives that I am probably forgetting at this moment.

And there are tools dedicated to build a (multi)boot USB drive 
starting from ISO images; just that those tools rely on a correct 
partitioning scheme and build on that.

So, IMHO, I don't see a Windows-user looking for mkdiskimage, but I 
could be wrong.

In any case, examples are helpful.

> 
> 
> ---------------------------------------------------------------
> Intermediate summary:
> 
> I defend Hardware_Compatibility#USB-Geometry until more people
> join Ady's opinion that it is more confusing than helping.
> (I count Gene on my side :))
> We both made our points by now.
> The article is sufficiently hidden to do not much harm until
> we come to a final decision.
> 
> I try to bring Ady's points into a new article
>   Common_Problems#Bad_Heritage_on_MS_DOS_disk

I would suggest not using the work "disk". It is frequently 
misinterpreted, specially when used near "MS-DOS". We are talking 
about "partition tables".

BTW, the user should not get the (incorrect) idea that SYSLINUX works 
on traditional MBR only. It works on GPT too. Most of us know that 
already; a common casual user reading the wiki might not.

> which shall make proposals on application level.
> It is evolving at:
>   http://www.syslinux.org/wiki/index.php/User:Scdbackup#New_Common_Problems_Bad_Heritage_on_MS_DOS_disk
> 
> @Ady:
> Did i represent your points sufficiently here ?
> Anything i skipped by mistake ?
> 
 
Don't worry. The wiki is there to be improved.

Regards,
Ady.