I built a core-image-sato live image from recent master which when written to a USB stick boots perfectly fine on an EeePC 901, however with the same USB stick plugged into an Acer Aspire One ZG5 netbook, syslinux displays its version banner, the led on the USB stick flashes for a few seconds, but no "boot:" prompt appears.
Darren recommends usb-zip format
Yes, see the USBZIP format instructions in README.hardware.
Marking as needinfo until the USBZIP format is attempted. Another thing to try is forcing the BIOS to treat the USB key as an HDD and not as a FLOPPY - but that option isn't always available.
Paul, Have you had a chance to try the USBZIP format on this device?
Moving this to normal as this single platform should not hold up the release.
I haven't, but I plan to do so tomorrow.
I don't seem to have an option as far as I can tell to use HDD mode; so I went ahead and tried to set up the device for USB-ZIP. I couldn't seem to install mkdiskimage (provided by syslinux-perl) on my slightly outdated Fedora machine, so instead I used the one from the native sysroot (fairly easily found by doing a "cat pseudodone", for reference). Our instructions imply that you should just use the head and sector counts from fdisk and 0 for the cylinders; this just got me "mkdiskimage: /dev/sdc: don't know how to determine the size of this device". Using the real cylinder number reported by fdisk worked. Is there any harm in just telling people to do this in the instructions rather than trying with 0 for the number of cylinders first? One more issue I noticed with the instructions - we need to tell the user to unmount the USB disk at the end, or they might not realise they need to do it or forget. (I can prepare a patch to README.hardware for these if desired.)
Heh, forgot to mention. Once I finished with the instructions the USB disk did indeed boot properly, so I guess this bug is invalid. It may be worth pointing out explicitly in README.hardware that the symptoms may not be "boot error" but a freeze just after the syslinux banner is printed, or just after "loading initrd" (which interestingly is what I now get with the latest images without using USB-ZIP on this netbook).
Hrm, as for the 0 for automatically determining cylinders, I just lifted the instructions from the syslinux usbkey.txt. I haven't had any trouble with it myself. However, there are apparently sticks that fail here. For reference, from usbkey.txt: """ The script "mkdiskimage" which is supplied with the syslinux distribution can be used to initialize USB keys in a Zip-like fashion. To do that, calculate the correct number of cylinders (31 in the example above), and, if your USB key is /dev/sda (CHECK THE KERNEL MESSAGES CAREFULLY - IF YOU ENTER THE WRONG DISK DRIVE IT CANNOT BE RECOVERED), run: mkdiskimage -4 /dev/sda 0 64 32 (The 0 means automatically determine the size of the device, and -4 means mimic a zipdisk by using partition 4.) Then you should be able to run syslinux /dev/sda4 """ I have no objection to adding additional symptoms (I only reported the ones I had seen myself) and making a note to use the cylinder count from fdisk.
Created attachment 421 [details] mkzipimage.sh Perhaps rather than re-documenting this rather painful process, we should instead clean up and add my attached script to contrib/scripts and point to that from the README.hardware? This should probably be augmented with my disk blacklist and device info from ddimage. And this would result in some duplication.... so perhaps ddimage should ultimately accept a -z option which uses the mkdiskimage script? Then again, I believe our bugs opened against the image format in general may result in disk formats that most BIOS will use correctly and this may no longer be necessary. It's just too early to tell. If we want a solution for 1.2, I suggest we just update the README.hardware per Paul's recommendation - but I've attached the script as reference in case anyone reading this benefits from it.
So since this wasn't a bug per se I am marking this NOTABUG. We now have the relevant updated instructions in README.hardware as of revision 6a11c787571230e104699ea83aa50484ec1d8a86, and I have attached mkzipimage.sh to bug #1763 ("more universally bootable live images") so that it doesn't get lost.