I'm struggling to upload a floppy image (same goes with cd_rom image) from Packer using the vsphere-iso plugin.
I was able to deploy a Linux ISO file located in a datacenter within vCenter and it works well.
As soon as I have some provisioning using floppy of cdrom images that needs to be uploaded to the datastore, it fails.
I can successfully upload the files manually from the vSphere Client UI which means vCenter privileges are just fine for my user (I'm not full admin on the ESXi).
Using vshere-iso builder to deploy an ISO file available in the ESXi datastore, provisioning it with a floppy image for the OS installation.
Datastore ISO is correctly detected and mounted but the build fails everytime during floppy image upload.
Please excuse any information I could have missed that would be required to troubleshoot
Any idea or help is very welcomed.
Reported on Packer github as well: https://github.com/hashicorp/packer/issues/11655
Thank you !
Overview of the Issue
Reproduction Steps
Run following command using the builder below:
packer build -debug -var 'username=xxx' -var 'password=yyyy' .
Randomly, one build outputs a **404 Not found** error and one build outputs a **write tcp 10.1.21.208:57236->10.1.11.230:443: write: broken pipe**
In every case, the HTTP request that seems to fail is:
Put "https://<host>/folder/<vm-name-folder>/packer-tmp-created-floppy.flp?dcPath=<datacenter>&dsName=<datastore>
Packer version
1.8.0
Simplified Packer Template
packer-template.pkr.hcl
Operating system and Environment details
Ubuntu 20.04.4 LTS
vCenter version 6.7
Log Fragments and crash.log files
packer-broken-pipe-error.log
packer-404-not-found.log
Related
What we are trying to do is to get SonarQube to analyze our Typescript (Node.JS) project on a Docker image, but we are running into an error. If it helps, we are trying to use the sonarqube-scanner module from Node.JS.
The error is as encountered below:
[17:57:23] Starting analysis...
[17:57:24] Getting info from "package.json" file
[17:57:24] Checking if executable exists: /root/.sonar/native-sonar-scanner/sonar-scanner-4.5.0.2216-linux/bin/sonar-scanner
[17:57:24] Could not find executable in "/root/.sonar/native-sonar-scanner".
[17:57:24] Proceed with download of the platform binaries for SonarScanner...
[17:57:24] Creating /root/.sonar/native-sonar-scanner
[17:57:24] Downloading from https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-4.5.0.2216-linux.zip
[17:57:24] (executable will be saved in cache folder: /root/.sonar/native-sonar-scanner)
[91m[18:03:53] [0m[91mERROR: impossible to download and extract binary: connect ETIMEDOUT 91.134.125.245:443
[0m[91m[18:03:53] [0m[91m SonarScanner binaries probably don't exist for your OS (linux).
[0m[91m[18:03:53] In such situation, the best solution is to install the standard SonarScanner (requires a JVM).
[0m[91m[18:03:53] Check it out at https://redirect.sonarsource.com/doc/install-configure-scanner.html
Now if you notice from the error, the binaries server encounters an ETIMEDOUT error, and this is because the server that accesses it comes from an internal network that cannot access external sites.
Would it be possible to configure SonarQube to pull from an internal server? And if so how would we go about configurating this?
Many thanks in advance!
I was able to find documentation through the SonarQube Javascript module here (https://www.npmjs.com/package/sonarqube-scanner)
By default, the scanner binaries are downloaded from https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/. To use a custom mirror, set $SONAR_SCANNER_MIRROR. Or download precise version with $SONAR_SCANNER_VERSION
Example:
export SONAR_SCANNER_MIRROR=https://npm.taobao.org/mirrors/sonar-scanner/
export SONAR_SCANNER_VERSION=3.2.0.1227
I am trying to install minishift on Windows. However, I am facing with below Issue while installing It.I have tried with multiple version of Open Shift
Command Used : minishift.exe start --vm-driver virtualbox
Console Out Put :
-- Downloading OpenShift v3.9.0 checksums ... OKError starting the cluster: Error attempting to download and cache 'oc': Failed to validate hash - expected: 7ed04f7bc411056425d98aa6a10536fab15bdb569549446223f6ed22421ea4e6, actual: 705eb110587fdbd244fbb0f93146a643b24295cfe2410ff9fe67a0e880912663
Is their anyway to skip hash validation Check..?
There is currently no option to disable hash validation check. However there is a workaround for your issue, you can download the binary manually and put it into Minishift home - then Minishift on next start will not attempt to download it.
Download oc v3.9.0 release for Windows from its release page
Extract
Move oc.exe binary to .minishift/cache/oc/v3.9.0/windows/oc.exe
Start Minishift
Similar steps will also apply for other platforms and versions of oc. You can search for all releases by tag at Origin release page.
Reason of failure:
I have checked both Checksum on release and actual sha256sum of the binary and your sum is correct. Is it possible that the CHEKSUM file is cached on your proxy? What is the version of Minishift you are using?
If you are willing to invest some of your time, you can create an issue on Minishift so the team can take a deeper look into the problem.
you might receive a 403 forbidden status from GitHub if your request exceeds the rate limit for your IP address.Instead of waiting for GitHub to reset the limit for your IP address, you can create a Personal API Tokens from your personal GitHub account.
Personal API Token generation URL: https://github.com/blog/1509-personal-api-tokens
You need to set Token to environment variable.
For windows10: set MINISHIFT_GITHUB_API_TOKEN=<token_ID>
For Linux: export MINISHIFT_GITHUB_API_TOKEN=<token_ID>
Then run below command on windows CMD:
minishift.exe start --vm-driver virtualbox
I am having a problem deploying an EB instance with a custom .ebextensions file. This is the relevant part in that file:
container_commands:
01_migrate:
command: 'python db_migrate.py'
02_npm_build:
command: 'npm install && npm run prod'
As you can see, these commands are for migrating my PostgreSQL database (via a Flask backend) and building my React .jsx files.
If I leave these commands out, the deployment completes perfectly well. However, once I put them in, looking at the eb-activity.log it stalls at this part forever (as far as I can tell):
[2017-04-10T02:39:24.106Z] INFO [3023] - [Application deployment app-613e-170409_223418#1/StartupStage0/EbExtensionPostBuild] : Starting activity...
I also get this message on the Health overview in the console (this is after 1 day):
Performing application deployment (running for 1 day).
I have also tried to deploy it without those container_commands, and then including it back after the successful initial deployment. Then I get the same error message as before in eb-activity.log, and I also get this message on the Health overview:
Incorrect application version "app-2a3d-170409_214923" (deployment 1). Expected version "app-2a3d-170409_214923" (deployment 1).
Which is very strange because those two versions referenced are the same versions. I don't know what this means!
I found a solution.
Remove all you container_commands from .ebextensions/
Go ssh to instance, kill process with.
sudo killall python
Then Deploy new version without container_commands.
And start debuging all your container_commands, one by one on ssh..
Have fun.
I'm learning how to build a basic OS kernel with https://intermezzos.github.io
I've create my .iso file and I'm at the point where I am runnning qemu-system-x86_64 -cdrom os.iso
When I press enter, QEMU runs a window with the following output:
Booting from Floppy...
Boot failed: could not read the boot disk
Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0004)
Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initializing devices...ok
iPXE 1.0.0+git-20131111.c3d1e78-2ubuntu1.1 -- Open Source Network Boot Firmware
-- http://ipxe.org
Features: HTTP HTTPS iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE Menu
net0: 52:54:00:12:34:56 using 82549em on PCI00:03.0 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:01]
Configuring (net0 52:54:00:12:34:56)...ok
net0: 10.0.2.15/255.255.255.0 gw 10.0.2.2
Nothing to boot: No such file for directory (http://ipxe.org/2d03e13b)
No more network devices
No bootable device.
I went to the website listed in the output (http://ipxe.org/2d03e13b) and one of the tips is that I might Use the iPXE command line to perform DHCP manually, however when I press CTRL + B to access cli, I'm not able to do so.
Where do I look next to troubleshoot this problem of not being able to boot my .iso?
How do I make QEMU have access to keyboard input?
UPDATE
I don't know how, but I'm am now able to use CTRL + B to access iPXE command line.
This seems like a good place to start diagnosing my problem of not being able to boot my .iso.
What am I looking for?
UPDATE 2
Thanks to Peter Maydell's suggestion below, I've tested a known-good iso image (https://alpinelinux.org/), running qemu-system-x86_64 -cdrom alpine-3.4.3-x86_64.iso and it booted perfectly just as I expected.
I've rewritten my files from https://intermezzos.github.io to create a new iso image, this time copy and pasting the code from the repository, just in case I was previously inputting typos.
Still not booting. On to the next clue...
The first thing to do is to check whether this command line and ISO image work on a normal Linux host system. That will tell you whether the problem is (a) the Windows Subsystem for Linux not correctly implementing something QEMU relies on or (b) your ISO image actually not being a bootable CDROM.
You might also try booting a known-good ISO image such as one for a Linux distribution.
(The general principle here is to try to do diagnostic tests to split the space of "what might be the problem" into smaller sections and determine which side your problem is.)
Simple solution to the problem. Has to do with systems that use EFI to boot.
source
I needed to apt-get install grub-pc-bin and then rebuild image.
I tried building recutils version 1.7 downloaded from the home page, using the standard configure, make, sudo make install sequence, but when trying to run the resulting binaries. like recinf, I get the error:
recinf: error while loading shared libraries: librec.so.1: cannot open shared object file: No such file or directory
Does this mean I made a mistake during the build or is the package itself in error?
As Etan Reisner said the problem was that the shared object libraries were installed but not loaded into the cache, hence the need to run ldconfig. After running
sudo ldconfig
the binaries ran properly. If I had looked in /usr/local/lib, I would have seen the libs there.