8.2-BETA1 sysinstall: No USB devices found
freebsd at jdc.parodius.com
Mon Dec 13 03:36:08 UTC 2010
On Mon, Dec 13, 2010 at 01:53:41PM +1100, Ian Smith wrote:
> On Sun, 12 Dec 2010, Michael Voorhis wrote:
> > On 12/12/2010 11:28 AM, Brandon Gooch wrote:
> > > How difficult would it be for the installer to automatically re-scan
> > > for devices when USB is selected as install or Fix-it media?
> > Ditto this. I do all my OS installs via a USB CD reader and it took me a
> > little while to come up with the rescan-fix.
> This one goes back a while; I got involved in a discusion in questions@
> where Randi provided a fair bit of info on some of the issues here:
> Re: 8.0-RELEASE-i386-memstick fixit - No USB devices found!
> > I don't order rack servers with optical disk readers that I'll only be using
> > once to install the OS, so all the stuff I build is installed from USB disc
> > readers. My initial response was "how can we not know there's a CD reader
> > when I just booted and read the installer from it."
> Ah, perhaps it's not just older kit and/or some types of USB stick that
> have this issue then ..
> > One of the 1st things sysinstall does is run a device scan deviceGetAll(),
> > but that misses the USB device, apparently. The deviceRescan() calls the
> > same function, but preceeds it with deviceReset().
> > All this stuff is in src/usr.sbin/sysinstall/devices.c. I'm not smart enough
> > to make my own install disks right now; what would happen if the reset were
> > inserted in front of the rescan (in main.c) at the beginning of sysinstall
> > execution? That seems to be the only difference between the initial scan and
> > the "option" scan.
> There may be an issue with doing that too: it seems that reset also
> resets other things, in my case losing the disk slicing, labelling and
> choice of distributions that had already been done:
> Re: Installing 8.1-RELEASE from the memstick
> I still don't undersand why memstick images need to be in DD mode (daXa)
> rather than allowing being properly sliced (daXsY), unless it's just the
> clash with sliced da devices indicating 'real' SCSI disks in devices.c?
> I'd love to be able to put amd64 and i386 installers, plus say the
> packages from the DVD, plus somewhere to save dmesgs, on one stick.
I've been trying to do this for quite some time -- I dedicated nearly 4
weeks to trying to accomplish something similar ~6 months ago.
My idea was to have multiple .iso files on a single USB memstick, which
GRUB/MEMLINUX would therefore boot. Things like Kubuntu, FreeBSD 7.x
i386 and amd64, 8.x i386 and amd64, DBAN, memtest86+, Western Digital,
Seagate, Maxtor, Hitachi, etc. disk analysis/repair tools, and a couple
of other ISOs.
To clarify: literally I wanted a single FAT32 filesystem with .iso files
placed on it, with some GRUB/MEMLINUX boot semantics/config files put in
place, to provide a menuing system with information of what ISO file
represented what. You'd select the OS/thing you wanted to boot (see
below website for a screenshot) and off it went. Why .iso files on
FAT32 rather than a dedicated slice for each thing? Because it makes
testing a new release or upgrading an ISO very simple; insert USB stick
in <any OS>, delete old file, copy over new one, edit the GRUB
configuration bits, sync and/or umount, and pull the USB stick.
The tool I was using was this (though it has been updated regularly.
Note that the latest version is 2 days old; I was working with a version
many months ago):
The result: I was able to get things like memtest86+ and DBAN to boot,
and very specific Linux distributions (with a lot of pain), in addition
to FreeBSD. However, FreeBSD would always fail to find the necessary
installation packages/sources/etc. due to "how" the whole booting
process above works. I had to spend a lot of time messing around with
MEMLINUX and the "map --hook rootnoverify (0xff)" parameters and similar
Another problem I ran into is described on that site under the "Boot
Errors" section, blabbing about how the drive has to be defragmented and
the files have to be in contiguous order (I assume this means every
block of data in the ISO has to be in linear order and cannot be spread
across non-linear sectors/blocks of the USB drive).
What I'm trying to say is that basically accomplishing things how I
described above is impossible given the limitations of the PC BIOS
(I have to assume INT 0x13), and that's really too bad given the need
for such a thing in this day and age.
What did I end up doing? Buying multiple HP-brand 4GB USB memory sticks
and dedicating each of them to whatever tool was needed. When visiting
the datacenter I haul with me a large tote of tools, cables, and of
course said sticks.
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable