I've a tape contains a corrupt tar file.
I'm using Unix SunOS 5.5.1.
So when I run this command :
dd if=/dev/rmt/0 of=/tmp/outputfile.tar
I get this error message :
warning /pci#1f, 0/pci#1/pci#1/sunw, isptwo#4/st#4,0 (st4):
Error for command : read Error Level: Fatal
Requested Block : 11900 Error Block : 11900
Vendor : TANDBERG Serial Number: =:CREATED081
Sense Key: Media Error
ASC: 0x11 (unrecorded read error), ASCQ: 0x1, FRU: 0x0
Please Help me I really need solution for this problem
Finally I solved my problem ^^' it was the bs format type :D
Data was written in 512 so I did this :
dd if=/dev/rmt/0 of=/tmp/outputfile.tar bs=512 and all is fine :)))
The bad news is that the tape drive is reporting a media error.
Now this still can mean a few things:
Bad tape drive
This is possible, but rather uncommon. To test it: check if it can read other tapes (it wrote itself), or read tapes other drives wrote.
Dirty heads
Tape drives heads do need periodic cleaning. Esp if they are kept in less that spotless conditions this is very important. Cleaning tapes are commercially available, do match them with the right drive and do not overuse them either.
Mismatch between tape drive and tape medium
Different tape formats (e.g. LTO) have generations (e.g. LTO-3), and there is a need for compatibility between the tape medium and the tape drive.
Bad tape
Tapes do wear out, and need replacement to prevent that. Moreover a written tape has a limited shelf life just as well.
In this last case, you might be able to find a commercial recovery service to try to do something, but I'd not bet the farm on the results ... And data recovery services are expensive ...
Related
I recently had to downsize my ESP32 WROVER package down to 8MB from 16MB before, due to component unavailability.
This broke my update process, showing the invalid segment length 0x15abba12 error message while doing Update.writeStream().
I wrote my new 8MB partition as follows (I use FFAT):
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000,
otadata, data, ota, 0xE000, 0x2000,
app0, app, ota_0, 0x10000, 0x2A0000,
app1, app, ota_1, 0x2B0000, 0x2A0000,
ffat, data, fat, 0x550000, 0x2B0000,
My firmware.bin size is 1.4MB (1411248, or 0x1588B0).
What am I missing?
Ok. Weird enough. It appears that the firmware.bin produced as usually by platformio had some issues, hence the segment fault.
By simply recompiling and linking again, the produced firmware.bin was OK and the update completed successfully.
=> So if you face similar segment fault issue, try to rebuild your firmware bin file before loosing time to debug your actually working code.
I'm coding for class and when I try to compile I now get this error. Worked fine yesterday. IT does not work weekends so I'm out of luck until Monday unless someone can help. I'm fairly new to unix as I only really use it when coding.
cc scheduler.c
Close failure on scheduler.o : No space left on device
cc: acomp failed for scheduler.c
Delete some things on your disk. Use df (type 'man df' for usage) to see where the mount point is that you're compiling onto.
Check out the quota command. It'll show you how much space you get. You've probably just used up all the disk space you're allotted for you account. Go to your home directory:
> cd ~
and run:
> du -sh *
It will show how much space each of your directories takes up. Just remove some unused files.
If one directory takes up most of the space, you can cd into it and run du -sh * there too, to see the disk usage of its subdirectories. It's basically just a useful command for finding large files that you might not need anymore. For example, if you downloaded a really big program for a class project last year, but no longer need it, just rm it.
I am using a 32 bit perl in my openvms system.(So perl can access up till 2gb of virtual address space ).
I am hitting "out of memory!" in a large perl script. I zeroed in on the location of variable causing this . However after my tests with devel:size it turns out the array is using only 13 Mb memory and the hash is using much less than that.
My question is about memory profiling this perl script in VMS.
is there a good way of doing memory profile on VMS?
I used size to get size of array and hash.(Array is local scope and hash is global scope)
DV Z01 A4:[INTRO_DIR]$ perl scanner_SCANDIR.PL
Directory is Z3:[new_dir]
13399796 is total on array
3475702 is total on hash
Directory is Z3:[new_dir.subdir]
2506647 is total on array
4055817 is total on hash
Directory is Z3:[new_dir.subdir.OBJECT]
5704387 is total on array
6040449 is total on hash
Directory is Z3:[new_dir.subdir.XFET]
1585226 is total on array
6390119 is total on hash
Directory is Z3:[new_dir.subdir.1]
3527966 is total on array
7426150 is total on hash
Directory is Z3:[new_dir.subdir.2]
1698678 is total on array
7777489 is total on hash
(edited: Pmis-spelled GFLQUOTA )
Where is that output coming from? To OpenVMS folks it suggests files in directories, which the code might suck in? There would typically be considerable malloc/align overhead per element saved.
Anyway the available ADDRESSABLE memory when strictly using 32 pointers on OpenVMS is 1GB: 0x0 .. 0x3fffffff, not 2GB, for programs and (malloc) data for 'P0' space. There is also room in P1 (0x7fffffff .. 0x4000000) for thread-local stack storages, but perl does not use (much) of that.
From a second session you can look at that with DCL:
$ pid = "xxxxxxxx"
$ write sys$output f$getjpi(pid,"FREP0VA"), " ", f$getjpi(pid,"FREP1VA")
$ write sys$output f$getjpi(pid,"PPGCNT"), " ", f$getjpi(pid,"GPGCNT")
$ write sys$output f$getjpi(pid,"PGFLQUOTA")
However... those are just addresses ranges, NOT how much memory the process is allowed to used. That's governed by the process page-file-quota. Check with $ SHOW PROC/QUOTA before running perl. And its usage can be reported as per above from the outside adding Private pages and Groups-shared pages as per above.
An other nice way to look at memory (and other quota) is SHOW PROC/CONT ... and then hit "q"
So how many elements are stored in each large active array? How large is an average element, rounded up to 16 bytes? How many hash elements? How large are the key + value on average (round up generously)
What is the exact message?
Does the program 'blow' up right away, or after a while (so you can use SHOW PROC/CONT)
Is there a source file data set (size) that does work?
Cheers,
Hein.
I noticed this question has been asked many times in the past and surfing the web I found many pages about it. However, it seems like the proposed solutions rarely work and, in my case, the problem does not refer to a program that I wrote. So I'll give it another try here.
I recently installed Linux Mint 14 on my laptop. After the OS was spick and span, I started to install the software I need, and among these netgen (a Mesh Generator software). I tried both ways: download+unpack+compile+install and synaptic. Either way, this is the output I get when I try to execute the program
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Serial number of failed request: 490
Current serial number in output stream: 491
As I said, I surfed the web, and apparently, this is thought to be linked to some problem in the X server configuration. And here start the mess. Someone says I should modify /etc/X11/Xorg.conf, adding the lines
Option "Videoram" "65536"
Option "Cachelines" "1980"
Under the section "Device." Unfortunately, I have no such file, as apparently in recent distros, the X configuration file has been moved to /usr/share/X11/xorg.conf.d/* and it's now split into different files. The one about the monitor and graphics should be called 10-monitor.conf...which I don't have. I tried to create one, following the instruction at this link, and then add those lines, but nothing happened. To be fair, I'm not 100% sure I generated the file correctly since I am not sure how to detect the driver for my graphics card.
I don't know how much and which information people would need to have an idea of how to fix this problem. Here's what I see might be useful.
The output of 'lspci | grep VGA' is
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
ATI RS880M [Mobility Radeon HD 4200 Series]
My current /usr/share/X11/xorg.conf.d/10-monitor.conf is the following
Section "Monitor"
Identifier "Monitor0"
Modeline "1920x1080_60.00" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync
EndSection
Section "Device"
Identifier "LVSD"
Driver "fglrx" #Choose the driver used for this monitor
EndSection
Section "Screen"
Identifier "Screen0"
Device "LVDS"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1920x1080_60.00" "1366x768"
EndSubSection
EndSection
Under the section "Device." Unfortunately, I have no such file
Try creating your own xorg.conf file, placing it in this location will override your X settings after restarting X or simply by restarting the computer.
mkdir -p /etc/X11/xorg.conf.d/
cp /etc/X11/xorg.conf.d/xorg.conf /etc/X11/xorg.conf.d/xorg.conf.bk # in case it exists
cp /usr/share/X11/xorg.conf.d/10-monitor.conf /etc/X11/xorg.conf.d/xorg.conf
The content of /etc/X11/xorg.conf.d/xorg.conf would look like (adding your options):
Section "Monitor"
Identifier "Monitor0"
Modeline "1920x1080_60.00" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync
EndSection
Section "Device"
Identifier "LVSD"
Driver "fglrx" #Choose the driver used for this monitor
Option "Videoram" "65536"
Option "Cachelines" "1980"
EndSection
Section "Screen"
Identifier "Screen0"
Device "LVDS"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1920x1080_60.00" "1366x768"
EndSubSection
EndSection
This also could be related to the driver you're using, there are other common drivers available like
Driver "fbdev"
Driver "vesa"
Driver "fglrx"
The fbdev driver supports all hardware where a framebuffer driver is available.
The vesa driver supports most VESA-compatible video cards. There are some known exceptions, and those should be listed here.
fglrx is a X.org(7x) driver for ATI (Mobility(TM)) RADEON® and (Mobility(TM)) FireGL(TM) based video cards. The driver provides hardware acceleration for 3D graphics and video playback. It includes support for dual displays, TV Output and as of version 8.21.7 also OpenGL 2.0 (GLSL).
Depending on which driver you choose, certain options/functionality/compatibility would be enabled or not, you could change the driver and test with the options you said would work.
Finally, you have hundreds of options here to play with X11.
When I had made written a lot text to my program I took similiar error. When I reduce the text size the error was disappeared. I think you should reduce too showing things or reorganise how they are looking on screen.
I hope I could help you with this broken English ;)
I am looking for a working distribution of SQLite for OpenVMS. I tried building SQLite 3.7.9 from the amalgamation file, using patches I found in a mailing list, but it does not quite work.
I am using HP C V7.1-015 on OpenVMS Alpha 7.3-2.
Since I cannot install python, which seems to include SQLite3, I have to build from sources.
I compile using the following commands:
$ CC /OPTIMIZE -
/DEFINE=(SQLITE_THREADSAFE=0, -
SQLITE_OMIT_LOAD_EXTENSION=1, -
SQLITE_OMIT_COMPILEOPTION_DIAGS=1, -
SQLITE_OMIT_MEMORYDB=1, -
SQLITE_OMIT_TEMPDB=1, -
SQLITE_OMIT_DEPRECATED=1, -
SQLITE_OMIT_SHARED_CACHE=1, -
_USE_STD_STAT=ENABLE) -
/FLOAT=IEEE_FLOAT -
sqlite3.c
$ CC /OPTIMIZE -
/DEFINE=(SQLITE_THREADSAFE=0, -
SQLITE_OMIT_LOAD_EXTENSION=1, -
SQLITE_OMIT_COMPILEOPTION_DIAGS=1, -
SQLITE_OMIT_MEMORYDB=1, -
SQLITE_OMIT_TEMPDB=1, -
SQLITE_OMIT_DEPRECATED=1, -
SQLITE_OMIT_SHARED_CACHE=1, -
_USE_STD_STAT=ENABLE) -
/FLOAT=IEEE_FLOAT -
shell.c
I copied the defines from the mailing list, and added /FLOAT=IEEE_FLOAT to get rid of most warnings regarding floating points (related to overflows due to exponent 308).
During compilation I got some informationals and warnings.
I get the following messages while linking:
$ LINK shell.obj,sqlite3.obj
...
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM, __STD_FSTAT
%LINK-I-UDFSYM, __STD_STAT
...
Since I am a little bit lost here, I rather have SQLite3 sources which compile on OpenVMS.
The specific problem you're getting from the linker arises from the fact that you've requested capability at compile time that your system doesn't have. I believe the _USE_STD_STAT option first became available in OpenVMS v8.2, yet you're on 7.3-2. Your compiler and your headers know what to do when _USE_STD_STAT is defined, but the functions to process the X/Open-compliant stat structure do not exist in the C run-time (CRTL in VMS parlance) on your system, and your linker is telling you, "ain't got those functions."
Ideally you would be able to upgrade your operating system. Current as of this writing is v8.4. v7.3-2 was released eight and a half years ago and v8.2 over seven years ago. I understand that there are technical, budgetary, and even political reason that upgrades aren't always possible. If it were me, and I were stuck on OpenVMS Alpha v7.3-2, I would try removing the _USE_STD_STAT=ENABLE from the compilation and see what blows up.
One of the side effects of enabling _USE_STD_STAT is that you also get _LARGEFILE along with it. If that's the only reason SQLite needs the option, you may be fine but limited to 4GB databases. I suspect there's more to it than that, i.e., SQLite very likely makes use of elements in the stat structure that do actually require the newer structure.
You can read up on the differences in the traditional and standards-compliant stat structures at http://h71000.www7.hp.com/doc/84final/5763/5763profile_062.html#index_x_1699.
I've recently improved my VMSish patch for SQLite and made it available for SQLite version 3.7.14.1: http://www.mail-archive.com/sqlite-users#sqlite.org/msg73570.html (or http://sqlite.1065341.n5.nabble.com/Building-SQLite-3-7-14-1-for-OpenVMS-td65277.html).
POSIX locking still doesn't work though, and I was unable to find out why.
Well, there was a message on the sqlite-users mailing list on getting SQLite 3.7.9 working on OpenVMS. I don't know how relevant that is to the version you've got (or if the patch was adopted by the SQLite developers; they're a bit picky for legal reasons IIRC) but it looks likely to be useful. Good luck.