Bootable OS disk for RC apps ??

[rperkins]

Hi
Is there a bootable iso ( probably linux based ) that has common RC apps preloaded?

I'd love to have one. Would help with people having usbasp driver Java, and other installation issues.
I was wondering is anything close to this available ?

My thinking is:
1. a bootable image that can be installed on a flash drive or burned to a cdrom ( TinyCore linux ??)
2. Incudes wifi connection utility ( TinyCore supports this )
3. bootable image has a partition that can be accessed from other OS to facilitate moving files around ( havent thought this through but it probably wouldnt work on a CDR installation) . Also persistence between boots ( again tinycore supports this )

4. short list of apps

avrdude
java ( open source version )
eepe/companion9x
kkmulticopter flash tool
Taranis needs ?

What do you think ?

[ShowMaster]

I've sort of brought this up a few times. I think the issue is the fact that many of the apps can be downloaded and used by individuals but can't be pre installed for the masses.
Other options like flashing from the sd card are in the works.
My thoughts were if I had the ability, was to have a ISO file or boot up file that would look for a certain folder with specific files in it to auto install and run. This would install the programs and required drivers. To use it we would on our own download the programs and drivers to maybe a thumb drive or hdd folder. The boot file would look for that path.
You get the idea. The boot up file would not have anything with it that could be forbidden.
Something like a Bart's CD as I remember using once.

I may be way off base with the above thinking but there must be some reason why your idea hasn't been done so far?


Sent from my iPod touch using Tapatalk

[Rob Thomson]

I think that while a good idea - it takes allot of effort to maintain this sort of thing.

No idea who will do it

Sent from my GT-I9300 using Tapatalk

[rperkins]

thanks for the replies. I looked at Tiny Core linux last year after christmas and am back looking again. I'm really just getting familiar with it. I agree that maintaining it would require a lot of work and it would need to be limited to files that could be distributed . I was sorta hoping something was already out there. Tiny core has extensions (packages) but it doesnt include what we would need.
Been specifically looking at Core Plus ( around 72MB) http://www.tinycorelinux.net/

[rperkins]

I went ahead and asked for guidance on their forum
http://forum.tinycorelinux.net/index.ph ... 0.msg98822

[ShowMaster]

I really like the idea. I'm challenged in that area but posting for help on various forums is a great idea.
I think the Taranis and rumored 9XR Pro are working towards making the FW and other upgrades more user friendly and less computer knowledge required. At least for normal FW upgrades.
However, with the many other RC programming requirements happening every day like FPV and Quads as well as the new smart TXs conning on line, a master pgm/driver boot cd or thumbdrive, or ISO could be a good thing.
As Ron pointed out, it will require someone or persons to support the updates. Much like er9x and openTX.
Hopefully someone reading this will jump on board and make it happen. Until then we're fortunate that soon er9x and opentx will be easier for most to upgrade.



Sent from my iPod touch using Tapatalk

[rperkins]

I worked on this over the weekend.

I have a 55MB bootable .iso file that can be burned to a CDR that has the kkmulticopter tool loaded on it.
it should also be able to be loaded on a flash drive, but I havent tested that yet. 95% of the testing was in a virtual environment.

it includes avrdude with libusb so that a usbasp device will work. kkmulticopter tool uses java so openjdk was used

I plan to add eepe/companion 9x but havent worked through the best way for inclusion of the qt libraries

55 MB doesnt get you wifi connections, a web browser, or persistent storage, but all that is attainable. It just takes more room ( and time ).

It is just a start. When I burned it on a CDR I had to use the TinyCore linux boot option of waitusb=30 at the bootloader. If it just boots up to a command prompt that is the issue. This can be automated also

The goal is to be usable by the person who has trouble getting windows drivers installed. we aint there yet , but it is a start. try it out if you want .

EDIT - I added a weblink in the next post. These urls will not stay valid
NOTE -- I added another source. I'm curious which server one is better( the files are the same)
http://9xrprogrammer.com/images/kkmulti.iso ( 600KB/s capped speed but probably steady )
http://perkosolutions.com/kkmulti.iso ( hosted content on 1and1 , probably bursty)

[rperkins]

I got a version of eepe working if you want to give it a spin. it came in at only 28MB. Definitely not ready for prime time yet. I created a stub with the current main issues and links to downloads and the src code

http://9xrprogrammer.com/index.php/rc-bootdisk

Pretty soon I will be asking about whether small specialized downloads would be preferred over a single large iso that supports everything ( estimated under 200MB )

