Thursday, April 20, 2017

support for ancient ubuntu releases


I've got a couple of machines that probably won't upgrade nicely, and the "gee why can't you upgrade them" comments are useless.  The ones I had were appliance downloads popular at the time I obtained them, and there was not the usual trail of how they were built accompanying them.

since one is my email archive I will continue to run it till SMTP POP3 and IMAP protocols die without any update.

Here is a link which worked for my oldest version, hardy, which is Ubuntu 8.  The date of the release is to probably 2006 maybe earlier.

https://superuser.com/questions/339537/where-can-i-get-the-repositories-for-old-ubuntu-versions

Here is the most useful answer (including the useless suggestion to update). 

**********************

Your system is End-of-Line (EOL), therefore not officially supported. Unless you have a good reason for sticking with 9.04, upgrade to a newer version. 16.04 is the next long-term supported release for Ubuntu, which will continue to receive updates.
To access old Ubuntu repositories, take a look at http://old-releases.ubuntu.com/.
There is also an official Ubuntu documentation for EOL upgrades
They say you should be able to access your packages by putting the following into /etc/apt/sources.list. Important: Change CODENAME to your distribution's code name, e.g. jaunty.


## EOL upgrade sources.list
# Required
deb http://old-releases.ubuntu.com/ubuntu/ CODENAME main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ CODENAME-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ CODENAME-security main restricted universe multiverse

# Optional
#deb http://old-releases.ubuntu.com/ubuntu/ CODENAME-backports main restricted universe multiverse
 
 
Just run apt-get update and you can use them.

Thursday, April 6, 2017

Migrating Readynas Radiator to OS 6 Readynas devices


One challenge in migrating from Sparc architecture products, to Intel or other (Arm), is that the Linux file system on sparc was built with a 4k block size, rather than 512.

On Intel linux, if you set up your disks, you can mount them with some incantations and special procedures.  Not sure how the Readynas Linux handles that problem, but there is a link showing it.

I had a bad disk and some problems with the data recovery firmware on a REadynas NV+ some years ago and got the support group to help me get around it.  In the mean time, I had mounted the 4 drives on an Intel linux system I'd built up and had recovered most of the data.

https://kb.netgear.com/29875/ReadyNAS-Migrating-disks-from-RAIDiator-to-OS-6?cid=wmt_netgear_organic

Copy of article for archival:

This articles outlines the necessary steps to access data on disks from ReadyNAS units running RAIDiator on ReadyNAS OS 6 units.
Due to differences in CPU architecture and operating system between RAIDiator and ReadyNAS OS 6, it may be necessary to take additional steps once the disks are moved to an OS 6 chassis.
If your ReadyNAS running RAIDiator is still functional, and you can access the data, we recommended you first backup the data to another location
http://kb.netgear.com/app/answers/detail/a_id/21344
If you can no longer access the data using your legacy ReadyNAS and you wish to access the data using your ReadyNAS OS 6 device, booting may not be as easy. Depending on which legacy model the disks come from, and which ReadyNAS OS 6 you posses the steps differ to make the data accessible.
After initially moving the disks from the legacy ReadyNAS to the ReadyNAS OS 6 model please be aware of the following items;
  • Do not attempt an OS reinstall
  • Do not attemp a factory reset
  • The RAID must be healthy i.e. if the RAID was broken on the legacy NAS it will not always be possible to access the data on the ReadyNAS OS 6 - an example of this would be 2 failed disks in a 4 disk RAID 5.
  • ReadyNAS OS 6 model must have at least the same amount of drive bays as the legacy ReadyNAS
  • Logging a ticket with Technical Support may be required
  • Purchasing a data recovery contract may be required
  • You may require one additional spare blank disk
  • You may require an external location to where you can recover your data to i.e. external USB HD, network share, other NAS storage.
