Re: Safely remove USB drive

2023-02-23 Thread Andrew Grillet
A great bit of work.

Do you know if USB DAT drives are working on Sparc64? They were not when I
last tested (probably OBSD 6.2).

Andrew

On Mon, 13 Feb 2023 at 13:02, Crystal Kolipe 
wrote:

> On Thu, Feb 09, 2023 at 09:20:48PM -0300, Crystal Kolipe wrote:
> > There is no reason why we couldn't implement support for 'eject -t' for
> sd
> > devices, (which is internally treated as a tape retension command).
> >
> > In fact, I just made a patch to do that out of curiosity and was able to
> > access the usb device again after 'reloading' it.
>
> Over the weekend I received a few emails off-list asking me about this, so
> I've written up and posted a brief explainer here:
>
> https://research.exoticsilicon.com/articles/eject_command_hacking
>
>


Re: recommended partitions to backup with dump

2022-08-25 Thread Andrew Grillet
Remember that some that some things need to be explicitly dumped -
eg databases and repositories
because when you do restore, you might want to restore to an upgraded OS
version.

Rather than use dump, I use gtar - I have restored stuff after 30 years
with gtar,
to completely different OSes - eg OS/2 to OBSD! *
If you do GFS (four tapes: grandfather, father, son, and NEXT), each tape
is approximately
used once per month, and can be expected to have quite a long life. The
"Son" tape
is kept near the drive, the "father" tape goes off-site.

You tape from the disk backup (done with rsync) machine - databases and
repositories can
have hot standbys on the same machine.

In case of disaster recovery, step 1 is to duplicate the "father" tape off
site. Then you still
have a chance of knowing how bad things are before you accidentally
overwrite the "son".
Once a year, you can put one father tape aside for archive, and replace
with a fresh tape.
Possibly twice a year - to maintain a second, completely separate, archive.

If you don't use tapes, expect to lose data one day.

I am probably the only person to have restored data from VMS to BBC Micro
using 1600BPI reel to reel tapes.
(Probably the only person to have a BBC micro with both reel-to-reel tape
and ST506 interfaces).

Andrew

* ICL George 2 to VMS only worked with no compression, and George 2 to Cray
:-) required
an assembler program to convert between the two different the 6-bit ASCII
character sets
on 7-track 556 bpi tapes.


Re: Is it true that `dd` is almost not needed?

2021-12-12 Thread Andrew Grillet
"The era of magnetic tapes" has not ended.

It is just that some people mysteriously believe their data is safer "in
the cloud" where they cannot monitor it,
than on a tape in a fire safe under their own supervision. I have read back
tapes I wrote myself 30 years earlier.
Have you tried getting your data back from a deceased "cloud provider"?

That is why we get all these stories of ransomware attacks.

Also, for many of us that have spent half a century learning Unix, we do
not want our well proven tools snatched from our hands.
There is room for more than one knife in a virtual tool box.

On Sat, 11 Dec 2021 at 23:58, Stuart Longland 
wrote:

> On Sat, 11 Dec 2021 18:06:43 +0200
>  wrote:
>
> > The Cult of DD
> > Mar 17, 2017
> > You'll often see instructions for creating and using disk images on Unix
> > systems making use of the dd command. This is a strange program of
> > [obscure provenance](https://en.wikipedia.org/wiki/Dd_(Unix)) that
> > somehow, still manages to survive in the 21st century.
> >
> > Actually, using dd is almost never necessary, and due to its highly
> > nonstandard syntax is usually just an easy way to mess things up. For
> > instance, you'll see instructions like this asking you to run commands
> > like:
> >
> > […snip…]
> >
> > 
> > End of article and my questions:
> >
> > Is the author right in general?
> > Is the author right for Linux environment?
> > Is the author right for OpenBSD environment?
>
> Can `cat`/`tail` et all, create a "sparse" file?
> > vk4msl-gap$ dd if=/dev/zero bs=1M count=1 seek=9 of=sparsefile
> > 1+0 records in
> > 1+0 records out
> > 1048576 bytes transferred in 0.009 secs (108639200 bytes/sec)
> > vk4msl-gap$ ls -lh sparsefile
> > -rw-r--r--  1 stuartl  stuartl  10.0M Dec 12 08:42 sparsefile
> > vk4msl-gap$ du -hs sparsefile
> > 1.0Msparsefile
>
> Very useful for "thin provisioning" of raw disk images with virtual
> machines.
>
> Can `cat`/`tail` et all read bytes from the middle of a file?
> > vk4msl-gap$ echo -n '000102030405060708090a0b0c0d0e0f' > test
> > vk4msl-gap$ dd if=test of=test.part bs=2 skip=4 count=4
> > 4+0 records in
> > 4+0 records out
> > 8 bytes transferred in 0.000 secs (66541 bytes/sec)
> > vk4msl-gap$ cat test.part
> > 04050607
>
> Can `cat`/`tail` et all overwrite specific bytes in the middle of a file?
> > vk4msl-gap$ echo -n 'aaabacad' | dd of=test bs=2 count=4 seek=8
> conv=notrunc
> > 4+0 records in
> > 4+0 records out
> > 8 bytes transferred in 0.000 secs (98985 bytes/sec)
> > vk4msl-gap$ cat test
> > 0001020304050607aaabacad0c0d0e0f
>
> I think you'll find `dd` was written in the era of magnetic tapes as a
> storage medium, and so the ability to seek to a specific part of a tape
> then perform a read or write, was seen as a critical feature of the day.
>
> That same feature is handy when doing various low-level disk operations
> as well (e.g. backing-up/restoring the boot sector/partition table).
> --
> Stuart Longland (aka Redhatter, VK4MSL)
>
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
>
>


Re: Sparc64 LDOM not working past OpenBSD 6.5

2021-05-12 Thread Andrew Grillet
I have a T1000, and it runs 6.9 in primary and 7 guests.
However, attempts to create and install a new ldom config result
in complete loss of the device tree, and consequent inability to boot.

restore to factory, and then restore the ldom config created with OBSD 6.3
will produce a working system.

This system is available and currently could be used for testing, although
not on the public internet, and only during office hours in Europe/London
timezone - machine must be shut down out of office hours.

Andrew
.

On Wed, 12 May 2021 at 03:22, Ax0n  wrote:
>
> I have a SunFire T2000 that I originally installed 6.1 on. I set up LDOMs
> way back in May 2017. I kept all of the domains up to date until OpenBSD
> 6.6. After that, LDOMs would no longer work. The system would not boot
> unless I reverted back to the single domain default using
> bootmode config="factory-default"
>
> I kind of just forgot about the machine until 6.7 came out. I upgraded, and
> got the same errors upon trying to boot. I re-generated the LDOM config as
> outlined in this blog post I wrote:
>
> http://www.h-i-r.net/2017/05/logical-domains-on-sunfire-t2000-with.html
>
> That is, I dumped the factory-default config, used it as a template for the
> new LDOM configuration, edited a config file, applied the config to the
> directory and used ldomctl download to apply the LDOM config before
> resetting the system.
>
> Specifically, the errors I get now (and yes, some are repeats, but it's ALL
> I get from the console while booting) are:
>
> ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
> ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
> ERROR: /pci@780: Invalid hypervisor argument(s). function: b5
> WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node
> WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node
>
> And after that, the system hangs and I must exit to the ALOM system
> controller prompt to do anything further, such as revert the configuration
> and reset to make the system able to boot again.
>
> I searched and found one other person with this problem a while back ago,
> but no resolution. I have hardware right here in front of me and I'm not
> afraid to run -CURRENT and/or test patches to help. I am also willing to
> provide remote SSH access to the system controller if someone wants to hack
> on the hardware directly if it would help, though I think there are a few
> LDOM-capable sparc64 machines in developers' hands already.
>
> dmesg:
> console is /virtual-devices@100/console@1
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2021 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
>
> OpenBSD 6.9 (GENERIC.MP) #794: Sun Apr 18 12:34:31 MDT 2021
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
> real mem = 34225520640 (32640MB)
> avail mem = 33608228864 (32051MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root: Sun Fire T200
> cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu2 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu3 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu4 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu5 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu6 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu7 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu8 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu9 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu10 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu11 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu12 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu13 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu14 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu15 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu16 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu17 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu18 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu19 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu20 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu21 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu22 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu23 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu24 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu25 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu26 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu27 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu28 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu29 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu30 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu31 at mainbus0: 

Release schedule/general product engineering

2021-04-22 Thread Andrew Grillet
One of the key strengths of OpenBSD that it is well engineered - and
consequently robust
and reliable.

Management of the release engineering is key to this. (Cathedral, not bizarre).

However, release engineering is no longer mentioned on the home page
of www.openbsd.org,
and I could find no mention of it anywhere on the site.

  I wanted to know approximately when the next release would be
available to decide
  whether to install 6.8, a snapshot or wait for 6.9 for a machine I
have prepped and am
  going to configure "real soon now".

I also can no longer find architecture-specific change logs (to see if
work has been
done that might affect Sparc64 installs, and make things different from when I
installed 6.8 on this hardware last time).

*** I think it is worth making this info more visible both for
existing users (eg me) and
potential future users ***

I believe there will be future users (Netcraft notwithstanding) -
people are often p'd off
by other operating systems introducing new features they don't need
which clobber
the old ones they do - and might want to know there is a better way!
(Even if they don't use Sparc64). [Written in anticipation  of a
general drift away from
Intel and towards Arm by both server and workstation users]. There is
also the possibility
that people who have been hit by malware might want a more secure solution.

regards

Andrew



How to unlock a serial port

2021-01-14 Thread Andrew Grillet
Hi

I am running OpenBSD on a T2000 (Sparc64).
I was trying to use the serial port from the primary domain, connected via
ssh, and my network lost the connection.
My tty00 is now locked:
jay# stty -f /dev/tty00
stty: /dev/tty00: Device busy
I do not want to reboot the primary, as the guests are running various live
services. I cannot find evidence of a lock file in /dev/spool/lock.
Is there a way out of this predicament?

Andrew