Also will be wanting to know what is a 'stable' pull from eepe/c9x/kkmulitcopter.

lastly will we want things like the arduino environment or the avr-burn-o-mat tool on the iso that have java

probaby will have eepe /c9x on a single iso as they both use the qt devel environment.

would consider other tools but dont want to add any other environments ( like mono )

Wondering what cheap prototype board I can get that simulates the Taranis hardware to test out c9x/taranis.
I dont have a taranis. Are there driver issues getting taranis updated as well ? I really havent been following it too close,afraid I'll want to have one

well thats the roadmap till I run out of gas

[jtaylor]

I haven't seen anybody posting about driver problems on Linux. I know I'm not having any problems with my self compiled versions of Companion on openSuse 12.3 and 13.1. To upgrade firmware you do need the dfu-util package (http://dfu-util.gnumonks.org/) which, depending on your distribution, you may have to compile yourself as I did. But unless you are running Ubuntu you have to compile Companion yourself and anybody that can do that probably won't have a problem getting dfu-util installed and solving any other problems that come up.

The problem I see with a Linux iso to upgrade firmware on the Taranis (or 9x I guess) is that it would need to contain all the network drivers so Companion can download customized versions of the firmware from the server. Otherwise it would need to contain a generic version of the firmware and put out a new iso every time there is a firmware upgrade, or provide instructions for the user on how to download the firmware using a native installation of Companion and provide it to the Companion running on the iso (which probably would not be practical for many users).

Although after openTX 2.0 with the new boot loader I wouldn't expect anybody would have problems updating firmware on the Taranis.

[rperkins]

The problem I see with a Linux iso to upgrade firmware on the Taranis (or 9x I guess) is that it would need to contain all the network drivers so Companion can download customized versions of the firmware from the server..

Hello
Thanks for the Reply.

yes the disk needs network access. Currently it is provided for wired ethernet. Tiny core linux has a wireless package that includes native ljnux wireless drivere,ndiswrapper, and the firmware blobs needed to support wireless connections. I havent tested that yet but realize it is a necessity . Estimated additional size of iso to support wireless is 50MB

My question about installing drivers for the taranis was more geared towards the windows user. I know the usbasp drivers for the 9x/9xr are troublesome to install in modern windows OS and was wondering if taranis users in windows had driver installation issues.

Thanks

[jtaylor]

Drivers to flash the Taranis (not the ones needed to read and write the eeprom) seem to be the biggest problem for Windows users. Getting Zadig to install the STM32 Bootloader driver seems to be a real problem for some/many? people, especially if they only have USB 3 ports. While I mostly use Companion on my Windows 7 laptop to edit models, pull logs, and download sounds I have no personal experience with flashing it on Windows as I use one of my Linux desktops to flash it and haven't bothered to try to load the Windows STM32 driver.

In the past getting live CD wireless support working had been problematic, especially for older usb network adapters that needed downloaded firmware, but the latest System Rescue and Knoppix CD's seem to have really good support, even for older adapters.

As I said, once openTX 2.0 comes out with the new bootloader, upgrading firmware should no longer be a problem for anyone (well, maybe a few). However, to get to openTX 2.0 will require loading the current way at least once. So, assuming you get a live CD with a version of Companion capable of flashing the Taranis, it would be good to include a generic 2.0 firmware on the CD that could be used to get the new firmware/bootloader installed the first time. That would be a real help to those that have problems flashing, or haven't been able to flash at all.

[rperkins]

Hi

Thanks for the very good information regarding Taranis. I had read about the upcoming bootloader but was unaware of the challenges of getting the drivers installed in windows and the usb3 issue. I may have to upgrade some 5 year old mobo's huh .

I wold guess that the wireless tools on Tiny core would be compatible with knoppix. Normally it is the newest adapter that cause the most problem as the upstream kernel/other sources have not implemented them yet. found this thread which links to a half updated wiki entry listing the supported devices.
http://forum.tinycorelinux.net/index.ph ... 10.60.html

Yes a single use case is part of what I imagine. As long as the user has the ability to create a CDr and allow his computer to boot from it, He can determine that his hardware is sound and his trouble is the installation of drivers on his native windows system. Yes if they have a non supported wireless configuration they may have to use a different computer or plug in a network cable.

Sure some people may want persistent storage on a bootable flash drive to keep their RC apps ,models,settingm etc completely portable and isolated from their main OC, but I dont think that is the main use case .

I am slowly building this up. now back to work for me

[jtaylor]

I will be interested in seeing how it goes getting Companion compiled and running on tinycorelinux and the size increase from including the necessary libraries. I had considered that the best way might be to compile a static linked version, but Companion Make is complex enough that I'm not sure how much work it would take to static link it.

As a test I used elf statifier to create a pseudo static version of the current unstable (git/next) Companion and dfu-util and was able to get it to run in a tinycore VM. I had to disable address space randomization in tiny core with echo 0 > /proc/sys/kernel/randomize_va_space to keep it from segfaulting, but after that Companion seemed to run ok.

Now the down side.....Companion went from a 10 MB dynamic linked executable to 48 MB as a Statifier executable and dfu-util went from a few K to 2 MB.

I have never been able to get usb ports to work on my VM so I was unable to test if it would actually talk to the Taranis so I booted a system rescue CD and it also ran the statifier Companion (again I had to disable address space relocation). I connected the Taranis and was able to read both the firmware and the eeprom from the transmitter. I really didn't want to try to flash it with the unstable Companion, but have no reason to think it wouldn't work.

Just throwing out the results of some experiments in case it will help.

Jim

[Rob Thomson]

Drivers for taranis are soon to be a non issue.

The whole flashing system will be changing.

Sent from my GT-I9300 using Tapatalk

[rperkins]

Hi
Thanks for the information.

I initially started down the static path, learning as I went. Read that to build a static qt app, that qt had to be built statically. Attempted to build qt statically but failed. Not smart enough to just build the pieces needed, but diid manage to avoid compiling the tests and examples.

Looked at the dcore build of tiny core which repackages debian binaries but dcore is too bleeding and not well enough documented for me to use due to my lack of detailed knowledge about tiny core.

So then looked at current tiny core but no qt there. qt does exist in tc (tiny core) 4.7. Maintainer is not currently available to update package but pointed me to his build scripts. Scripts needed work due to changes in qt's download scheme and the way the tarball is packed.

Currently using tiny core 4.7 which includes qt and openjava (for kkmultitool). Eepe is qt app and it compiles and works. Companion9x has at least one more dep, which is phonon. May get a crack at c9x tonight.

Been working on the automation tools tzctools and ezremaster as i go so the details of each app are fresh in my mind. Had to buikd avrdude twice due to problems with ver 6. Got avrdude,eepe,kkmulti fairly set except for icons in the toolbar.

I'm willing to give the static builds more attention to save space although i was Pleasantly surprised at how small the libs actually were on tc. Plus if eepe and c9x are both on the same disk the libs may actually be smaller than 2 static builds.

I use libvirt/kvm/qemu vm and usb passthrough works . This is in linux. I have been wondering if windows 8 supports a free, as in freedom or beer, vm that has usbpassthrough. Then the end user wont even need to leave windows.

Have given any of the iso's i created a spin ?

[jtaylor]

I'm using VirtualBox on 64 Bit Windows 7 and it has usb passthru, but I've never been able to get it to work reliably. I haven't tried any of your iso's yet. I only fly planes and have a Taranis so can't test any of the apps but I will download them and take a look.

[rperkins]

Thanks for the reply
thats good info on virtualbox. I was wondering if windows would let you have access to the port. This is something to follow up on later

Maybe you'll wanna wait till I get c9x sorta working before you spin up one of my iso's

I did get companion to compile on TC . it took me awhile to compile the xerces-c and get the precompiled version of xsd installed so that c9x saw it. c9x weighed in at 7.8MB but stripping it slims it down a little . Of course that doesnt include the libraries but I think the ones to run it arent very large over the ones neeed for eep ( qt)


I notice I will need the dfu-util. My question is once I get it compiled can I use this development board I have to verify the functionality of dfu-util as needed by taranis. I got one of these free and havent done anything with it.
http://www.st.com/web/catalog/tools/FM1 ... 2/PF253215
http://en.wikipedia.org/wiki/STM32#STM32_F0

My goal is not to have to buy the taranis but be sure that my iso will support the taranis.

I dont think this little board will hold the entire firmware of the taranis but hopefully there is a process where I can upload something to it to verify the workings of dfu-util. If I could do that from within the c9x application , that would be even better.

thanks

[Kilrah]

I don't think the F0 series has a DFU-compatible USB bootloader, only the F2/F3/F4.

[rperkins]

Got an update to this: Would like some feedback - Thanks

This disk incudes eePe, Companion9X, Multicopter Flash tool. Also includes avrdude and dfu-utils to communicate with the targets. Iso file is 61MB and loads completely into memory( around 200MB). Should run fast even in older computers. Includes desktop icons. Does not support wireless network connections. Does not include sam-ba for the sky9x board. does not support usbhid programmers. You need a network connection to download the firmwares.

Tested on 9xr and kkboard. I dont have a taranis so do some flash reads before attempting to write . compiling dfu-utils was straight forward so I dont expect any issues.

Link to downloads
http://9xrprogrammer.com/index.php/rc-bootdisk

screenshot of tiny linux

Next up is to add wireless support, remove unneeded icons and tailor the prefs of the apps to the directory structure, and of course documentation ( especially how to copy it to a flash drive the 'tinycore linux' way, which will give persistence across reboots.

What else is needed/missing/wanted ?

[jtaylor]

I took your bootdisk for a test drive to try out Companion. First loaded it in a Virtualbox VM on my Windows 7 laptop. Companion came up and since the VM has virtual ethernet I was able to download the Taranis firmware from the build server. Couldn't test connection to the Teranis because I've never been able to get usb passthru to my VM to work.

Next I booted it on an older desktop pc. Brought up Companion and connected my Taranis with power off and was able to read the flash from the transmitter and save it to a file. Really didn't want to test flashing it back, but see no reason why it wouldn't work. Next I connected the transmitter powered on and attempted to read the eeprom. Got a message that Companion couldn't identify the transmitter. That was because TC did not automount the eeprom and SD card drives. I mounted them manually and then Companion was able to read the eeprom from the transmitter. Again as I was going flying today I didn't want to try writing it back, but again see no reason why it won't work. I umounted the two drives manually before I disconnected the Taranis.

To be usable by anybody that is not familiar with Linux, TC will either need to mount and umount the drives automatically or have instructions for the user to do it. You have to be root to mount them using the command line, but it looks like there is a GUI mount tool that will let the TC user do it (if he knows the device or mount point). It looks like TC sets up mount points on /mnt (/mnt/sdb1, /mnt/sdc) for all the drives it detects, but you have to figure out which ones are the eeprom and SD drives. In my case I have quite a few partitions so I had mount points in /mnt for /sda1 through sda9, sdb1, and sdc. Looking at the kernel ring buffer with dmesg it was easy enough to tell that /dev/sdb1 was the SD card and /dev/sdc was the eeprom and mount them manually, but the devices will be different for other machines.

Looks good. I only have a Taranis so could only test Companion, but the other apps come up and run, I just don't have hardware to test them.

Jim

[rperkins]

1.I booted it on an older desktop pc. Brought up Companion and connected my Taranis with power off and was able to read the flash from the transmitter and save it to a file.

2.To be usable by anybody that is not familiar with Linux, TC will either need to mount and umount the drives automatically or have instructions for the user to do it.

3.You have to be root to mount them using the command line,

4.but it looks like there is a GUI mount tool that will let the TC user do it (if he knows the device or mount point). It looks like TC sets up mount points on /mnt (/mnt/sdb1, /mnt/sdc) for all the drives it detects,

5.Looking at the kernel ring buffer with dmesg it was easy enough to tell that /dev/sdb1 was the SD card and /dev/sdc was the eeprom and mount them manually, but the devices will be different for other machines.
Jim

thanks for taking the time to check it out.

1. I remember reading about the power on -vs- power off. I will brush up on that.
2 . That is something I never thought about. I wonder if taranis has a common UUID for its storage ?
3. sudo works for the tc user. by default the tc account doesnt have a password and login is disabled for root. I added password to tc on my dev machine to utilize ssh.
4. Yea the little simple tool. I've glanced at that. Writing up some steps that use that tool would be easiest at first. Hopefully it can be automated

5. so it appears the eeprom does not have a partition to it ?

Since you mentioned it I remember reading taranis shows the flash/eeprom as hard drives. I hadnt given it a second thought till you brought it up. thanks so much. I need to do more research on this before commenting further.

as Far as I had got concerning hard drives was considering whether to add the application that allows the user to install the OS on a flash drive from within the OS. I am hesitant to add the app because I am afraid the user will overwrite their primary (windows ) hard drive. ( The alternative is to just let the end user burn the iso to a flash drive from within windows ) I need to investigate the app to see what kind of failsafes it has in place. Maybe it has some detection routines that can be used to identify taranis drives based on UUId, size, or anything that is picked up by udev. I have seen some udev bits in TC but am not aware if all the bits are in place or if additional libraries are needed. I think it has a very basic subset for drive identification.

I do know the usbasp part works for avrdude so I am getting closer to the point where I can point to this ISO as a means to verify that the usbasp hardware is working and the end user in fact does not have the windows drivers installed properly. Taranis is a little further off it appears.

thanks again

[MikeB]

ersky9x has a bootloader now, and with this both the flash and the EEPROM appear as files on a hard drives on the USB, in the same way the Taranis does. OpenTx is going to be using the bootloader as well.
This means, once you have a bootloader version of ersky9x on theTx, you won't need SAM-BA anymore.
I've also got a "maintenance mode" available on bootup that allows updating the bootloader itself from a file on the SD card. I've just added the ability to update the firmware on the coprocessor from a file on the SD card in this "maintenance mode".
The 9XR-PRO is coming out shortly and will ship with ersky9x on it, complete with bootloader, so again, all that should be needed is the two USB hard drives, one being the SD card and the other the flash and EEPROM.
SAM-BA is then only needed if a user has a catastrophic failure.

Mike.

[rperkins]

, all that should be needed is the two USB hard drives, one being the SD card and the other the flash and EEPROM.
Mike.

thanks for the good information. If you get a chance to review my statements and questions any guidance/corrections would be appreciated. thanks

A boot disk like Rcboot.iso wont even be needed for taranis/ersky9x/9XR0PRO once the MCU has a bootloader installed as all OS ( esp windows ) support usb drives. This bootable disk would only be needed (to avoid driver installation on windows machines) one time in order to upgrade the firmware on the target to a version that includes a bootloader. In order to upgrade the firmware on a target that doesnt have a bootloader the target is turned off and the appropriate utility is used (dfu-util or sam-ba) . Since the target isnt even turned on then the usb drives arent being advertised anyway.

Now that I have arrived at this point ( i think ) it makes the following a lower priority. But if I get to the point where I would like the usb drives to be automounted on the rcboot disk, to allow acccess to them from within the Rcboot,iso, here is the research I have done. and some questions..

so on linux to locate the eeprom file location you search all mounted *fat* fstype's for a file /TARANIS.BIN
I notice on windows you check the volume name for (vName.contains("TARANIS") . I like that better. does that not work on linux.
https://github.com/opentx/opentx/blob/n ... .cpp#L1009.

As far as the sdPath, you just read that from the preferences ? you dont go out and search for the SD card.

And am I right that the SD Card is used only for Sounds and logs ??

Basically I am looking for the best way to automount the appropriate drives or at least give the end user some good hints for finding them.

[rperkins]

I updated the bootable disk located at
http://9xrprogrammer.com/index.php/rc-bootdisk

Added wireless support. partial list of supported devices is here
http://wiki.tinycorelinux.net/wiki:list ... fi_devices
theoretically anything listed here should be able to work.
http://wireless.kernel.org/en/users/Devices
drop me a note if you have device that is listed in either of these places and does not work

the size of the iso is 90MB and supports:
eepe ( rev 393)
companion9x ( 1.52)
KKMultiCopterFlashTool (.77 beta 7)
includes avrdude and dfu-utils to support flashing devices. DOES NOT include sam-ba for skyboard

next is to get some install information, docs, webpage, complete license info of various source code, current source code, scripts to help taranis find their drives, and make a more general announcement.

If anyone tries this out feedback would be great.
thanks

[jtaylor]

I got strange results with the new iso with wireless. It booted fine in the VirtualBox vm on my laptop. But when I booted the iso on one of my desktops it came up to command line instead of GUI and /usr/local/bin was empty. No xsetup or Xversa commands so no way to start the GUI. Now I'm booting the iso using grub2 instead of burning a CD, but when I boot your old iso on the same machine using the same grub2 loopback boot commands it comes up in the GUI. Strange..... It's like something isn't mounting, but I don't know what. I messed with it for a while but never did figure out what the difference is between the two. The isolinux.cfg is a little different between the two so something must be a different, but I cant figure out what. I wanted to test it on that system because it has a Dlink USB wireless that is listed as supported and I wanted to see if it worked.

I haven't actually burned a CD in ages, but if I can find a blank one I may have to actually burn it and see what it does.

Jim

[rperkins]

It booted fine in the VirtualBox vm on my laptop. But when I booted the iso on one of my desktops it came up to command line instead of GUI and /usr/local/bin was empty.
Jim

I got the same thing on my original iso. The problem is that the computer boots the kernel and initramfs, but when it does the pivotroot to finish the bootup, it is not waiting long enough for the cdrom/dvd drive to be mounted, hence none of the applications, including X are being installed.

the second round of iso I put all the applications in the initramfs, so that avoided the entire pivotroot scenerio. the problem was the user couldnt take that cd and do a usb pen drive installation with it because all the apps were in the initramfs instead of in the native tiny core linux package format

When I made this last disk I added a waitusb=20. I guess I should have made it 30 as that worked for me before. I think in your cases if at the boot prompt you would type waitusb=xx where xx is > 30 would probably work.

I am sure if you are booting up to the prompt instead of the gui then your cdrom/dvd is not being found at the pivitroot. This is gonna be a FAQ when I get there.

thanks for checking it out and I will increase the usbwait delay. I think I will have 2 boot entries at the grub command line, one with the recomended usbwait=5 for usb pen drives and another with usbwait=30 for bootable cdrom installations.

1. Do you think the graphics quality is good enough. I am using Xvesa
2. do you think the text based wirelesss app is good enough. It uses much less hard drive space and I dont like the layout of the more advanced gui anyway.

I do admit I did most of my testing of the wireless using qemu-kvm with usb passthrough of a wifi dongle. the one I tested was ralink based and worked fine.

[jtaylor]

Ok I solved the boot problem. I'm not booting from a cd so that isn't the problem. I'm booting the iso from a fat disk partition. The old iso ran completely form ram disk so didn't need the filesystem with the loopback iso to be mounted. I booted the old iso with the grub2 commands:

loopback loop (hd0,1)/RCBoot.iso
linux (loop)/boot/vmlinuz root=/dev/ram0
initrd (loop)/boot/core.gz
boot

The new iso requires access to the loop device after boot for Xvesa and cde and didn't have it. I changed my linux command to:

linux (loop)/boot/vmlinux root=/dev/ram0 iso=/mnt/sda1/RCBoot.iso desktop=fluxbox cde

and all is good.

I think the graphics quality is fine, at least on my VM and the one desktop I've tested it on.

Now for the bad news on my wireless. I have an old Dlink DWL-G120 rev C1 usb adapter that is listed as supported, but doesn't work. When I click on the wifi icon it opens a blank terminal window and sits there awhile (doesn't write anything to it) and then closes the window. iwconfig shows no wireless devices available. Looking at dmesg I see:
(p54usb) cannot load firmware isl3886usb (-2)

So it looks like the firmware isn't getting loaded to the card. Google seems to indicate that Debian doesn't install non-free binary firmware and you have to load the firmware from somewhere else so I don't know if that is the problem with TC or not. I run openSUSE 13.1 on that system and it uses that wireless and I have booted Knoppix and SystemRescue on it and they both had no problem with that wireless so I don't know. If I get some time I'll look into it some more and try a different usb wireless and see if it does any better.

[rperkins]

glad you got it up. sounds like it was as different wrinkle of the same situation.
I am working up a disk now with better usbwait implementations.

I will check into your particular wireless and see what it takes to get it going. tiny core doesnt do a good job of listing what firmware* packages are needed for wireless. I manually went thru them and removed the ones that werent for wireless. I may have removed support for your hardware or it may be under a different package, or I will need to add one. hmm that might entail compiling a kernel module also

[rperkins]

O. When I click on the wifi icon it opens a blank terminal window and sits there awhile (doesn't write anything to it) and then closes the window.

yes that's how it acts when there isnt a useable wireless device. I would have liked some feedback but the script doesnt provide it. It doesnt provide it when it connects either

It looks like the kernel module is provided but not the firmware. I'll check into it
http://wireless.kernel.org/en/users/Drivers/p54

Note I updated the rcboot_wireless.iso to better support booting of a slow starting cd/dvd . It was a change to the isolinux.cfg and the addition of a menuc32 file. none of the apps changed.

[rperkins]

alright I updated the iso again

using the information from here
http://wireless.kernel.org/en/users/Dri ... 4#firmware

based on your information I believe you have this device
USB 1st generation (ISL3886 + net2280)
downloaded the firmware from here
http://daemonizer.de/prism54/prism54-fw ... 0.lm86.arm

and now the iso copies that firmware to /usr/local/lib/firmware

Of couse I cant tell if that will work. If you get a chance let me know and I will create a package with all these firmwares. I think I got the process right but a lot of the firmwares are in subdir's under the /usr/local/lib/firmware dir. I dont know if the kernel module expects the firmware in one specific location or if it recursively searches in the firmware dir.

thanks for the testing and feedback