Installation on USB stick fails due to InstallerPackageNotFoundException
An installation attempt from an USB stick onto another USB stick fails the following stack
No handlers could be found for logger "freenasOS.Configuration"
Traceback (most recent call last):
File "/usr/local/bin/freenas-install", line 56, in <module>
if installer.GetPackages() != True:
File "/usr/local/lib/freenasOS/Installer.py", line 739, in GetPackages
raise InstallerPackageNotFoundException("%s-%s" % (pkg.Name(), pkg.Version())
The FreeNAS installation on da1 has failed. Press any key to continue..
typed from screen. The `?` in the version string is a non-visible part in a line break due to failing screen adjustment.
The installation target has been connected during the GRUB countdown to make sure that the installation routine is running from one stick and the other which serves as installation media is discovered.
Experienced with FreeNAS-9.3-STABLE-201502050159.iso copied according to http://doc.freenas.org/9.3/freenas_install.html#on-freebsd-or-linux, i.e. not the version I had to select for the `Seen in` field!
#2 Updated by Sean Fagan over 5 years ago
- Status changed from Unscreened to 15
This doesn't happen for me, with the same iso.
At the installation menu, go into the shell, and run "mount" at the prompt. It shoudl sho
/dev/md0.uzip on / (ufs, local, read-only)
/dev/iso9660/FreeNAS_INSALL on /.mount (cd9660, local, read-only)
and a few other things.
#3 Updated by Karl-Philipp Richter over 5 years ago
I could now see that `gpart: arg0 'da1': Invalid argument` is displayed before what clearly is output of `dd` saying the 0 records are processed. Clearing the target installation media with the `shred` command (of coreutils 8.23) didn't help, but exchanging source and target USB sticks did, though I used the target media for a FreeNAS 9.2 running 5 weeks. The issue seems unrelated to the device file name `daN` because after exchanging the media the target is `da1` again.
Long story short: It'd be helpful to improve the feedback after `dd` failed due to a corrupted installation media. I can't explain the fact that using the USB stick on Linux 3.16 is no problem and I don't understand why `shred` which needs to write on the whole device succeeded if there is corrupted.
The issue occurs after entering the desired root password.
#4 Updated by Sean Fagan over 5 years ago
When gpart complains about da1, all it means is that there is no GPT yet. That's why it does not cause an error.
dd saying 0 records are processed, on the other hand, means something is wrong with your thumb drive.
So in addition to the mount commands I asked for, I also want to see the output of "diskinfo da1". Or whichever device it ends up being in that boot.
Also what type of thumb drive you are using.
#5 Updated by Karl-Philipp Richter over 5 years ago
Seems like the reported failure was the last action of that device. It overheated (almost burned by fingers on it) and now does nothing. It was an `Innostor Innostor` 16 GB USB thumb device ~5 years old (it doesn't seem to implement a lot of device information - that's all `lshw` on Linux tells me).
The only thing left to do is reviewing the code, but that up to you. I don't see a list of possible status, so change it to whatever you think is appropriate.
Thanks for your feedback!