To find the steps needed to access the data on your ReadyNAS OS 6 device, find your model below:
  • ReadyNAS OS 6
    • ARM
      • ReadyNAS 100 series (RN102, RN104)
      • ReadyNAS 200 series (RN202, RN204)
      • ReadyNAS 210 series (RN212, RN214)
      • ReadyNAS 2120 (RN2120)
    • x86
      • ReadyNAS 300 series (RN312, RN314, RN316)
      • ReadyNAS 500 series (RN516)
      • ReadyNAS 700 series (RN716X)
      • ReadyNAS 3130 (RN3130)
      • ReadyNAS 3138 (RN3138)
      • ReadyNAS 3220 (RN3220)
      • ReadyNAS 4220 (RN4220)
Find the model of your Legacy ReadyNAS running RAIDiator, click on the link and follow the instructions. X represents whether or not your model came with disks.



Tuesday, April 4, 2017

NFS Client and Server setup pages


To set up NFS Client and Server functions on Debian, et. al. here are some notes

NFS Server

apt-get install nfs-kernel-server nfs-common

NFS Client

apt-get install nfs-common

Exports

/home/jws           192.168.0.101(rw,sync,no_subtree_check)
/var/www        192.168.0.101(rw,sync,fsid=0,crossmnt,no_subtree_check,no_root_squash)

Other setup details related to mount @ boot time, etc., refer to link below.

Examples above from:

https://www.howtoforge.com/install_nfs_server_and_client_on_debian_wheezy

Tuesday, March 28, 2017

Readynas Radiator 4.1 firmware problem with SMB CIFS shares


The changes made to SMB protocol from version 1 to version 3, seems to have killed the share mode of access on readynas older systems.

Switching to user share mode and creating a user is a pain as well.

But the share name is entered as a user id in passwd, but not put up as a user in the gui, which is a huge hole when you switch from share to user.

the only method of fixing it is to install EnableSSHAccess and log in as root.  One can then set an SMB passwd on the shares that exist, and each will be accessible with that passwd on system thru so far and including windows 10.

Also other secured user access is then possible once the sharing is turned on if desired.  The users cannot access others storage w/o using group access features.

Of course this has a possibility of voiding any service you have with Netgear (warranty for 4.x devices is long gone).  But if you have any service agreements, don't do this w/o checking since it may impact your agreements for unauthorized user mods to devices.

To install ssh access for 4.x radiator do the following

Download EnableRootSSHAccess for your architecture from here

EnableRootSSHAccess

Original NV+ and 1100 systems are Sparc.  Pro and Ultra systems on 4.x will be Intel.  I'm not sure if Arm has a 4.x version.  All the ones I've seen with Arm are 6.0

then:

  1. Get the SSH bin file from the ReadyNAS web site. Click the Add-ons for RAIDiator 4.1.3+ link and scroll to the EnableRootSSH link. Download the bin file and store it on your local computer.

  2. Log in as admin on your ReadyNAS using a browser

  3. Update your ReadyNAS firmware (optional). This is under System > Update. Just click the Check for Updates button.

  4. Click the Local tab and click Choose File to find the EnableRootSSH.bin file that you previously downloaded. Upload this and follow the prompts.
 A restart of the Readynas system is required, if you have other users on the device.  (since some windows systems may work).  I doubt if any samba stacks such as one would have with shares on MacOS would work, but they may be impacted.

Install instructions from here;

http://blog.epdoc.com/2009/11/ssh-on-readynas-nv.html







CIFS mount problem on Linux, Error 12, can't allocate memory error


There is a workaround for this which is in the link below.

What worked however is this:

reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v Size /t REG_DWORD /d 3 /f
sc stop  LanmanServer
sc start LanmanServer

Will have to research and update link with whatever is being done, but this worked for mounting my Google driver server windows 7 system.

Windows Xp so far has not shown the problem.  Other options have been necessary too, this is just the latest.

Occured on a Cubox debian Wheezy system on 3/27/2017 for me.

mount-cifs-mount-error12-cannot-allocate-memory

Monday, March 27, 2017

