Copying disks with Linux - Revision history

PoC: /* Footnotes */ +cat

2026-04-14T21:40:28Z

Footnotes: +cat

← Older revision		Revision as of 23:40, 14 April 2026
Line 60:		Line 60:

	[[Category: System Administration‏‎]]		[[Category: System Administration‏‎]]
			[[Category: Hardware Repair]]

PoC: /* See also */ +link, rearranged order

2025-11-30T17:41:19Z

PoC: /* Conclusion */ not so sure

2025-09-30T20:02:28Z

Conclusion: not so sure

← Older revision		Revision as of 22:02, 30 September 2025
Line 43:		Line 43:
	The shown condition can be corrected by an ordinary reinstall of SLIC and the OS, wiping the existing disk. '''Note:''' This does '''not''' affect MULIC/FULIC, which is preserved. But that needs proper install media.		The shown condition can be corrected by an ordinary reinstall of SLIC and the OS, wiping the existing disk. '''Note:''' This does '''not''' affect MULIC/FULIC, which is preserved. But that needs proper install media.

	While the procedure shown is not advisable to be used as a single backup scenario, it is definitely a viable way to preserve MULIC/FULIC data from (partly defective) disks. MULIC/FULIC is machine specific code for CISC models, and ~~apparently~~ contains the system serial number. If the system serial number changes (because it is IPLed with MULIC from a different machines' MULIC tape), a [[system password invalidation]] happens. Recovering from that condition involves contacting IBM.		While the procedure shown is not advisable to be used as a single backup scenario, it is definitely a viable way to preserve MULIC/FULIC data from (partly defective) disks. MULIC/FULIC is machine specific code for CISC models, and presumedly contains the system serial number. If the system serial number changes (because it is IPLed with MULIC from a different machines' MULIC tape), a [[system password invalidation]] happens. Recovering from that condition involves contacting IBM.

	== See also ==		== See also ==

PoC: /* Reformat */ optional

2024-02-12T18:10:36Z

Reformat: optional

← Older revision		Revision as of 20:10, 12 February 2024
Line 25:		Line 25:
	You can reformat drives to matching block size like this:		You can reformat drives to matching block size like this:
	sg_format -v -v -6 --format --size=520 /dev/sg0		sg_format -v -v -6 --format --size=520 /dev/sg0

			This is a purely optional step and shown for completeness only.

	== Restore ==		== Restore ==

PoC: Parameter -p isn't known for Debian dd.

2023-12-10T20:19:17Z

Parameter -p isn't known for Debian dd.

← Older revision		Revision as of 22:19, 10 December 2023
Line 14:		Line 14:
	* use <code>lsscsi -g</code> to identify the disk(s) on the bus, and also list their SCSI Generic device node,		* use <code>lsscsi -g</code> to identify the disk(s) on the bus, and also list their SCSI Generic device node,
	* Duplicate the Disks's content with sg_dd (example):		* Duplicate the Disks's content with sg_dd (example):
	sg_dd blk_sgio=1 if=/dev/sg0 bs=520 of=outfile_520.dd verbose=2 sync=1 -p		sg_dd blk_sgio=1 if=/dev/sg0 bs=520 of=outfile_520.dd verbose=2 sync=1

	If is very important to know that (with some exceptions)		If is very important to know that (with some exceptions)
Line 30:		Line 30:

	Then you can write back the image to a given disk:		Then you can write back the image to a given disk:
	sg_dd blk_sgio=1 bs=520 of=/dev/sg1 if=outfile_520.dd verbose=2 sync=1 -p		sg_dd blk_sgio=1 bs=520 of=/dev/sg1 if=outfile_520.dd verbose=2 sync=1

	== Conclusion ==		== Conclusion ==

PoC: New findings by Friedkiwi

2023-06-30T15:06:25Z

New findings by Friedkiwi

← Older revision		Revision as of 17:06, 30 June 2023
Line 1:		Line 1:
	~~{{FIXME\|How to restore}}~~
	[[File:Disk SCSI Copy.jpg\|thumb\|right\|PXE booted PC as SCSI Attachment Station]]		[[File:Disk SCSI Copy.jpg\|thumb\|right\|PXE booted PC as SCSI Attachment Station]]
	Since (mainly) older machines are very picky about Tape Drives, and existing tape drives either become defective, or working tape cartridges become more and more scarce, an alternative to regular full backups on tape is needed. Offline backups become more and more a viable alternative, despite the higher effort of (temporarily) extracting the disk(s) to hook them up to a SCSI equipped Linux PC.		Since (mainly) older machines are very picky about Tape Drives, and existing tape drives either become defective, or working tape cartridges become more and more scarce, an alternative to regular full backups on tape is needed. Offline backups become more and more a viable alternative, despite the higher effort of (temporarily) extracting the disk(s) to hook them up to a SCSI equipped Linux PC.
