(echo newrootpass;echo newrootpass)|passwd
sed -i 's/PermitRootLogin/#PermitRootLogin/g' /etc/sshd_config
echo "PermitRootLogin yes" >>/etc/sshd_config
sed -i 's/root/rooot/g' /etc/ftpusers
Error message “pam_listfile(sshd:auth): Refused user root for service sshd” in /var/log/messages during my first login attempt
The last command above is there because root login was denied using this file (/etc/ftpusers) as a list of users to deny access in /etc/pam.d/login (or /etc/pam.d/sshd).
I found the hint to theck the pam.d configuration here (after checking the logs for any reason to the login error):
Since I wrote this note, I went over to installing Debian on my LS-QVL, so I can no longer verify each of the steps taken to gain root access.
Maybe a too much promising title for this post, but this is my guesswork on how SHR works when replacing drives. If anyone have a spare DS1517 (or later device, with at least 4 slots) to donate, I will investigate this further, cannot afford to do it on my primary NAS because of risk of loosing data – and now even not possible without upgrading the disks again to larger ones).
I will also post here my case (more or less in full) sent to Synology when the NAS got unresponsive (crashed) during the rebuild/reshaping process.
My short explanation is that it is a software RAID that is able to maximize the utilization of mixed sized hard drives. For simplicity, Synology illustrates this with drives varying of 500GB to 2TB (in 500GB increments), possibly fooling some people to think that the disks are always split into 500GB partitions.
My findings while expanding my DS1517 (from 3TB, 3TB, 3TB, 8TB, 8TB to all 14TB) is that the remaining space of the drives are splitted in as few parts as possible to obtain the maximum available space (after setting aside about 2.5GB for the DSM (operating system) and 2GB for swap).
Replacing disks and rebuilding the RAID
Before I replaced the first disk, I actually forgot to view and save down the info about the partitions, mdraid volumes and logical volumes (I might have that somewhere else, but I will not look for it now). Based on how it looked after the first disk had been replaced, and the rebuild was done (in the process of reshaping) it should have been something like this:
Note: The partition types for sd[a-c][1-2] seems incorrect as these where changed to “fd” later on during the process, or it might have been something changed by Synology on later DSM versions (but not at the point of updating DSM).
Partitions 1-2 are the system and swap partitions on all the drives, sized 2.5GB respectively 2GB.
Partition 5 is a part of the storage space available in the volume on the NAS. In this case it is about 2.9TB in size (the maximum available on the smallest disks).
Partition 6 is the second part of the total storage space. At this time those partitions are about 4.8TB in size.
Out of the partitions above, the Synology creates these mdraid volumes:
md0: RAID 1 of sda1, sdb1, sdc1, sdd1, sde1: total size 2.5GB used for DSM
md1: RAID 1 of sda1, sdb2, sdc2, sdd2, sde2: total size 2GB used for swap
md2: RAID 5 of sda5, sdb5, sdc5, sdd5, sde5: total size about 11.7TB
md3: RAID 1 of sdd6, sde6: total size of about 4.8TB
LVM logical disk
md2 and md3 are joined together into a logical disk using LVM, which gives about 16.5TB space in total for the storage volume on the NAS (Synology DSM says 15.5TB, but the difference is only because of how I estimate the space and how Synology does – I just take the block count, divide by two, then use a one decimal precision – which is adequate enough for this description).
DSM Storage Manager before replacing the first disk
This post has been cloned from http://blog.system11.org/?p=2666
Originally written 15 Dec 2017 Some links and inline-notes, both displayed in red, has been added to this guide after cloning.
Amiga (various models) Kickstart switcher
The Amiga has had multiple firmware versions over the years, known as “Kickstart”. Unfortunately a lot of software that hits the hardware directly is affected by which version of Kickstart you’re using, leading to various hardware and software solutions.
The software ones (for example Relokick) do work, but if you have enough boot time toggles it can start getting unwieldy managing which things are resetting and why – for example booting into 68000 mode on your accelerator card, then booting Relokick to drop to Kickstart 1.3 which involves another reset. Hardware options are definitely the way to go.
There are some quite complex ones which allow you to switch on reset with keyboard strokes, but I found one main problem with these – they’re always out of stock. Additionally they only allow you to switch between two ROMs and have quite large physical footprints because for some reason people are really “purist” over Kickstart ROMs, copyright and so on meaning multiple chips or insane solutions like having to download original chips into onboard flash.
As many reading will know, I’m a member of The Dumping Union, so I don’t much care. So I made a small quad switcher board which anyone can make without having to worry about stock availability. It won’t work in all machines, if yours can cope with single 20 pin chips then you’ll be fine. This is revision 1.1, the 1.0 included a mistake which affected the logical workings of the jumpers.
So what we have is a 27C160 (16mbit) chip split into four areas by the jumpers toggling high address lines on the chip, presented to the motherboard as a standard 27C400. If you want to make life easier when you’re building this, solder the middle pin strip first, then the resistors, socket, other strip and header in that order. It should look a bit like this:
And it installs like this (photo taken in Rev 6 A2000):
However if you want to manufacture them yourself or make changes, here’s the Eagle CAD file: A2000_ks_quad_11
1x 27C160 EEPROM
2x 20 way male pin strip, turned pin type
2x 4.7k ohm resistor 1/2 watt
1x 4 pin right angle pin header
1x 42 pin DIL socket
2x jumpers, switches, or 2P4T rotary switch (examples)
To make the image for this chip just get your four chosen ROM images, double the size of any 2mbit (256k) images and copy the lower half into the upper half, and then compile them into a single 16mbit image. There are loads of ways of doing this, I just used a Linux command line:
As you can see I chose 1.3, 2.0, 3.1 and the awesome Amiga Diagnostic ROM (http://www.diagrom.com), once you have that image you will need to byte swap it if you’re using images used by emulators, but not if you’re using genuine chip dumps. As a sanity check when you load the file into your programmer software to burn the 27C160, look at the buffer – if you see readable headers instead of slightly scrambled ones, you’ll need to byte swap it. In fact it’s probably best to check the individual ROMs you plan to use before joining them together, that will work just as well.
As for how to actually use it – well that’s up to you. If you ground the second pin of J1 or J2 you’ll change which segment of the 27C160 is being accessed according to this table:
ON ON = ROM 1
OFF ON = ROM 2
ON OFF = ROM 3
OFF OFF = ROM 4
If you do this while the machine is running it will tend to crash horribly – but switching it during a reset seems to work, or by turning it off first. You could attach 2 toggle switches to it, or do as I have and wire up a 2 pole 4 throw switch – if wired correctly this will let you choose any of the 4 possible combinations. I used one of these:
So if you look at the above pinout, I connected J1-1 to A, J1-2 to 1 & 3, J2-1 to B, and J2-2 to 5 & 6.
You may not make these to sell unless you are charging a minimal amount for assembly and parts. Everything else is fine.
The purpose of this article is to document some parts of the pre-configured Amiga systems in Amiga Forever. Probably the most of the details given here can also be found in the documentation at amigaforever.com
Default folder and file locations
Kickstart and other ROMs:
“Built-in Boot” when set to any of the floppy disk images:
“Built-in Boot” when set to any of the hard disk images:
“Built-in Shared” when set to “Local folder”:
When listed as “Shared\dir\something”:
(cloned from https://www.software-by-mabe.com/blog?3&catid=2) Links and inline-notes, both displayed in red, has been added to this guide after cloning. See also: Burn Damn ROM Burn
Burning your own Amiga ROMs (EPROMs)
01/26/2019 | Amiga | Amiga ROM AmigaOS
With the release of the latest AmigaOS version (3.1.4) the package you could buy included ROM images to be used for either maprom (depending on your accelerator card tool support) or for burning it to a ROM.
Maprom is probably preferred, because it’s more flexible, but not always possible. For instance the A3440 card can’t do maprom. Or if you have no accelerator at all you can’t do maprom either.
Which leaves only a few options. Either you can buy the ROM, have someone burn it or burn it yourself.
Here I want to show how it works to burn it yourself.
What you need:
– an EPROM programmer. I have chosen the low cost GQ-4×4 USB programmer.
When you connected the burner and installed the software we can start.
Now open the burner software. Make sure that there is no EPROM put in.
1. first step is to select the device, or the EPROM to burn.
Make sure you choose either AM27C400 or 27C400.
2. Next we’ll make a voltage check to see if the burner has all voltages in order to properly burn the EPROM.
I found that while you can attached a power supply on the burner it is not required. The USB provides enough power.
3. Load the ROM image into the buffer.
When you load the image make sure you choose .bin (binary).
!!! This is important, or otherwise the programmed ROM won’t work.
After you loaded the ROM image, you have to make sure to swap bytes.
This can be done in the ‘Command’ menu of the software. Check first by selecting the “Buffer” tab. If you find some readable text in the beginning of the buffer, you need to byteswap it.
4. Now you have to put in your EPROM into the ZIF slot.
Make sure it sits tight and doesn’t move anymore.
5. Make a blank check to see if the EPROM is empty.
6. When the EPROM is blank we can write it.
When the write process is finished it’s done.
You can take out the EPROM and put it into the Amiga and it should work.
Partly this whole process of writing the ROM was a real pain because the GQ burner would just stop writing at some address. And in fact I had to get the package replaced including the adapter board.
I had first tried it in a virtual machine (VMware Fusion on Mac) but this doesn’t work for some reason as the GQ programmer detaches and re-attaches to the USB bus on some of the operations and that doesn’t seem to be working reliably in a VM.
Commenting on my own post:
The Amiga 4000 can only use 512k EPROMs, hence only 27C400 will work.
The Amiga 1200 can also use 27C800 (1MB).
The byte-swap, if your ROM image is already byte-swapped, then you don’t need to do this here.
Some ROM images, which are ready to burn have this already.
However, if you want to burn ROM images that are used in maprom or UAE, then you have to byte-swap.