Opened 15 years ago
Closed 15 years ago
#5197 closed bug (invalid)
USB Flash Drive not recognised at boot; works fine in Haiku
Reported by: | casm | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | System/Boot Loader | Version: | R1/alpha1 |
Keywords: | WebDT Geode USB | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
I have a 1GB no-name USB flash drive that I use for booting experimental OSes on my WebDT 366 (Geode). If I `dd' a bootable ISO image (say, PuppyLinux 4.3.1 for this device from http://bit.ly/7Qz4rv) to it and boot with the flash drive connected either directly or via a USB hub to the WebDT, the OS boots from the USB drive without issue.
Using the same method to boot Haiku (from a nightly or release image) fails. However, under the installed version of Haiku on the same hardware platform, I can insert the flash drive and Haiku recognises and automounts it.
syslog and `listusb' output is attached. The flash drive in question is the device named "SMI CORPORATION" "USB DISK'.
Attachments (2)
Change History (5)
by , 15 years ago
Attachment: | webdt366_listusb.txt added |
---|
by , 15 years ago
Attachment: | webdt366_syslog added |
---|
follow-up: 2 comment:1 by , 15 years ago
Component: | Drivers/USB → System/Boot Loader |
---|---|
Owner: | changed from | to
follow-up: 3 comment:2 by , 15 years ago
Replying to mmlr:
What image are you using? Note that our ISOs aren't (yet) hybrid MBR/ISOs so you can't use the ISOs for booting USB sticks.
Well, that explains that ;) I'm currently using the Alpha 1 image (from http://mirrors.ibiblio.org/pub/mirrors/haiku/releases/r1alpha1/haiku-r1alpha1-iso.zip) for testing. Makes sense that it only boots from CD.
Anyway, the problem is that our boot code/MBR doesn't provide a valid partition table and the (broken) BIOS assumes to boot from an "active" partition which isn't there. The problem is assuming a partition table in that way is broken because there's more than one partitioning system (think GPT or just custom boot code). Nothing we can do about other than faking a partition table. It's not a USB problem anyway.
Can we move to or add the option to build hybrid MBR/ISOs? I bring this up because I'm testing on physical hardware that has three boot options: USB CD-ROM, USB flash drive, or the proprietary internal almost-but-not-quite-IDE SSD (equivalent to /dev/hda). I'd like to be able to test nightlies as well as spec builds out of svn, but the only practical way to do that is via USB flash - having to burn CDs on a regular basis would severely limit my ability to test effectively.
I'm pretty sure this problem is logged already, but I can't find the ticket.
Yeah... I searched before filing, but couldn't find it either.
comment:3 by , 15 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Replying to casm:
Can we move to or add the option to build hybrid MBR/ISOs?
As soon as someone does the work. The setup is rather simple, but needs some tinkering.
I bring this up because I'm testing on physical hardware that has three boot options: USB CD-ROM, USB flash drive, or the proprietary internal almost-but-not-quite-IDE SSD (equivalent to /dev/hda). I'd like to be able to test nightlies as well as spec builds out of svn, but the only practical way to do that is via USB flash - having to burn CDs on a regular basis would severely limit my ability to test effectively.
Just take the raw images and put them on the flash drives. They are made for such use.
Anyway I'm going to close this one as invalid, as it doesn't really match any of the existing problems.
What image are you using? Note that our ISOs aren't (yet) hybrid MBR/ISOs so you can't use the ISOs for booting USB sticks.
Anyway, the problem is that our boot code/MBR doesn't provide a valid partition table and the (broken) BIOS assumes to boot from an "active" partition which isn't there. The problem is assuming a partition table in that way is broken because there's more than one partitioning system (think GPT or just custom boot code). Nothing we can do about other than faking a partition table. It's not a USB problem anyway.
I'm pretty sure this problem is logged already, but I can't find the ticket.