Microdata, Decision Data, and Western Dynex boards


These boards showed up in an auction and Al Kossow kindly directed my attention to the boards, sold after the system was scrapped.

There is a clean set of spares from a 2400 RPM Dynex, probably a 6000 drive, including backplane and terminator.

There is a Decision Data + Intel manufactured processor and memory set, as well as an 8 slot backplane in the lot.

And there is a Microdata manufactured 1600 board set in the lot, but with Decision Data markings in the etch and some of the silkscreens.  This includes a larger 14 slot backplane.

Included in the Microdata set, is a CPU set, DMA board set, 2950 (Decision Data badged), and one (or two) A20002613 8ways.  The 2613 had full modem control.

There is also an 8 port DB 25 board, which should work with any of the 8ways available, hopefully via ribbon cables.

There is an interesting cabling setup with an additional 50 pin connector on the 8 port connector that will have to be investigated.

Both of the backplanes are powered via molex connectors, rather than the Microdata Paddle board approach in the last slot.

Boards from Western Dynex 2400 RPM drive, probably 10mb capacity.

A2 Control

Tag says 2400RPM.  I am going to infer this was for a 10mb (5 over 5) drive, since I doubt many 5mb drives were made at 2400RPM

Closeup of service tag.  shows 2400RPM

Sector Counter A1

Servo A3

Data A4

Backplane, Pin side, showing Terminator and input cable slot

A1 Sector Counter / Control
A2 Control
A3 Servo
A4 Data
Backplane Component side.  Both sides have 3 level WW pins available on all pins

Set of boards in backplane, best guess as to location

Closeup of the shot with the boards in backplane
Only one board identified as Servo is pretty certain.  I guessed from memory on the others.
Closer shot of the boards in backplane

Decision Data processor set

8 Way connector Top 2 cables are probably from 2613.  not sure what the other one did





8 slot backplane.
Since there are no keyways in the backplane, and none on the 2901 cpu set boards, I'm guessing this is the backplane for the newer system.

Also it only hs the single 12 pin Molex power connection.  There is an 8 slot rear of board connector on the memory board below, probably to supply +5 and maybe a minus voltage to the memory array, so the backplane supply is probably enough +and- 12 to run the 2613's and a lot of +5 and ground

2901 cpu and firmware
Sadly one rom is missing, so no firmware disassembly is probably going to happen.
2910 and other logic in second CPU set board
A 40 pin chip / socket has been totally scraped off this, as well as maybe some other damage.  Worst damage of the lot.
Intel Memory board
The Etch shows Intel (in Intel font) made this board.  All the chips are NEC though.  Guess all the work making the board didn't pay off for the Intel memory division, unless they distributed or resold NEC parts.
Memory array on the Intel board
The array is of 16K x 1 parts, and there are 11 parts in each column.  Suggesting single bit correction 2 bit detection ECC capability with the memory.

Total of 64K, which would align with what a Microdata 1621 firmware board would do.
Memory chips with legible part#s
NEC UPD416C-2 parts  Date code 85 maybe on one chip?
NEC UPD416C-2  Link copied 3/2017
NEC UPD416C-2  PDF data sheet link copied 3/2017

200ns 16k x 1 memory Page Mode Dram

Microdata Compatable / manufactured (In*sight) boards

A20002613 8 way with modem control

Microdata A20002515 DMA board

Microdata A20001242 Control CPU board

Microdata A20001043 Data CPU Board

Second A20002613 8 way with modem control

A20001044-1 Front panel interface

14 slot backplane for Microdata CPU. 
From the spacing and practicality of the design, the 1040 front panel board goes in the slot on the left in the backplane.  Microdata had a 12 slot  with 20 amps, and an 18 slot with 40 amps (or 20) of their own.

Some outfit named Elko Pacific made these backplanes.  The connectors do not match the most common Microdata part for their original backplanes.  CDC originated the backplane connector that Microdata used.