Line 32:		Line 31:
	Then you can write back the image to a given disk:		Then you can write back the image to a given disk:
	sg_dd blk_sgio=1 bs=520 of=/dev/sg1 if=outfile_520.dd verbose=2 sync=1 -p		sg_dd blk_sgio=1 bs=520 of=/dev/sg1 if=outfile_520.dd verbose=2 sync=1 -p

			== Conclusion ==
			A test run copying a smaller disk to a larger for a CISC system, and test-IPLing this yielded an eventual halt of the system after a main storage dump. By using the displayed SRC on the panel as a crude IPL progress meter, the machine finished reassembling the LID (parts of the "kernel") into RAM and crashed right after enabling full paging. At this time in the IPL sequence that probably means it couldn't find the boot device for further tasks. But it did manage to load SLIC into RAM. And for CISC machines, it also managed to load MULIC/FULIC.

			Unresolved questions:
			* is the crash related to the size difference or due to the fact that this is an entirely different disk?<ref>DST in OS/400 has a facility to dump a disk contents to another, but it's unknown if it does any "magic" while doing so.</ref>
			* is a similar behavior happening when doing this for PPC systems?

			The shown condition can be corrected by an ordinary reinstall of SLIC and the OS, wiping the existing disk. '''Note:''' This does '''not''' affect MULIC/FULIC, which is preserved. But that needs proper install media.

			While the procedure shown is not advisable to be used as a single backup scenario, it is definitely a viable way to preserve MULIC/FULIC data from (partly defective) disks. MULIC/FULIC is machine specific code for CISC models, and apparently contains the system serial number. If the system serial number changes (because it is IPLed with MULIC from a different machines' MULIC tape), a [[system password invalidation]] happens. Recovering from that condition involves contacting IBM.

	== See also ==		== See also ==
	* [[Tape Drives on old AS/400]]		* [[Tape Drives on old AS/400]]
	* [[Ordinary Harddisks on the AS/400]]		* [[Ordinary Harddisks on the AS/400]]
			* [[CISC AS/400 LIC Tapes]]

	== Weblinks ==		== Weblinks ==
Line 41:		Line 52:
	* [https://en.wikipedia.org/wiki/SCSI SCSI], Wikipedia		* [https://en.wikipedia.org/wiki/SCSI SCSI], Wikipedia
	* [https://archive.midrange.com/midrange-l/202003/msg00234.html Linux dealing with IBM i blocksizes], Midrange-Mailing List		* [https://archive.midrange.com/midrange-l/202003/msg00234.html Linux dealing with IBM i blocksizes], Midrange-Mailing List

			== Footnotes ==
			<references />

	[[Category: System Administration‏‎]]		[[Category: System Administration‏‎]]

PoC: Updated with information from Friedkiwi

2023-06-30T10:04:48Z

Updated with information from Friedkiwi

← Older revision		Revision as of 12:04, 30 June 2023
Line 15:		Line 15:
	* use <code>lsscsi -g</code> to identify the disk(s) on the bus, and also list their SCSI Generic device node,		* use <code>lsscsi -g</code> to identify the disk(s) on the bus, and also list their SCSI Generic device node,
	* Duplicate the Disks's content with sg_dd (example):		* Duplicate the Disks's content with sg_dd (example):
	sg_dd if=/dev/sg0 bs=~~522~~ of=~~outfile_522~~.dd		sg_dd blk_sgio=1 if=/dev/sg0 bs=520 of=outfile_520.dd verbose=2 sync=1 -p

	If is very important to know that (with some exceptions)		If is very important to know that (with some exceptions)
Line 22:		Line 22:

	If in doubt, use <code>dmesg</code> to scroll through the kernel message buffer and locate the position where the SCSI disk(s) is/are identified with their block size. It is important to use the correct blocksize in the <code>bs=</code> parameter.		If in doubt, use <code>dmesg</code> to scroll through the kernel message buffer and locate the position where the SCSI disk(s) is/are identified with their block size. It is important to use the correct blocksize in the <code>bs=</code> parameter.

			== Reformat ==
			You can reformat drives to matching block size like this:
			sg_format -v -v -6 --format --size=520 /dev/sg0

	== Restore ==		== Restore ==
	First, make sure the new target disk has been formatted to the correct block size. ~~The best~~ way to do this is to IPL the target system via CD or tape, and use the DST provided utilities to do the formatting.		First, make sure the new target disk has been formatted to the correct block size. A proven way to do this is to IPL the target system via CD or tape, and use the DST provided utilities to do the formatting.

	~~In theory, the <code>dd</code> statement from the backup just needs to be reversed to copy back the image file to the disk.~~
	~~sg_dd if=outfile_522.dd bs=522 of=/dev/sg0~~

	~~In practice, the copy command exits quickly with~~
	~~31+1 records in~~
	~~32+0 records out~~

	~~Further investigation is necessary~~ to ~~provide~~ a ~~reliable way to copyback~~.		Then you can write back the image to a given disk:
			sg_dd blk_sgio=1 bs=520 of=/dev/sg1 if=outfile_520.dd verbose=2 sync=1 -p

	== See also ==		== See also ==

PoC: /* Weblinks */ +Link

2022-01-27T10:43:52Z

Weblinks: +Link

← Older revision		Revision as of 12:43, 27 January 2022
Line 42:		Line 42:
	* [https://sg.danny.cz/sg/sg3_utils.html The sg3_utils package]		* [https://sg.danny.cz/sg/sg3_utils.html The sg3_utils package]
	* [https://en.wikipedia.org/wiki/SCSI SCSI], Wikipedia		* [https://en.wikipedia.org/wiki/SCSI SCSI], Wikipedia
			* [https://archive.midrange.com/midrange-l/202003/msg00234.html Linux dealing with IBM i blocksizes], Midrange-Mailing List

	[[Category: System Administration‏‎]]		[[Category: System Administration‏‎]]

PoC: Restore

2022-01-27T10:40:12Z

Restore

← Older revision		Revision as of 12:40, 27 January 2022
Line 22:		Line 22:

	If in doubt, use <code>dmesg</code> to scroll through the kernel message buffer and locate the position where the SCSI disk(s) is/are identified with their block size. It is important to use the correct blocksize in the <code>bs=</code> parameter.		If in doubt, use <code>dmesg</code> to scroll through the kernel message buffer and locate the position where the SCSI disk(s) is/are identified with their block size. It is important to use the correct blocksize in the <code>bs=</code> parameter.

			== Restore ==
			First, make sure the new target disk has been formatted to the correct block size. The best way to do this is to IPL the target system via CD or tape, and use the DST provided utilities to do the formatting.

			In theory, the <code>dd</code> statement from the backup just needs to be reversed to copy back the image file to the disk.
			sg_dd if=outfile_522.dd bs=522 of=/dev/sg0

			In practice, the copy command exits quickly with
			31+1 records in
			32+0 records out

			Further investigation is necessary to provide a reliable way to copyback.

	== See also ==		== See also ==

PoC: New

2022-01-27T10:33:19Z

New

New page

{{FIXME|How to restore}}
[[File:Disk SCSI Copy.jpg|thumb|right|PXE booted PC as SCSI Attachment Station]]
Since (mainly) older machines are very picky about Tape Drives, and existing tape drives either become defective, or working tape cartridges become more and more scarce, an alternative to regular full backups on tape is needed. Offline backups become more and more a viable alternative, despite the higher effort of (temporarily) extracting the disk(s) to hook them up to a SCSI equipped Linux PC.

IBM "blessed" AS/400 disks are different in some ways, which makes it difficult do cope with them on Linux. Fortunately, most problems can be avoided by using the SCSI Generic facilities to talk to the device(s) in question. For this, it's mandatory to have the sg3 utils package installed. In addition, the ''lsscsi'' package is also mandatory for checking devices on the bus from within Linux.

This article assumes basic knowledge about SCSI:
* How to avoid duplicate device IDs,
* proper bus (cable ends) termination.

Please see the articles in the ''See also'' section for further details.

== Backup ==
* Attach the disk and boot the PC,
* use <code>lsscsi -g</code> to identify the disk(s) on the bus, and also list their SCSI Generic device node,
* Duplicate the Disks's content with sg_dd (example):
sg_dd if=/dev/sg0 bs=522 of=outfile_522.dd

If is very important to know that (with some exceptions)
* PowerPC based AS/400's use 522 Bytes per sector, and
* CISC architecture AS/400's use 520 Bytes per sector.

If in doubt, use <code>dmesg</code> to scroll through the kernel message buffer and locate the position where the SCSI disk(s) is/are identified with their block size. It is important to use the correct blocksize in the <code>bs=</code> parameter.

== See also ==
* [[Tape Drives on old AS/400]]
* [[Ordinary Harddisks on the AS/400]]

== Weblinks ==
* [https://sg.danny.cz/sg/sg3_utils.html The sg3_utils package]
* [https://en.wikipedia.org/wiki/SCSI SCSI], Wikipedia

[[Category: System Administration‏‎]]

← Older revision		Revision as of 19:41, 30 November 2025
Line 46:		Line 46:

	== See also ==		== See also ==
			* [[Ordinary Harddisks on the AS/400]]
			* [[Disk device related system reference codes]]
	* [[Tape Drives on old AS/400]]		* [[Tape Drives on old AS/400]]
	* [[Ordinary Harddisks on the AS/400]]
	* [[CISC AS/400 LIC Tapes]]		* [[CISC AS/400 LIC Tapes]]