[QUOTE=petrw1;497915]AWOL?[/QUOTE]
10-12-18, 11:40 AM UTC:
[url]https://downforeveryoneorjustme.com/gpu72.com[/url]
[QUOTE]It's not just you! [URL="https://gpu72.com"]gpu72.com[/URL] looks down from here. [/QUOTE]

It's back up
 

[QUOTE=kladner;497923]10-12-18, 11:40 AM UTC:
[url]https://downforeveryoneorjustme.com/gpu72.com[/url][/QUOTE]

It;s Back Up at 1PM Eastern.

[QUOTE=tServo;497948]It;s Back Up at 1PM Eastern.[/QUOTE]

Sorry guys. A *really* bad kernel upgrade / reboot...

"symbol not found: grub_efi_secure_boot" for every kernel available from the GRUB boot menu. Smashed my head against the wall for hours on this (in addition to having to take one of our cats to the vet because of injuries resulting from a fight last night).

In case anyone else encounters this, the solution is to move /boot/grub to /boot/grub_bu and /boot/grub2 to /boot/grub2_bu, then "yum reinstall grub*", then "grub2-install /dev/sda", "grub2-install /dev/sdb" (in a RAID1 configuration), then "grub2-mkconfig -o /boot/grub2/grub.cfg", then "grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg".

I hate computers....

Edit: Just to document the exact proceedure, in case I have to do this again myself, the above commands are done in a "rescue" environment (via the "serial console" in the case of a co-located server) with the file systems mounted and then chroot'ed into.[CODE]
cd /mnt
mkdir t
mount /dev/md1 t
mount /dev/vg00/usr t/usr
mount /dev/vg00/var t/var
mount -t proc proc t/proc
mount -t sysfs sys t/sys
mount -o bind /dev t/dev
chroot t

# Do the GRUB stuff...

exit

umount t/sys
umount t/proc
umount t/dev
umount t/usr
umount t/var
umount t

shutdown -r now
[/CODE]

The exact file system locations will likely vary for other installations. "cat /proc/mdstat" and "lvdisplay" should give enough information to proceed.

Do we know anything about this anonymous participant?
 

Do we know anything about the anonymous participant who has 6,500 current TF assignments and has been turning in 30,000+ GhzDays/Day for the past several days? Currently at position #2 in the overall progress report.

[QUOTE=Chuck;504307]Do we know anything about the anonymous participant who has 6,500 current TF assignments and has been turning in 30,000+ GhzDays/Day for the past several days?[/QUOTE]

Only that they have some /serious/ kit!!! :wink:

They have chosen to be anonymous, so that's all I'll say on the matter (as a sysadmin I take confidentiality *very* seriously)....

LLTF work to 72 is running out...
 

Hey All.

We're about two weeks away from taking everything below 97M to at least 72 "bits".

There are around 10,000 candidates in 97M still at 71, but there are [URL="https://www.mersenne.ca/status/tf/0/7/3/9000"]several people working that range[/URL] "off the books" (read: not reserving from Primenet), so I'm hesitant to bring those candidates into GPU72 and risk "toes being stepped on".

I'm also a little hesitant to bring in work in the 10xM ranges, since that is *so* far ahead of the Primenet LL'ing and P-1'ing wave-fronts. GPU72 was created to help the GIM[U][B][I]P[/I][/B][/U]S project, and I'd like to keep to that primary agenda.

So, once everything "owned" by GPU72 at 71 is assigned, the system will start giving out work to 73 bits (starting in 92M), even if the pledge is only to 72.

Thoughts? Comments? Complaints?

And, as always, thanks for all the compute everyone!!! :tu:

Does GPU72 have a lot of users that only work up to 72 bits?

My only complaint is that I wish people didn't work "off the books" so close to the LL and P-1 wavefronts. The reason we have a reservation system is to prevent duplication of effort.

[QUOTE=masser;504381]Does GPU72 have a lot of users that only work up to 72 bits?[/QUOTE]

Yes, [URL="https://www.gpu72.com/reports/workers/lltf/week/"]a few[/URL]. Some with some fairly serious fire-power. And that's cool; everything is useful (even if not immediately).

[QUOTE=masser;504381]My only complaint is that I wish people didn't work "off the books" so close to the LL and P-1 wavefronts. The reason we have a reservation system is to prevent duplication of effort.[/QUOTE]

Seconded.

[QUOTE=chalsall;504383]And that's cool; everything is useful (even if not immediately)[/QUOTE]That makes me feel better about spending 6 months factoring to 10000M :smile:

[QUOTE=James Heinrich;504385]That makes me feel better about spending 6 months factoring to 10000M :smile:[/QUOTE]

That makes me feel useful as well :smile:

[QUOTE=chalsall;504383]Yes, [URL="https://www.gpu72.com/reports/workers/lltf/week/"]a few[/URL]. Some with some fairly serious fire-power. And that's cool; everything is useful (even if not immediately).
[/QUOTE]

Ok, I see now.

FWIW, I think you made the right choice. In the not-too-distant future, there won't be any useful TF work left at the 72 bit level, so better for contributors to get used to doing higher bit levels now. I would think it's less annoying to work to higher bit levels than to get poached by the yahoos that don't make reservations. Moving to 10xM ranges is less helpful to GIMPS.

I also notice that at the 96.8M range, GPU72 will have more work to do; TF to 77 bits will soon be the new norm.