I presume you have had to run on RAM, considering you removed all drives
Yes. Mass deployment using Clonezilla in an extremely heterogenous environment. I had to make sure the OS got installed on the correct SSD, and that it was always named sda, otherwise Clonezilla would shit itself. The solution is a hack held together by spit and my own stubbornness, but it works.
Mass deployment using a solution that is making you have to remove all other storage devices.
That sounds very frustrating and I wouldn’t want to do that.
On the other hand, you’re probably an expert on disconnecting and reconnecting SCSI cables by now.
There was no need to physically disconnect anything. We didn’t actually use any SCSI devices, but Linux (and in turn, the Debian-based Clonezilla) uses the SCSI kernel driver for all ATA devices, so SATA SSDs also appeared as SCSI hosts and could be handled as such. If I had to manually unplug and reconnect hundreds of physical cables, I’d send my resignation directly to my boss’ printer.
The local machine boots using PXE. Clonezilla itself is transferred from a TFTP server as a squashfs and loaded into memory. When that OS boots, it mounts a network share using CIFS that contains the image to be installed. All of the local SATA disks are named sda, sdb, etc. A script determines which SATA disk is the correct one (must be non-rotational, must be a specific size and type), deletes every SCSI device (which includes ATA devices too), then mounts only the chosen disk to make sure it’s named sda.
Clonezilla will not allow an image cloned from a device named sda to be written to a device with a different name – this is why I had to make sure that sda is always the correct SSD.
Yes. Mass deployment using Clonezilla in an extremely heterogenous environment. I had to make sure the OS got installed on the correct SSD, and that it was always named
sda, otherwise Clonezilla would shit itself. The solution is a hack held together by spit and my own stubbornness, but it works.Mass deployment using a solution that is making you have to remove all other storage devices.
That sounds very frustrating and I wouldn’t want to do that.
On the other hand, you’re probably an expert on disconnecting and reconnecting SCSI cables by now.
There was no need to physically disconnect anything. We didn’t actually use any SCSI devices, but Linux (and in turn, the Debian-based Clonezilla) uses the SCSI kernel driver for all ATA devices, so SATA SSDs also appeared as SCSI hosts and could be handled as such. If I had to manually unplug and reconnect hundreds of physical cables, I’d send my resignation directly to my boss’ printer.
So you somehow connected a networked drive as sda - is what I understand from that.
That would be interesting
No.
The local machine boots using PXE. Clonezilla itself is transferred from a TFTP server as a squashfs and loaded into memory. When that OS boots, it mounts a network share using CIFS that contains the image to be installed. All of the local SATA disks are named
sda,sdb, etc. A script determines which SATA disk is the correct one (must be non-rotational, must be a specific size and type), deletes every SCSI device (which includes ATA devices too), then mounts only the chosen disk to make sure it’s namedsda.Clonezilla will not allow an image cloned from a device named
sdato be written to a device with a different name – this is why I had to make sure thatsdais always the correct SSD.OIC, so the physically connected storage devices are disconnected in the software and then the correct, required one is re-connected.
The part of what Clonezilla is doing seems like a mis-feature, added to prevent some kind of PICNIC.