A user get an error when trying to install on his devices:
*trying to install keep getting error 34
here is the log file
Please let me know what i need to do. i tried it on my laptop and got the same error
Started executable C:\Users\damon\Downloads\windows-x32_1_2(2).exe at Fri Oct 08 16:06:43 2021
[0:0] restrict DLL directories
[0:0] init file name C:\Users\damon\Downloads\windows-x32_1_2(2).exe C:\Users\damon\Downloads\windows-x32_1_2(2).exe 53 0
[0:0] number of sections: 5
[0:0] size of optional headers: 224
[0:0] resSectionTableStart: 672
[0:0] rawDataSize: 16384, rawDataOffset: 381440
[0:0] sun.locale.formatasdefault is false
[0:0] language/country is en_US
[0:0] ignoring java options environment variables
[0:0] change working directory to C:\Users\damon\Downloads
[0:0] single instance mode
[0:0] semaphore name Local\c:_users_damon_downloads_windows-x32_1_2(2).exe, code 0, value 00000178
[0:0] Init done
[0:65] Starting work
[0:72] number of sections: 5
[0:72] size of optional headers: 224
[0:72] resSectionTableStart: 672
[0:72] rawDataSize: 16384, rawDataOffset: 381440
[0:73] starting at 397824
[0:73] verifying integrity length 52948869
[0:169] ERROR: check ReadFile failed 0 0 47984108*
any idea what's happening? I tried on multiple machines and works all the time
Together with installation package i distribute the FTDI drivers for the hardware. Could this be the issue (picking the "resctrict DLL directories" hint from the log)?
This error would happen if the file is truncated.
Related
I have already posted this as an issue on Github at https://github.com/snakemake/snakemake/issues/279 but haven't got any response yet. I hope to find help here.
Version
I am using the following versions on our HPC cluster:
Snakemake c5.4.4
singularity version 3.5.3
Minimal example
singularity: "docker://bash"
rule test:
shell: "echo test"
Describe the bug
snakemake --use-singularity --debug
returns this message:
Building DAG of jobs...
Pulling singularity image docker://bash.
Using shell: /bin/bash
Provided cores: 1
Rules claiming more threads will be scaled down.
Job counts:
count jobs
1 test
1
[Fri Mar 13 15:59:30 2020]
rule test:
jobid: 0
Activating singularity image /data/nanopore/test/.snakemake/singularity/36b22e49e8a03fd08160e9345dd1034e.simg
FATAL: container creation failed: not mounting user requested home: user bind control is disallowed
[Fri Mar 13 15:59:30 2020]
Error in rule test:
jobid: 0
RuleException:
CalledProcessError in line 4 of /data/nanopore/test/Snakefile:
Command ' singularity exec --home /data/nanopore/test --bind /opt/snakemake/v5.4.4/lib/python3.5/site-packages/snakemake-5.4.4-py3.5.egg:/mnt/snakemake /data/nanopore/test/.snakemake/singularity/36b22e49e8a03fd08160e9345dd1034e.simg bash -c 'set -euo pipefail; echo test'' returned non-zero exit status 255
File "/data/nanopore/test/Snakefile", line 4, in __rule_test
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
Shutting down, this might take some time.
Exiting because a job execution failed. Look above for error message
Complete log: /data/nanopore/test/.snakemake/log/2020-03-13T155917.601627.snakemake.log
Apparently, snakemake runs singularity with default values for --home and --bind. These were disallowed by the administrator, however.
Executing
singularity exec --home /data/nanopore/test --bind /opt/snakemake/v5.4.4/lib/python3.5/site-packages/snakemake-5.4.4-py3.5.egg:/mnt/snakemake /data/nanopore/test/.snakemake/singularity/36b22e49e8a03fd08160e9345dd1034e.simg bash -c 'set -euo pipefail;'
returns:
FATAL: container creation failed: not mounting user requested home: user bind control is disallowed
Additional context
Is there a way to disable the Singularity default parameter setting in snakemake? Inside the singularity container the /data directory is still writeable and readable anyway.
Thanks a lot
I would like to run a Yocto image in QEMU but the way how it's described in the documentation doesn't work.
To verify I'm not doing anything wrong i followed the steps in the quick build guide:
install required packages
clone poky
checkout correct version
source build environment
set machine to qemux86 in local.conf
add sstate-mirrors and allow parallel build
start bitbake core-image-sato
do something else for the next few hours
when I try now to run that image in qemu like describe in the documentation:
runqemu qemux86
I just get the following output, nothing happens:
runqemu - INFO - Running MACHINE=qemux86 bitbake -e...
runqemu - INFO - Continuing with the following parameters:
KERNEL: [/mnt/wwn-0x50014ee0576fe9ef- part1/test_python3_in_yocto/build/tmp/deploy/images/qemux86/bzImage--4.14.76+git0+3435617380_2c5caa7e84-r0-qemux86-20190305114605.bin]
MACHINE: [qemux86]
FSTYPE: [ext4]
ROOTFS: [/mnt/wwn-0x50014ee0576fe9ef-part1/test_python3_in_yocto/build/tmp/deploy/images/qemux86/core-image-base-qemux86-20190305151244.rootfs.ext4]
CONFFILE: [/mnt/wwn-0x50014ee0576fe9ef-part1/test_python3_in_yocto/build/tmp/deploy/images/qemux86/core-image-base-qemux86-20190305151244.qemuboot.conf]
runqemu - INFO - Setting up tap interface under sudo
runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0
runqemu - INFO - Running /mnt/wwn-0x50014ee0576fe9ef-part1/test_python3_in_yocto/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-i386 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=/mnt/wwn-0x50014ee0576fe9ef-part1/test_python3_in_yocto/build/tmp/deploy/images/qemux86/core-image-base-qemux86-20190305151244.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -device usb-tablet -device virtio-rng-pci -cpu pentium2 -m 256 -serial mon:vc -serial null -kernel /mnt/wwn-0x50014ee0576fe9ef-part1/test_python3_in_yocto/build/tmp/deploy/images/qemux86/bzImage--4.14.76+git0+3435617380_2c5caa7e84-r0-qemux86-20190305114605.bin -append 'root=/dev/vda rw highres=off mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 '
When I try to run qemu without graphics I get a kernel panic:
runqemu nographic qemux86
...
[ 6.171521] EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null)
[ 6.172937] VFS: Mounted root (ext4 filesystem) on device 253:0.
[ 6.175806] devtmpfs: error mounting -2
[ 6.237143] Freeing unused kernel memory: 852K
[ 6.238001] Write protecting the kernel text: 8752k
[ 6.238722] Write protecting the kernel read-only data: 2376k
[ 6.244382] Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin.
[ 6.245455] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.76-yocto-standard #1
[ 6.245913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/4
[ 6.246730] Call Trace:
[ 6.247788] dump_stack+0x58/0x72
[ 6.248071] ? rest_init+0x90/0xc0
[ 6.248320] panic+0x94/0x1c6
[ 6.248529] ? rest_init+0xc0/0xc0
[ 6.248807] kernel_init+0xda/0xf0
[ 6.249046] ret_from_fork+0x2e/0x38
[ 6.249834] Kernel Offset: 0xd800000 from 0xc1000000 (relocation range: 0xc0000000-0xd07dbfff)
[ 6.250595] ---[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentat.
Is there something missing in the documentation?
I also tried different images...
core-image-sato
core-image-base
core-image-minimal
and finally I tried it with version 2.5.2 (sumo) instead of 2.6.1 (thud)... but no change...
When I googled for that issue I didn't really find anything helpful except increasing the memory, which didn't change anything, so I hope anyone here someone knows whats wrong...
Probably missing an appendage to the second parameter.
Browse to the folder in the error message, and check the directory qemux86 exists, chances are it doesn't.
I had to
runqemu qemux86-64
and not
runqemu qemux86
If you haven't changed MACHINE variable in your local.conf file in build directory, check out the file and make sure your image name was identical.
Analyzing a crash dump, WinDbg says my symbols (PDB file) does not match the module. The symbols are the ones generated when the DLL was compiled. The only thing that I can imagine would cause a mismatch is that the DLL was signed.
I'm using !chksym to validate symbols:
!chksym libcef.dll D:\sym\libcef.dll.pdb
libcef.dll
Timestamp: 5BB3D477
SizeOfImage: 626D000
pdb: F:\src\out\libcef.dll.pdb
pdb sig: B0065D83-113F-63BE-53BC-AEF07EC816B4
age: 1
libcef.dll.pdb
pdb sig: 9BA88A40-D168-44F2-44C1-DD2D73A38B38
age: 1
sig MISMATCH: libcef.dll.pdb and libcef.dll
Code signing an executable or DLL does not affect the debug header of the executable. Thus, it will still match the PDB.
...\SigningPdb\bin\Release>symchk signed.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
...\SigningPdb\bin\Release>symchk unsigned.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
And
...\SigningPdb\bin\Release>ChkMatch.exe -c signed.exe SigningPdb.pdb
ChkMatch - version 1.0
Copyright (C) 2004 Oleg Starodumov
http://www.debuginfo.com/
Executable: signed.exe
Debug info file: SigningPdb.pdb
Executable:
TimeDateStamp: bc78c18e
Debug info: 2 ( CodeView )
TimeStamp: a7b373e5 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 97 RVA: 000026a0 FileOffset: 000008a0
CodeView format: RSDS
Signature: {b8ed520c-cdfc-486b-8e1a-7c0752a2a41f} Age: 1
PdbFile: ...\Release\SigningPdb.pdb
Debug info: 16 ( Unknown )
TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 0 RVA: 00000000 FileOffset: 00000000
Debug information file:
Format: PDB 7.00
Signature: {b8ed520c-cdfc-486b-8e1a-7c0752a2a41f} Age: 1
Result: Matched
The timestamp is in the COFF header. That header is only 24 bytes in size and will not change during code signing.
Most changes will happen in a new section for certificates. This section, however, will also be ignored during code signing. Otherwise, a second signature would destroy the first signature. (BTW: this section has been used to transport malicious code inside a signed executable)
Of course, the "usual" checksums, which do not consider the EXE/DLL file structure, will report a different checksum.
What may have happened to your DLL or EXE?
you have accidentally rebuilt it, so the time stamp of your DLL does not match the PDB any more
you are using aspect oriented programming (AOP) in .NET and there is some code weaving happening after a rebuild. These tools might not be able to rebuild the PDB after weaving, so the PDB mismatch is already there before the DLL is code signed.
My fetchmail scripts retrieves emails from an email box and puts them into a file, called mario, and dumps it into my /var/mail/ folder. I am trying to set up a procmail script to process mario; by processing, this is what I mean: the procmail script should filter against an external text file (fromlist) containing a list of known email addresses. Once there is a match mario/fromlist, the message is pulled out from mario and stored into my local nbox/ folder.
Online, I found a piece of code, including a recipe, that I have entered into my procmail control file (.procmailrc) but it doesn't seem to be working. This is the code:
FROMFL=$MAIL/fromlist
FROMLS=formail -xFrom: | sed -e 's/*(.*)//;s/>.*//;s/.*[:]*//'`
:0
* ? fgrep -xi $FROMLS $FROMFL
$MAIL/inbox
I think I have addressed the sed (see my question Sed command and unknown patterns found online), but I still haven't been able to address the formail and fgrep parts. So when I run the procmail script, the logs I obtain are:
$ mailstat var/log/procmail.log
/bin/sh: 0: Can't open fgrep
/bin/sh: 1: grep: not found
/bin/sh: 1: sed: not found
/home/user/var/mail/reginbox/
procmail: [6880] Sat Jun 16 16:57:32 2018
procmail: Acquiring kernel-lock
procmail: Assigning "FROMFL=/home/user/var/mail/fromlist"
procmail: Assigning "FROMLS="
procmail: Assigning "LASTFOLDER=/home/user/var/mail/reginbox/msg.XXX"
procmail: Assigning "SHELL=/bin/sh"
procmail: Executing "fgrep,-xi,/home/user/var/mail/fromlist"
procmail: Executing "formail -xFrom: | sed -e `'s/.*<//; s/>.*//'`"
procmail: No match on "fgrep -xi /home/user/var/mail/fromlist"
procmail: Non-zero exitcode (127) from "fgrep"
procmail: Notified comsat: "user#0:/home/user/var/mail/reginbox/msg.XXX"
procmail: Opening "/home/user/var/mail/reginbox/msg.XXX"
It looks as if formail cannot quite extract the lines where "From:" is located, which means that the email addresses in those lines are not carved out of the rest by the SED command and are not compared against the text file with the list of emails (fromlist), that's why the log show a "No match" message.
How can I find out where these things break down?
The syntax for running an external command is
VARIABLE=`command to run`
You are missing the opening backtick, so you are running effectively
FROMLS="formail"
-xFrom: | sed etc is a syntax error
Anyway, the recipe to extract the sender is a bit inexact, because it doesn't cope correctly with various variations in email address formats. A more robust but slightly harder to understand solution is
FROMLS=`formail -rtzxTo:`
which makes formail generate a reply -rt, then from the generated reply extract the To: address, which of course now points back to the original sender. By design, formail only puts the actual email address of the sender of the input message in the To: header when it generates the reply, so that's what you will be extracting.
With that out of the way, your script should technically work to the point where it can extract the matching messages and copy them to the destination folder you want. Here's a quick demo:
tripleee$ cd /tmp
tripleee$ echo moo#example.com >fromlist
tripleee$ cat one.rc
# temporary hack
SHELL=/bin/sh
MAILDIR=/tmp
MAIL=.
VERBOSE=yes
FROMFL=$MAIL/fromlist
FROMLS=`formail -rtzxTo:`
:0
* ? fgrep -xi "$FROMLS" "$FROMFL"
$MAIL/inbox
tripleee$ procmail -m one.rc <<\:
From: ick#example.com
To: poo#example.org
Subject: no match
hello
:
procmail: [16406] Wed Jun 27 13:41:35 2018
procmail: Assigning "FROMFL=./fromlist"
procmail: Executing "formail,-rtzxTo:"
procmail: Assigning "FROMLS=ick#example.com"
procmail: Executing "fgrep,-xi,ick#example.com,./fromlist"
procmail: Non-zero exitcode (1) from "fgrep"
procmail: No match on "fgrep -xi ick#example.com ./fromlist"
Subject: no match
Folder: **Bounced** 61
tripleee$ procmail -m one.rc <<\:
From: moo#example.com
To: poo#example.org
Subject: match
hello
:
procmail: [16410] Wed Jun 27 13:41:37 2018
procmail: Assigning "FROMFL=./fromlist"
procmail: Executing "formail,-rtzxTo:"
procmail: Assigning "FROMLS=moo#example.com"
procmail: Executing "fgrep,-xi,moo#example.com,./fromlist"
procmail: Match on "fgrep -xi moo#example.com ./fromlist"
procmail: Assigning "LASTFOLDER=./inbox"
procmail: Opening "./inbox"
procmail: Acquiring kernel-lock
Subject: match
Folder: ./inbox 68
There is no way really for procmail to remove anything from the input folder. If you want to do that, a common solution is to have Procmail write the non-matching messages to another output folder, then copy that back over the input file. The net effect is that the messages from the original input folder are now partitioned into two files, one with matching, and one with non-matching messages.
hi i have attached crash dump for an exe and symbols also.but i am getting this error:
Unable to verify checksum for abc.exe.
What would be the reason for this?
Unable to verify checksum is emitted when the checksum in the PE header isn't verifiable.
This can happen if the exe in question was compiled and linked without using /RELEASE linker option.
Normal project based compile linker sets this option. nmake or batch file based compilation can omit this switch and can lead to this output.
A simple hello world compiled and linked with and without /RELEASE linker option (PDB not generated for simpilicity and diffed to show the difference in timestamp and checksum). Loaded in WinDbg and checksum warning is generated only for the exe with no checksum in PE header.
simple hello world.cpp contents
testrelease:\>dir /b & type testrelease.cpp
testrelease.cpp
#include <stdio.h>
int main (void) {
printf("hello my relase\n");
return 0;
}
compiling without /RELEASE
testrelease:\>cl /nologo testrelease.cpp
testrelease.cpp
renaming the exe and compiling the same source with with /RELEASE
testrelease:\>ren testrelease.exe testrelease_norel.exe
testrelease:\>cl /nologo testrelease.cpp /link /release
testrelease.cpp
comparing both exes
testrelease:\>fc /b testrelease.exe testrelease_norel.exe
Comparing files testrelease.exe and TESTRELEASE_NOREL.EXE
000000E0: D6 CE
00000130: A3 00
00000131: 95 00
00000132: 01 00
analysing output of the comparison
testrelease:\>xxd -s +0x3c -l 1 testrelease.exe
000003c: d8 .
testrelease:\>xxd -s +0x3c -l 1 testrelease_norel.exe
000003c: d8 .
testrelease:\>echo d8 = NT_HEADER so e0 = TimeDateStamp and 130 = CheckSum
d8 = NT_HEADER so e0 = TimeDateStamp and 130 = CheckSum
loading both exes in windbg warning generated for only one exe without checksum
testrelease:\>cdb -c ".reload /f ; q" testrelease.exe
.*** ERROR: Module load completed but symbols could not be loaded for image00400
testrelease:\>cdb -c ".reload /f ; q" testrelease_norel.exe
.*** WARNING: Unable to verify checksum for image00400000
*** ERROR: Module load completed but symbols could not be loaded for image004000
no symbol header available error means the exe was compiled without debug information.
You can't do much about it unless you have a lot of expertise in recreating debug information from scratch.
Both the executables that are compiled above will generate the error because iIhave intentionally not created the debug information.
DBGHELP: image00400000 missing debug info. Searching for pdb anyway
DBGHELP: Can't use symbol server for image00400000.pdb - no header information available