¿ªÔÆÌåÓý

  1. HP-Agilent-Keysight-Equipment
  2. Topics

16901A 16901-14102 recovery disc ISO wanted (was Re: [HP-Agilent-Keysight-equipment] Wanted: 16902B recovery DVD, p/n 16902-14100)

 

Pn Thu, Jul 18, 2024 at 8:13?AM Mark Litwack via <mlitwack=[email protected]> wrote:
Be patient; I think it's un-tarring this gigantic tar file on demand to generate the list.

I'm now working on my 16901A rather than the 16902B I previously mentioned.

As it turns out, being patient isn't enough. When I try to download any of the recovery DVD .iso files from the tarball file list, I can only download a little over 1GB, out of any of the 2+GB images, before Internet Archive closes the connection with no error reported, resulting in a truncated file. The exact length varies a bit, but I think what is happening is that it hits a time limit.

I found that I can download the ENTIRE ~200GB tarball. I did that over http, taking a lllloooonnnngggg time, and then extract a 16901A (M880 motherboard, 16901-14102.iso) recovery image, The 16901-14102 recovery image appears to be corrupted. Upon boot, during the execution of AUTOEXEC.BAT, something clears the screen but then prints something like "Opcode error: [line of hexadecimal crap]". I should have taken a photo. Then it drops me to a "-" prompt for FreeDOS.

Poking around, I found that I could manually start the recovery process, by doing what AUTOEXEC.BAT normally does, CDing into \Recovery then running recovery.exe. This gets the Symantec Ghost Corporate 8.0 working restoring the disk drive from the ghost image. However about 3/4 of the way through this fails, clearing the screen and displaying "ABORT: 19235, Decompression error -5".

If I run the ghost client manually, and ask it to verify the image, it gets the same error at the same place.

So I thought that either:
1) The recovery .iso image was corrupted during my download
2) The logic analyzer motherboard isn't working right

To rule out #1, I downloaded the entire 200G tarball again, but using the torrent. This was much faster, but more importantly, the torrent file contains a hash of every 4MB block of the download. Oddly enough, the torrent download failed to get the XML metadata that IA associates with the image, and one of the padding files they added. However, it successfully gets the .iso image and the other (unneeded) metadata and padding files.

The .iso image downloaded by torrent is byte-for-byte identical to the one I got by http, so it is nearly impossible that either got garbled in the transfer between IA and me.

To rule out #2, I installed a Linux distribution (Fedora 25) on the analyzer, and ran a memory test for a while. This worked fine, with no errors.

My conclusion, therefore, is that the tarball that IA created in 2015 has a corrupted 16901-14102 ISO image. That could be either because corruption occurred when IA retrieved it from , or the actual file on was corrupt. (Or there's something more subtly wrong with my 16901A than seems likely.)

So my questions are:
1) Has anyone else tried to actually use the 16901-14102 recovery disc image from Internet archive? (I could provide a copy if anyone cares to try it without having to do the 200G download.)
2) Does anyone have a physical 16901-14102 DVD from which they would be willing to rip an ISO?

Thanks!

Eric
 

On Fri, 30 Aug 2024 at 07:41, Eric Smith via <spacewar=[email protected]> wrote:
Pn Thu, Jul 18, 2024 at 8:13?AM Mark Litwack via <mlitwack=[email protected]> wrote:
Be patient; I think it's un-tarring this gigantic tar file on demand to generate the list.

I'm now working on my 16901A rather than the 16902B I previously mentioned.

As it turns out, being patient isn't enough. When I try to download any of the recovery DVD .iso files from the tarball file list, I can only download a little over 1GB, out of any of the 2+GB images, before Internet Archive closes the connection with no error reported, resulting in a truncated file. The exact length varies a bit, but I think what is happening is that it hits a time limit.

You could try curl, which has the option of resuming at a specific location. If you do that, I would test out on some small pieces first. Download first 1 MB, then the 2nd 1 MB, then see if you can concatonate them to create the same as if you download the first 2 MB in one piece.

drkirkby@canary:~$ curl --help
Usage: curl [options...] <url>
? ? ?--abstract-unix-socket <path> Connect via abstract Unix domain socket
?-C, --continue-at <offset> Resumed transfer offset
?-b, --cookie <data|filename> Send cookies from string/file

--
Dr David Kirkby Ph.D
Kirkby Microwave Ltd
Email: drkirkby@...
Web:
Telephone 07910 441670 (UK) or +44 7910 441670 (international)
Registered in England and Wales, company number 08914892.?
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Essex, CM3 6DT
 

Or use "wget -c" which is similar to what Dr. Kirkby said but using "curl".

For me archive.org also fails in 90% of the cases but I retry it and
continue using wget and -c option.

If you don't use Linux, you can find a compiled version for M$ Windows
for the wget.

On 30/08/2024 14:41, Dr. David Kirkby, Kirkby Microwave Ltd via
groups.io wrote:
On Fri, 30 Aug 2024 at 07:41, Eric Smith via groups.io <
groups.io> <spacewar@... <mailto:[email protected]>>
wrote:

Pn Thu, Jul 18, 2024 at 8:13?AM Mark Litwack via groups.io <
groups.io> <mlitwack@...
<mailto:[email protected]>> wrote:

Be patient; I think it's un-tarring this gigantic tar file on
demand to generate the list.


I'm now working on my 16901A rather than the 16902B I previously
mentioned.