This connector may be from a 130 pin connector vendor who made parts for the later Reality 6000's 8000s, and Royale systems.  The 1040 backplane had a heavier bakelite / plastic component.
Closeup of Elko Pacific badge and power input
Serial numbering didn't match the style of Decision data which used such as 111DDxxxx numbering

Also the backplane termination is shown.
This is serialed 6-05607

Closeup showing more etch info
Type A 18801434-2
also various other inspection stickers
111MD01001 is the Decision data style part number and appears to be possibly silkscreened on

Serial I/O DB-25 panel
Will to figure out if there is anything more than a multipurposing of the design to have the extra 50 pin connector.  The Microdata A20002613's would have used two 50 ribbon cables to the board.

Possibly another design board made by Decision Data used just a single 50 and omitted some signals.

When Microdata originally licensed the CPU to people, they had a single port RS232 with modem control board, a 4 way which had no scanner.

There were two 8 port boards with scanners, the 2612 and 2613.  The 2613 was designed by Bill Homans as one of his first projects.  Both of those boards had a scanner feature which was clocked around to present the status lines of each 8way to the software.  There was logic to "lock" the scanner when a line had a status change.  Ports could be disabled, in input listen and lock mode, or in interrupt driven output lock mode.

A single address starting @ 0x18 in the 1600 address space would control the board.  The board had one interrupt for the board, and usually used firmware assist to run the boards.

The original 1600 could run well with the later A20002614 and A20002615 designs, but did not do that well with the 2612 or 2613.

Microdata Reality used the 2614, 2615, and Irvine Computer Corp 80010001 8ways for I/O.

The 2614 and 2615 had only to have ground, transmit and receive to work.

The ICC 8way added flow control in and out in hardware with some additions of hardware to monitor the Reality I/O state.

Friday, March 10, 2017

Notes for running Windows 98 (or older OS's) on Rpi


Snip from a posting about making up a Raspberry Pi running QEMU running Windows 98.  Mainly a QEMU note.

This part needs to be done on a Windows based computer, not the Pi:
I broke out my copy of Windows 98 and followed this chaps guide to get the .img file needed for the emulator, copied it over to my Pi (into ‘/home/pi’ for ease of access).
Now back to the Pi:
Don’t worry about the Youtube video in the post above, that is for an older version of Raspbian, now Jessie has QEMU available and easily obtainable by typing:
sudo apt-get update && sudo apt-get install qemu -y
Time to test it. Navigate to ‘/home/pi’ and run:
qemu-system-i386 -localtime -cpu 486 -m 96 -hda win98.img
QEMU should pop up and begin launching Windows 98, when its loaded have a click around and then shut it down as you would a normal 98 machine.
When QEMU has shut off it’s time to apply…

******************

https://www.raspberrypi.org/forums/viewtopic.php?f=41&t=117228

I just installed debian jessie on a desktop PC. Ran the update and upgrade. And then I simply ran the apt-get install for qemu. That allowed me to do the entire win98 install on the desktop PC.

After installing qemu, I used the following command to create the img file:

qemu-img create win98.img 1G

Then I used the following command to install windows from a win98 ISO created from an original install disk.

qemu-system-i386 -localtime -cpu 486 -m 256 -cdrom d win98se.iso -boot d -hda win98.img

Doing that resulted in a quick, clean, problem-free windows 98 install. It bypassed all the Win98 installation problems I was having on the RPI. And this works much better anyway since the desktop is a much faster PC to work with.

After the win98 install, I took the resulting img file and copied it over to the PI. And then I used these instructions to get qemu running on the PI.

https://www.youtube.com/watch?v=nrq_VtrnhHE.

After qemu installed, I used the following command to run 98 on the RPI.

qemu -cpu 486 -m 256 -hda win98.img

It's slow, but seems to work great. The only problem I have found is it does not close cleanly. It always hangs on shutdown which means it always does a scandisk when it restarts. If anyone has any ideas how to fix that, I'd love to hear them.