3 Apr
2019
3 Apr
'19
10:21 p.m.
On Wednesday 03 April 2019 12:38:12 Felix Miata wrote:
Gene Heskett composed on 2019-04-03 08:16 (UTC-0400):
...
...
yes, sdc is a 2T for amanda's vtapes, and sda and sdb will be swapped so
I'll be booting from the first hard drive again. This is a 10 second
operation as I have an old tiger direct 3 drive hot swap drive cage,
although in deference to the drives I move them only when its powered
down.
And I've discovered that I can set "removeable" in the boot priority
screen of the bios, so maybe it might boot from usb stick after all, but
I don't have any of a suitable size for a dvd sub, netinstall maybe.
Humm, just found a 16GB I don't think theres anything precious on.. But
all I have is the jigdo stuffs. So it will take a while to grab dvd-1.
And the jigdo file is no good, its asking for a site that apparently no
longer has a valid repo. Debian mirror
[http://carroll.aset.psu.edu/pub/linux/distributions/debian/] resolves,
but there is nothing there for jigdo.
I'm about burned out on this PITA. It seems to me that this problem
could be fixed once and for all by simply installing grub while the
partition was only at the minimal install stage, I think by waiting till
the end of the install, grub is too far into the disk for a dumb
messydos bios to find. Thats my theory at least. jigdo seems to be
working but the mirror is stuck in molasses. This may take a day or
more. And something has leaked, cups is AFU since the last failed
install. Ah, usb cable didn't get plugged in again. My usb tree here
if mapped, would resemble a fairly mature weeping willow. And this
machine was down for a fresh psu last week.
parted
-l
gene@coyote:~/Mail/emc$ parted -l
Model: ATA ST1000VX000-1CU1 (scsi) Model: ATA ST2000DM006-2DM1 (scsi)
Disk /dev/sdb: 2000GB
...
Model: ATA ST31000333AS (scsi)
Disk /dev/sdc: 1000GB
Model: ATA ST2000DM001-1ER1 (scsi)
Disk /dev/sdd: 2000GB
...
fdisk -l
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
...
Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
...
Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes
...
/dev/sdb is the target disk, /dev/sda is current
operating disk
/dev/sdc is older, not in use amandatapes-1T disk,
and /dev/sdd is currently used amandatapes-2T disk.
Look this over please.
I see nothing in the partitioning itself that should prevent success.
500G+ for the / filesystem does seem to be at least somewhere around
200%-300% overkill. 20G-30G may well be too little for your needs, but
surely 100G ought to cover it. If you're using big databases, they
probably should be configured to store their data on a data partition
rather than the / filesystem. I don't have any / filesystems as big as
20G (unless counting Mac or Windows, which are nevertheless under 3
digit G in size).
If the BIOS is old enough, more than around 504G for the / filesystem
containing the bootloader could be another obstacle. A 200M to 500M
primary partition at the start of disk just for /boot would avoid this
mere potential, as should a slightly smaller / partition. My boot
partitions are all EXT2. Writing to /boot is rather rare, making
journaling on them arguably unnecessary overhead.
If that's Wheezy on sda, I suggest to consider to use it to format the
partitions on sdb prior to installation, and ignore any objections you
get from the Debian installer that it is not to be doing any
formatting. Post-Wheezy at least one formerly optional/experimental
formatting feature for EXT4 became default, 64bit. It's not a needed
feature on smaller filesystems, as fit on a disk 2TB or smaller.
Having Wheezy do the formatting will allow working with the new
partitions post-installation. Alternatively, disabling 64bit (-O
'^64bit') when formatting with newer mke2fs versions would have the
same effect.
Questions remain as to bootloader configuration. Are sda and sdc to
remain installed once successful installation is confirmed and data
migration complete? If ultimately sda and sdc are to be retired, I
suggest to disconnect them prior to installation, and reconnect for
migration purposes only after installation success is confirmed. I
might go further and temporarily disconnect sdd as well.
sdd is an older 1T seacrate and was used for amanda for around 85,000
hours, but has been in a hard mount slot since it was replaced with the
2T. I keep it spining so stiction doesn't lock it up. smartctl says its
as good as new yet, except for the head flying hours.
Is this a mix of SATA and PATA, all SATA,
The latter. Even the floppy cable has been removed as the floppy is only
used for sneaker net, and since this chipset dies, locking up the whole
machine if a 256 byte/sector disk is inserted, its about as un-useful as
can be here.
or all PATA? A different set
of kernel and disk drivers could potentially reorder device
assignments, making the order bootloader sees and the system sees
differ. Booting using UUIDs or LABELs instead of device names is
supposed to render any such differences of no import, but potential
for confusion does remain, particularly from the perspective of an
administrator's eyes.
Well, since I'm the one applying the disks partition labels, I trust them
a lot farther than UUID's. I have had the simple replacemewnt of a
failing disk change every UUID in the system, more than once.
Since stretch seems to have been OEL'd at most mirrors I guess I'll wait
for Buster now.
Time to go change hats and play Chef.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>