Thank you for that. I?ve set up the thinstation-v5.6.1.iso in vm and setup the chroot. I did my first ./build ?allmodules and wrote the iso to usb using lili version 2.0 so that I can boot with older syslinux. I am doing this for the needed hardware profile to build from inside the vm however the usb has been stuck on the syslinux version line with a line following: Thinstation..... for 30 minutes now. Since the version of syslinux is v3.82 the only conclusion is incompatible kernel. Did you use a pae kernel for the build ?allmodules iso? My hardware will not support if you did.... Oh wait, 45 minutes later I got an error message that indicates: Not enough memory to lead map. I have committed to memory what kernel modules are needed to support the hardware. Aside from memory I have several kernel config files I could share. Is there another way to determine a ?hardware profile? for your build environment? Thank you Daryl> On May 13, 2020, at 1:17 PM, Don Cupp <doncuppjr at yahoo.com> wrote: > > ?The DevStation uses a full i686 kernel, but when you recompile the kernel for your old machines, you can change the compatibility. I think the UP(uni processor) kernel might already work for you. I did do some builds for geode. > > > > > > > On Wednesday, May 13, 2020, 10:12:51 AM PDT, Daryl Kuchay <daryl.kuchay at icloud.com> wrote: > > > > > > Thank you, > > Think I have that installed in vm. I was on github page and saw a mention of a devstation iso file and when I clicked on it I saw devstation-6.x.x on its way in. Wanted to get devstation on iso for 5.6.1 if possible? Easier to install to vm. > > When I startup the iso that I did download, TS-5.6.1 installer I get a message that my cpu is too old. I set up on p3 in vm due to having a 586 geode cpu on the target hardware. It lacks the noP instruction to make it full i686. Would rather know sooner than later if cpu is showstopper > > Sent from my iPad > >> On May 13, 2020, at 1:05 PM, Don Cupp <doncuppjr at yahoo.com> wrote: >> >> ?https://sourceforge.net/projects/thinstation/files/thinstation/thinstation-5/TS-5.6.1-Installer-0921.iso/download >> >> Hope those still work. >> >> >> >> >> >> >> On Wednesday, May 13, 2020, 09:45:01 AM PDT, Daryl Kuchay <daryl.kuchay at icloud.com> wrote: >> >> >> >> >> >> Do you have a download link for devstation-5.6.1? Cant find it within files at sourceforge. >> >> Thank you >> >>>> On May 13, 2020, at 11:56 AM, Don Cupp <doncuppjr at yahoo.com> wrote: >>> >>> ?Try ThinStation 5.6(last 32bit version) trade out the syslinux for the older version. Maybe rev the kernel. >>> >>> >>> >>> >>> >>> >>>> On Wednesday, May 13, 2020, 08:38:59 AM PDT, Daryl Kuchay via Syslinux <syslinux at syslinux.org> wrote: >>> >>> >>> >>> >>> >>> Hi All, >>> >>> I used to run webdt.org and this was built to support a tablet computer that hit the market around the late 90?s. DT Research makes them and they get sold to mostly enterprise applications. That being said there are still a few hundred thousand of these in circulation. >>> >>> The hardware is a bit of a hack. Its usb1.1 with a 44 pin flash module on 44 pin pata half height headers. MFGR grounded pin 44 so we cant easily swap out these for generic larger replacements. Average size of this module is 500mb. These originally came with windows ce. Bios is American Micro Devices XpressROM_DT366_0.01.10. Hardware is AMD Geode. Updated Bios is dated 7/21/2005. >>> >>> Syslinux is used to boot many distributions of linux however on this hardware the most recent version of syslinux that I have seen work is version 3.82 or version 3.83. If I try a distribution on v4 or newer of syslinux I see the boot hang on the first line indicating what version of syslinux is being used. >>> >>> webdt.org has been read only for years now and mostly due to the fact that owners of the hardware are limited to old versions of puppy linux, the last to support the aging hardware in the world. This is largely due to the fact that syslinux has updated to the point of no longer supporting the hardware. Grub-0.97 is also the last version of grub that supports the hardware so this is not singular. >>> >>> The irony of the packaging timelines with regard to this hardware are humorous. At the point in time that linux console tools, and namely inputattach, started to support this hardware (penmount serial touchscreen being able to attach to evdev) was about one version behind the point that syslinux started to not support the hardware. Accidental I am sure however it is very hard to make a version fo linux to support this hardware due to these timelines. >>> >>> My questions are: >>> >>> Was this by design? I well understand dropping legacy to advance code but with so many of these in the wild..... ebay dt research or webdt. I see over a thousand of them today in lot quantities. >>> >>> Is there anything I can do to get more modern versions of syslinux to boot on the hardware in question? IE workarounds or modifications to boot lines being used? >>> >>> We are supported by linux kernel up to version 5 on the hardware. It would be nice if other areas of linux followed suit. I have leaned on distribution maintainers to possibly make an iso with older syslinux on it so that owners of the hardware would be supported however many indicate they would not be sure they could support it. >>> >>> If you were me what would you do? >>> >>> Thank you in advance! >>> _______________________________________________ >>> Syslinux mailing list >>> Submissions to Syslinux at syslinux.org >>> Unsubscribe or set options at: >>> https://lists.syslinux.org/syslinux
Several comments... 1. Readers / Subscribers might note that I am replying to the email thread, but I'm not quoting any prior text; intentionally. Please carefully read the whole email before acting on any particular aspect / topic / step. 2. When reading something (a book, or source code, or whatever), I tend to go "forward", usually from the start to the end - call me crazy :o. I don't know anyone that reads a sentence from the last word towards the first one. Any message board of any kind shows the messages from top to bottom, not the other way around. In other words, to anyone participating in this mailing list, please, _avoid_ top-posting!!! Really. 3. Generally speaking, replies should be sent to the Syslinux mailing list's email address (not to private email addresses). Unfortunately, there are several reasons and circumstances that make this less intuitive than it should. Yet, please pay attention. 4. Regarding Unetbootin, LiLi, or whichever other tool that is being used in order to initially boot whichever distro's ISO / installer, the version of SYSLINUX and/or ISOLINUX that they use should not be relevant for the purpose of installing a specific version of SYSLINUX as bootloader on the destination device. To be clear, I don't mean that these tools have no influence at all, but rather that I am suggesting to use the official binaries distributed by The Syslinux Project - see the "Download" wiki page in the official Syslinux wiki. In other words, install the OS in whichever way you can, and then replace the bootloader with the desired version of Syslinux. 5. After downloading the relevant official upstream distribution archives, go back to the Syslinux wiki and search for the "Install" wiki page. 6. The point is that I am suggesting for the OP to replace the version of SYSLINUX that is being used as bootloader with whichever version is known to work in this hardware, independently of the specific package that some Linux distro is using. Beware: if using c32 modules, they should be from the same version of the bootloader; e.g. installing version 3.86 by means of the official upstream binaries / installers / commands shall imply that also the corresponding c32 modules need to be copied to the relevant location, such as "/boot/syslinux/*" for instance, if the c32 modules are in use (in syslinux.cfg). Please be careful not to overwrite ldlinux.c32 when manually copying c32 files (if it exists). 7. In order to evaluate whether any specific version of SYSLINUX successfully boots in this hardware, I would suggest temporarily renaming your "syslinux.cfg" to something else. It doesn't matter that the next step (i.e. booting your OS) would fail; the goal is still to check whether SYSLINUX was successfully installed as bootloader and able to boot in this hardware. The specific "successful" behavior depends on the version of SYSLINUX (v.3.85+ should show at least a "boot:" prompt); the "failure" behavior should be some kind of hang / freeze, even before attempting to load any kernel. Once SYSLINUX works correctly, rename back the cfg file, review the configuration and reboot. 8. There are many other / additional / possible troubleshooting steps. If the above is not enough, please carefully read the wiki. Without having access to the specific hardware, there are too many variables to troubleshoot in one email. Narrowing down the problem would help, and clear info posted in an orderly manner would too (if the wiki is not enough). Regards, Ady.
Regarding the first 3 points in your last email (since I really don't like email quoting... tried it for a while, but it got even more confusing after a while) I have to admit, I did make kind of a mess with the email thread. But on the other hand, there is no syslinux dedicated forum, so people are kinda lost when it comes to communicating and solving syslinux related problems. Let's face it, an email thread is not the same thing as a forum thread. The last few emails are a perfect example of how things can get confusing and mixed up after a few exchanged emails... not to mention the reply thing. On a forum, you reply to a thread, not a person/email address, which is pretty clean-cut IMO. Regards, Jane Todoroski On Thu, May 14, 2020 at 6:03 PM Ady via Syslinux <syslinux at syslinux.org> wrote:> Several comments... > > 1. Readers / Subscribers might note that I am replying to the email > thread, but > I'm not quoting any prior text; intentionally. Please carefully read the > whole > email before acting on any particular aspect / topic / step. > > 2. When reading something (a book, or source code, or whatever), I tend to > go > "forward", usually from the start to the end - call me crazy :o. I don't > know > anyone that reads a sentence from the last word towards the first one. Any > message board of any kind shows the messages from top to bottom, not the > other > way around. In other words, to anyone participating in this mailing list, > please, _avoid_ top-posting!!! Really. > > 3. Generally speaking, replies should be sent to the Syslinux mailing > list's > email address (not to private email addresses). Unfortunately, there are > several reasons and circumstances that make this less intuitive than it > should. > Yet, please pay attention. > > 4. Regarding Unetbootin, LiLi, or whichever other tool that is being used > in > order to initially boot whichever distro's ISO / installer, the version of > SYSLINUX and/or ISOLINUX that they use should not be relevant for the > purpose > of installing a specific version of SYSLINUX as bootloader on the > destination > device. To be clear, I don't mean that these tools have no influence at > all, > but rather that I am suggesting to use the official binaries distributed > by The > Syslinux Project - see the "Download" wiki page in the official Syslinux > wiki. > In other words, install the OS in whichever way you can, and then replace > the > bootloader with the desired version of Syslinux. > > 5. After downloading the relevant official upstream distribution archives, > go > back to the Syslinux wiki and search for the "Install" wiki page. > > 6. The point is that I am suggesting for the OP to replace the version of > SYSLINUX that is being used as bootloader with whichever version is known > to > work in this hardware, independently of the specific package that some > Linux > distro is using. Beware: if using c32 modules, they should be from the > same > version of the bootloader; e.g. installing version 3.86 by means of the > official upstream binaries / installers / commands shall imply that also > the > corresponding c32 modules need to be copied to the relevant location, such > as > "/boot/syslinux/*" for instance, if the c32 modules are in use (in > syslinux.cfg). Please be careful not to overwrite ldlinux.c32 when > manually > copying c32 files (if it exists). > > 7. In order to evaluate whether any specific version of SYSLINUX > successfully > boots in this hardware, I would suggest temporarily renaming your > "syslinux.cfg" to something else. It doesn't matter that the next step > (i.e. > booting your OS) would fail; the goal is still to check whether SYSLINUX > was > successfully installed as bootloader and able to boot in this hardware. > The > specific "successful" behavior depends on the version of SYSLINUX (v.3.85+ > should show at least a "boot:" prompt); the "failure" behavior should be > some > kind of hang / freeze, even before attempting to load any kernel. Once > SYSLINUX > works correctly, rename back the cfg file, review the configuration and > reboot. > > 8. There are many other / additional / possible troubleshooting steps. If > the > above is not enough, please carefully read the wiki. Without having access > to > the specific hardware, there are too many variables to troubleshoot in one > email. Narrowing down the problem would help, and clear info posted in an > orderly manner would too (if the wiki is not enough). > > Regards, > Ady. > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at syslinux.org > Unsubscribe or set options at: > https://lists.syslinux.org/syslinux >
Still trying to get something of a recent operating system to work on the hardware. I apologize for adding to the mess in the thread last night. Point taken. I do have to agree with the idea of a forum though. Last time I used a mail list for actual support was many years ago. In fact this might be why it took me ten years to reach out. These serve as info pipelines these days. Get more than a few people contributing and it gets messy quick. On a forum I can do so much more with formatting and all others on the internet benefit from the information being publicly visible. Thus reducing the involvement from people working on the code. Was wrong on tinycore. They are not using pae, they just dont compile anything ?experimental? in to kernel and most of my hardware that indeed is, needs to be * built in. On TC its not even there so I lost a day trying to make tiny core work. I?ve built over 30 kernels for this hardware. I cant get theirs to work. Thank you to Mr Cupp for suggesting Thinstation however the hardware profile iso I made (via documentation) loaded both vitualbox additions as well as VMware stuff AND firefox. That seems like an error for a iso to sniff hardware. I only have 256mb ram. Tazpuppy although interesting is not usable with pae kernel preloaded and my attempts to utilize vm to load that iso with build scripts leads me to an interface that does not work in vm. Clicks all take place in the upper left of each window that is open. So, for today I have to report that I am still tying to make a situation possible where I can report back to you what happens with the offered suggestions. I will have to build this myself through scripting so please allow for a few days for my ability to report back. I will refrain from jumping out of context on the mail list but this is a limitation. Again, I agree that a forum is the proper place for support. Daryl> On May 14, 2020, at 12:04 PM, Ady via Syslinux <syslinux at syslinux.org> wrote: > > ?Several comments... > > 1. Readers / Subscribers might note that I am replying to the email thread, but > I'm not quoting any prior text; intentionally. Please carefully read the whole > email before acting on any particular aspect / topic / step. > > 2. When reading something (a book, or source code, or whatever), I tend to go > "forward", usually from the start to the end - call me crazy :o. I don't know > anyone that reads a sentence from the last word towards the first one. Any > message board of any kind shows the messages from top to bottom, not the other > way around. In other words, to anyone participating in this mailing list, > please, _avoid_ top-posting!!! Really. > > 3. Generally speaking, replies should be sent to the Syslinux mailing list's > email address (not to private email addresses). Unfortunately, there are > several reasons and circumstances that make this less intuitive than it should. > Yet, please pay attention. > > 4. Regarding Unetbootin, LiLi, or whichever other tool that is being used in > order to initially boot whichever distro's ISO / installer, the version of > SYSLINUX and/or ISOLINUX that they use should not be relevant for the purpose > of installing a specific version of SYSLINUX as bootloader on the destination > device. To be clear, I don't mean that these tools have no influence at all, > but rather that I am suggesting to use the official binaries distributed by The > Syslinux Project - see the "Download" wiki page in the official Syslinux wiki. > In other words, install the OS in whichever way you can, and then replace the > bootloader with the desired version of Syslinux. > > 5. After downloading the relevant official upstream distribution archives, go > back to the Syslinux wiki and search for the "Install" wiki page. > > 6. The point is that I am suggesting for the OP to replace the version of > SYSLINUX that is being used as bootloader with whichever version is known to > work in this hardware, independently of the specific package that some Linux > distro is using. Beware: if using c32 modules, they should be from the same > version of the bootloader; e.g. installing version 3.86 by means of the > official upstream binaries / installers / commands shall imply that also the > corresponding c32 modules need to be copied to the relevant location, such as > "/boot/syslinux/*" for instance, if the c32 modules are in use (in > syslinux.cfg). Please be careful not to overwrite ldlinux.c32 when manually > copying c32 files (if it exists). > > 7. In order to evaluate whether any specific version of SYSLINUX successfully > boots in this hardware, I would suggest temporarily renaming your > "syslinux.cfg" to something else. It doesn't matter that the next step (i.e. > booting your OS) would fail; the goal is still to check whether SYSLINUX was > successfully installed as bootloader and able to boot in this hardware. The > specific "successful" behavior depends on the version of SYSLINUX (v.3.85+ > should show at least a "boot:" prompt); the "failure" behavior should be some > kind of hang / freeze, even before attempting to load any kernel. Once SYSLINUX > works correctly, rename back the cfg file, review the configuration and reboot. > > 8. There are many other / additional / possible troubleshooting steps. If the > above is not enough, please carefully read the wiki. Without having access to > the specific hardware, there are too many variables to troubleshoot in one > email. Narrowing down the problem would help, and clear info posted in an > orderly manner would too (if the wiki is not enough). > > Regards, > Ady. > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at syslinux.org > Unsubscribe or set options at: > https://lists.syslinux.org/syslinux