Hi Dan! Thank you for the nice script.
I have one question about the execution of the last part, where the image is supposed to be written…
When started the script for a very first time it was asking for CURL. However, with CURL in place it started to work pretty smooth up to the writing point:
root@Microknoppix:/media/sda3/WD MyBook# ./debricker.sh /dev/sdb ********************** DISK ********************** script will use the following disk: Model: ATA WDC WD20EARS-00M (scsi) Disk /dev/sdb: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Number Start End Size File system Name Flags 3 15.7MB 528MB 513MB primary 1 528MB 2576MB 2048MB ext3 primary raid 2 2576MB 4624MB 2048MB primary raid 4 4624MB 2000GB 1996GB ext4 primary is this REALLY the disk you want? [y] y ********************** IMAGE ********************** checking: 010507 searching: ./*/*01*05*07*.img searching: ./*/*01*05*07*.deb downloading: ./firmware/rootfs_010507.deb confirm [y]: y % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 154M 100 154M 0 0 1805k 0 0:01:27 0:01:27 --:--:-- 1881k will extract: ./firmware/rootfs_010507.deb confirm [y]: y extracting: ./firmware/rootfs_010507.img ********************** IMPLEMENTATION ********************** everything is now prepared! device: /dev/sdb image_img: ./firmware/rootfs_010507.img destroy: false this is the point of no return, continue? [y] y mdadm: /dev/sdb1 appears to contain an ext2fs file system size=1999808K mtime=Sun Apr 3 07:43:04 2016 mdadm: size set to 1999808K mdadm: creation continuing despite oddities due to --run mdadm: array /dev/md0 started. mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 125184 inodes, 499952 blocks 24997 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=515899392 16 block groups 32768 blocks per group, 32768 fragments per group 7824 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Checking for bad blocks (read-only test): 42.72% done, 5:24:00 elapsed. (4500/0/0 errors) At this point it started to work extremely slow and I verified the processes:
root@Microknoppix:/home/knoppix# pstree -al 3584 sudo -s └─bash └─debricker.sh ./debricker.sh /dev/sdb └─mkfs.ext3 -c -b 4096 /dev/md0 └─badblocks -b 4096 -X -s /dev/md0 499951 root@Microknoppix:/home/knoppix# Do you think that such a slow execution, with so many errors, can finally produce a successful debrick ?
Greets!