As it turns out, being patient isn't enough. When I try to download
any of the recovery DVD .iso files from the tarball file list, I can
only download a little over 1GB, out of any of the 2+GB images,
before Internet Archive closes the connection with no error
reported, resulting in a truncated file. The exact length varies a
bit, but I think what is happening is that it hits a time limit.


You could try curl, which has the option of resuming at a specific
location. If you do that, I would test out on some small pieces first.
Download first 1 MB, then the 2nd 1 MB, then see if you can concatonate
them to create the same as if you download the first 2 MB in one piece.

drkirkby@canary:~$ curl --help
Usage: curl [options...] <url>
? ? ?--abstract-unix-socket <path> Connect via abstract Unix domain socket
*?-C, --continue-at <offset> Resumed transfer offset*
?-b, --cookie <data|filename> Send cookies from string/file

--
Dr David Kirkby Ph.D
Kirkby Microwave Ltd
Email: drkirkby@...
<mailto:drkirkby@...>
Web: <>
Telephone 07910 441670 (UK) or +44 7910 441670 (international)
Registered in England and Wales, company number 08914892.
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Essex, CM3 6DT
 

¿ªÔÆÌåÓý

If someone wants to send me a URL, I could try pulling the file from a fast connection.
 

On Fri, 30 Aug 2024 at 19:04, Ed Marciniak via <ed=[email protected]> wrote:
If someone wants to send me a URL, I could try pulling the file from a fast connection.

Unfortunately is slow, so irrespective of what speed you have, you are not going to be able to download it quickly.

I would suggest trying wget, curl, or at a time when the majority of people in the USA
are asleep. I believe that internet traffic is lower at those times, so I guess speeds might go up.?
 

On Fri, Aug 30, 2024, 12:04 Ed Marciniak via <ed=[email protected]> wrote:
If someone wants to send me a URL, I could try pulling the file from a fast connection.

Thanks, but both of my downloads of 16901-14102.iso from IA were done over gigabit fiber. That's not the limiting factor. Also, I have with very high confidence determined that the IA copy is corrupt, hence my request to anyone who might have the physical DVD.
 



On Fri, Aug 30, 2024, 12:22 Dr. David Kirkby, Kirkby Microwave Ltd via <drkirkby=[email protected]> wrote:
I would suggest trying wget, curl, or at a time when the majority of people in the USA
are asleep.

Using wget, it took about 36 hours to download the 200GB tarball over gigabit fiber. My second downloaded was via torrent, which has error checking. That took about four hours, and the results was identical. That's why I'm fairly sure that the IA archived copy of 14901-14102.iso is corrupt.

I don't think more people trying to download it is going to help. That said, if anyone else does download it, we can compare sha256sum of the overall archive, or the individual .iso images.
 

Here's the images I have
?
?
File sizes and MD5sums
?
-rwxr-xr-x 1 root root 1874239488 Mar 21 ?2019 16900-14121.ISO
a3832026cd7817a2e2b958f8eb3ed78b ?16900-14121.iso
?
63197d5ffe6697ae5b7cc05a283c6d0e ?16900-14122 BIOS Upgrade.iso
-rwxr-xr-x 1 root root 67776512 Mar 21 ?2019 '16900-14122 BIOS Upgrade.iso'
?
For the IA download stuff, you should use something like aria2c:
?
This allows multiple streams.... I usually use is -x 16 and -s 16 arguments. Works great.
?
While I haven't figured out the exact limitation, I'm pretty sure the peering arrangements for the various transiting providers limit each individual connection to just under 4MB/s. If you're seeing that magic number, then that's what's happening. I've seen this for years across a variety of places.... so you need to use multiple connections.
?
The other thing, is IA has a TON of bandwidth. If you can get closer to them, without transiting, you'll get ridiculous speeds. I'm talking like 20gbps. It's a bit of a pain in the butt just to download something, but it works. I use FTP to backhaul stuff from machines closer to San Francisco, with multiple streams.... usually (10) at a time with programs like WinFTP.
?
With all these suggestions, you need to point this to the actual endpoint where the file is stored..... the path will be revealed when you try to download normally.... If you just point to the link you hover over in your browser, it's not going to work, because aria2c etc won't always follow depending on how they do it.
?
Hope this helps.
?
 

¿ªÔÆÌåÓý

I wonder whether internet archive simply has TCP 1323 window scaling options disabled or clamped to a low maximum, or something like path mtu discovery broken by blocking ICMP type 3 code 4 packet too big messages (or both). In general firewall policies deny everything not explicitly allowed, so allowing ping and perhaps trace route and then denying other ICMP messages can lead to poor or even broken behavior. All modern operating systems, at least those not on IOT devices expect to discover path maximum transfer units by sending ?packets with the don¡¯t fragment but set, and using the ICMP messages they expect to receive to adjust their sending size. This leads to interesting problems like TCP handshakes that succeed then, due following a certificate exchange setting up SSL/TLS encryption or poor throughput when (if) fallback occurs.

This is conjecture, as I haven¡¯t taken packet captures to confirm.
 

Maybe only on certain interfaces?
?
There's definitely nothing wrong w their configuration when you're close (network and latency-wise) to them. I mean, they often saturate the SSD disk writing limits(usually artificially limited by the providers) on the boxes I setup. Nothing handicapped there!
?

1 - 10 of 10