My main computer is in the shop (it won't pass a POST) and it looks like the motherboard may be the culprit. The last computers I had built were put together very well but the places where they were done no longer exist. Suggestions/recommendations for places that build computers to custom specs with high build quality? And, for that matter, what a future-proof solid set of specs looks like these days? (This is to replace a 12-core i7 box with 32GB RAM and some 10TB of storage.) Thanks! -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
"replace a 12-core i7 box with 32GB RAM and some 10TB of storage" Replace this? Future proof this? Your spec is pretty damn great already. You doing video editing or calcs for a satellite orbiting the earth? On Wed, 15 Jul 2020 at 13:02, Peter King via talk <talk@gtalug.org> wrote:
My main computer is in the shop (it won't pass a POST) and it looks like the motherboard may be the culprit. The last computers I had built were put together very well but the places where they were done no longer exist.
Suggestions/recommendations for places that build computers to custom specs with high build quality? And, for that matter, what a future-proof solid set of specs looks like these days? (This is to replace a 12-core i7 box with 32GB RAM and some 10TB of storage.) Thanks!
-- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA
http://individual.utoronto.ca/pking/
========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42 --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On 7/15/20 1:02 PM, Peter King via talk wrote:
My main computer is in the shop (it won't pass a POST) and it looks like the motherboard may be the culprit. The last computers I had built were put together very well but the places where they were done no longer exist.
If it's just the mom board, why not replace it, assuming the rest of the computer isn't too ancient. I bet the same shop where it's in for repair could do it. My computer is in the same case I bought about 15 years ago and has seen 3 - 4 motherboards. The only issue is that my DVD drives are still IDE, while the motherboard is SATA, so I had to buy an IDE interface for it.
On Wed, Jul 15, 2020 at 01:26:55PM -0400, James Knott via talk wrote:
If it's just the mom board, why not replace it, assuming the rest of the computer isn't too ancient. I bet the same shop where it's in for repair could do it.
My computer is in the same case I bought about 15 years ago and has seen 3 - 4 motherboards. The only issue is that my DVD drives are still IDE, while the motherboard is SATA, so I had to buy an IDE interface for it.
I haven't had any luck in finding motherboards that would take the old CPU, RAM, and so on, but your story is inspirational. The case is a CoolerMaster with lots of space in it, and it would be nice to be able to keep it. -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
On 7/15/20 2:01 PM, Peter King via talk wrote:
I haven't had any luck in finding motherboards that would take the old CPU, RAM, and so on, but your story is inspirational. The case is a CoolerMaster with lots of space in it, and it would be nice to be able to keep it.
You'd buy new CPU and RAM with the new MB. That's one area where things have changed.
| From: Peter King via talk <talk@gtalug.org> | I haven't had any luck in finding motherboards that would take the old CPU, | RAM, and so on, but your story is inspirational. The case is a CoolerMaster | with lots of space in it, and it would be nice to be able to keep it. What is your old motherboard? CPU? RAM? The oldest i7 with 6 cores seems to be of the Haswell-E generation (eg. Core i7-5820k). The 6-core I7's seem to use sockets with more pins than the common garden variety I7s. This makes for more expensive motherboards and they probably support more memory. Even the oldest 6-core i7s seem to use DDR4. Newer CPUs still use DDR4. So you might be able to reuse your RAM. It might be slower than what you'd want on a new build. The first 6-core 12-thread i7 seems to be Skylake-x. Like a Core i7-7800x. Suitable LGA 2066 motherboards are available and expensive. <https://www.newegg.ca/p/pl?N=100007626%20601299335> I'd love to play with what you discard! It would be newer and more powerful than any of my desktops. If you want a similarly high-end box but for modern times, you can go crazy with a current ThreadRipper or Epyc AMD processor. But you can get quite a lot of power for less, as Lennart has outlined.
On Wed, Jul 15, 2020 at 04:55:13PM -0400, D. Hugh Redelmeier via talk wrote:
What is your old motherboard? CPU? RAM?
The oldest i7 with 6 cores seems to be of the Haswell-E generation (eg. Core i7-5820k).
i7-3960X has 6 cores and 12 threads. I am running one. I also have my father's unstable (seems to hang detecting disks on most boot attempts for some reason) i7-3920 (4 core 8 thread) with the Asus Sabertooth X79 motherboard and 32GB ram. If it boots, it runs fine. If it hangs detecting disks the screen has no output since video is initialized after disks (there are a lot of diagnostic LEDs on these boards).
The 6-core I7's seem to use sockets with more pins than the common garden variety I7s. This makes for more expensive motherboards and they probably support more memory.
Oh yes. They certainly do all of that. Supports at least 128GB in my case.
Even the oldest 6-core i7s seem to use DDR4. Newer CPUs still use DDR4. So you might be able to reuse your RAM. It might be slower than what you'd want on a new build.
Mine is DDR3.
The first 6-core 12-thread i7 seems to be Skylake-x. Like a Core i7-7800x. Suitable LGA 2066 motherboards are available and expensive. <https://www.newegg.ca/p/pl?N=100007626%20601299335>
Socket 2011 was the first. Sandy Bridge-E.
I'd love to play with what you discard! It would be newer and more powerful than any of my desktops.
If you want a similarly high-end box but for modern times, you can go crazy with a current ThreadRipper or Epyc AMD processor. But you can get quite a lot of power for less, as Lennart has outlined.
Given you can get ryzen 9 for AM4 socket with 12 cores/24 threads for $649 for the CPU and about $300 or $400 for a good board, that's quite a bit cheaper than getting into threadripper. Unless you need a LOT of memory, it would probably be sufficient. -- Len Sorensen
On 7/15/20 5:27 PM, Lennart Sorensen via talk wrote:
On Wed, Jul 15, 2020 at 04:55:13PM -0400, D. Hugh Redelmeier via talk wrote:
What is your old motherboard? CPU? RAM?
The oldest i7 with 6 cores seems to be of the Haswell-E generation (eg. Core i7-5820k).
i7-3960X has 6 cores and 12 threads. I am running one.
I also have my father's unstable (seems to hang detecting disks on most boot attempts for some reason) i7-3920 (4 core 8 thread) with the Asus Sabertooth X79 motherboard and 32GB ram. If it boots, it runs fine. If it hangs detecting disks the screen has no output since video is initialized after disks (there are a lot of diagnostic LEDs on these boards).
The 6-core I7's seem to use sockets with more pins than the common garden variety I7s. This makes for more expensive motherboards and they probably support more memory.
Oh yes. They certainly do all of that. Supports at least 128GB in my case.
Even the oldest 6-core i7s seem to use DDR4. Newer CPUs still use DDR4. So you might be able to reuse your RAM. It might be slower than what you'd want on a new build.
Mine is DDR3.
The first 6-core 12-thread i7 seems to be Skylake-x. Like a Core i7-7800x. Suitable LGA 2066 motherboards are available and expensive. <https://www.newegg.ca/p/pl?N=100007626%20601299335>
Socket 2011 was the first. Sandy Bridge-E.
I'd love to play with what you discard! It would be newer and more powerful than any of my desktops.
If you want a similarly high-end box but for modern times, you can go crazy with a current ThreadRipper or Epyc AMD processor. But you can get quite a lot of power for less, as Lennart has outlined.
Given you can get ryzen 9 for AM4 socket with 12 cores/24 threads for $649 for the CPU and about $300 or $400 for a good board, that's quite a bit cheaper than getting into threadripper. Unless you need a LOT of memory, it would probably be sufficient.
For memory its a max of 256GB which isn't a lot if your considering running a workload that is using that many cores, the data sets are probably large. The other reason would be PCI-E lanes of 64 versus whatever ryzen9 has. Through for most people those things don't matter and 12 cores/24 threads is a lot even for large workloads. Through since you mentioned video editing or Peter did it may be good to figure out if single core speed is more important as some video encoders are more about clock speed or GPU speed than cores. Cheers, Nick -- Fundamentally an organism has conscious mental states if and only if there is something that it is like to be that organism--something it is like for the organism. - Thomas Nagel
| From: Lennart Sorensen via talk <talk@gtalug.org> | i7-3960X has 6 cores and 12 threads. I am running one. Oops, I missed that. Thanks for catching it. So I'm back to wondering what the actual chip and motherboard are. | > Even the oldest 6-core i7s seem to use DDR4. Newer CPUs still use | > DDR4. So you might be able to reuse your RAM. It might be slower | > than what you'd want on a new build. | | Mine is DDR3. If the old RAM is DDR3, it is going to be hard to use it in a new system. But it still might be useful to others. For example, most of my desktop systems use DDR3.
On Wed, Jul 15, 2020 at 05:27:19PM -0400, Lennart Sorensen via talk wrote:
What is your old motherboard? CPU? RAM?
Old motherboard: Asus Sabertooth X79 Old CPU: Intel i7 3970 (Sandybridge-E), six cores / twelve threads Old RAM: Corsair DDR3 4x8G = 32G total This is almost the same as Lennart's father's machine:
I also have my father's unstable (seems to hang detecting disks on most boot attempts for some reason) i7-3920 (4 core 8 thread) with the Asus Sabertooth X79 motherboard and 32GB ram. If it boots, it runs fine.
Interesting -- that's pretty much exactly the symptoms I had: if it actually made it past the POST, it booted and ran with no problems, but it only did that about one in twelve attempts.
I'd love to play with what you discard! It would be newer and more powerful than any of my desktops.
I expect to have some high-end components that I can't use in the near future... At the moment I'm looking at the AMD Ryzen 3800X 3.9GHz eight-core / sixteen-thread CPU, the Asus Prime X570-Pro AM4 ATX motherboard, and the Corsair LPX Vengeance 4x16G = 64G total. With any luck I can just migrate my audio card (Asus Xonar STX Essence), bluray drive, power supply, and perhaps even my CoolerMaster case. I haven't decided whether to use the old video card or try for one that will drive UHD 4K resolution -- the latter requiring a new monitor, too. Might be better just to start with the new equipment and see how easy or hard it is to get Arch up and running, then decide about the video. -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
On Thu, Jul 16, 2020 at 12:42:26PM -0400, Peter King via talk wrote:
Interesting -- that's pretty much exactly the symptoms I had: if it actually made it past the POST, it booted and ran with no problems, but it only did that about one in twelve attempts.
Makes me wonder if the south bridge or some of the circuitry connected to it is going bad. I should probably put the 32GB into the 4 empty sockets on my machine (same motherboard, just the 3960X instead of 3920). Then I would have 64GB.
I expect to have some high-end components that I can't use in the near future...
At the moment I'm looking at the AMD Ryzen 3800X 3.9GHz eight-core / sixteen-thread CPU, the Asus Prime X570-Pro AM4 ATX motherboard, and the Corsair LPX Vengeance 4x16G = 64G total. With any luck I can just migrate my audio card (Asus Xonar STX Essence), bluray drive, power supply, and perhaps even my CoolerMaster case. I haven't decided whether to use the old video card or try for one that will drive UHD 4K resolution -- the latter requiring a new monitor, too. Might be better just to start with the new equipment and see how easy or hard it is to get Arch up and running, then decide about the video.
Well you can always upgrade the video card later if needed. Audio card should not be a problem to move over as should the bluray drive. Any recent power supply should have ATX 24 pin power and 8 pin 12V power which should do just fine. And the case should be fine too, given both would be standard ATX boards. The only component I had trouble getting was the motherboard. Canada computers was out, so I ordered from newegg.ca, and then they canceled the order given they apparently had the inventory count wrong, so I ordered from isanek.com and next day got a message that the box had got crushed in the warehouse so they weren't shipping it, so then I made another order from newegg.ca who had apparently got more in stock, and they finally shipped it a couple of days later, after which it took 10 days to ship from california. Sheesh. -- Len Sorensen
On 2020-07-15 1:02 p.m., Peter King via talk wrote:
Suggestions/recommendations for places that build computers to custom specs with high build quality? And, for that matter, what a future-proof solid set of specs looks like these days?
That depends on the use cases. Are you just using it to access web pages and reading email, or are you wanting to use it for gaming? The amount of money you are willing to spend on a new machine is also another factor. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick
On Wed, Jul 15, 2020 at 01:38:25PM -0400, Kevin Cozens via talk wrote:
That depends on the use cases. Are you just using it to access web pages and reading email, or are you wanting to use it for gaming? The amount of money you are willing to spend on a new machine is also another factor.
No gaming, but audio editing and likely video editing as well. Mostly what I do is writing (neovim + (Xe)Tex) and editing (lots of high-resolution images of medieval manuscripts). Oodles of stored information, too, with complex structures. For the main unit, I'm willing to spend up to $3K or so. Less is good, more is possible. -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
Update: The motherboard is toast, and perhaps the CPU as well -- perhaps a power surge. So, new MB + CPU + RAM and maybe switching the case too. Oh well, time to see what's out there. -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
On Wed, Jul 15, 2020 at 01:02:24PM -0400, Peter King via talk wrote:
My main computer is in the shop (it won't pass a POST) and it looks like the motherboard may be the culprit. The last computers I had built were put together very well but the places where they were done no longer exist.
Suggestions/recommendations for places that build computers to custom specs with high build quality? And, for that matter, what a future-proof solid set of specs looks like these days? (This is to replace a 12-core i7 box with 32GB RAM and some 10TB of storage.) Thanks!
So by 12 core do you actually mean 12 tread (ie 6 core with hyperthreading) I would think? I just replaced the MB, cpu and ram in my father's machine because it was only successfully starting up about 10% of the time which was getting quite annoying, and it was about 6 or 7 years old. It went from a core i7 (4 core 8 thread) with 32GB ram and a pair of 120GB SSDs in RAID1 to a Ryzen 5 3600 (6 core 12 thread) with 32GB ram and a 1TB NVME M.2 drive. Of course for current AMD chips that's not a high end CPU and they have plenty of much more powerful chips if there is actually a need for that. I put in an Asus Prime X570-Pro motherboard, The Ryzen 5 3600 CPU, Corsair Vengeance LPX 32GB (2x16GB) DDR4 2666Mhz, and a Corsair Force MP600 1TB NVMe drive. Decent upgrade and not crazy expensive. Ryzen 7 chips with 8 core/16 thread or ryzen 9 with 12 core/24 thread are not that much more expensive for those with needs for that many CPUs. The case, power supply, bluray drive and video card didn't need to be changed. -- Len Sorensen
On Wed, Jul 15, 2020 at 02:48:16PM -0400, Lennart Sorensen via talk wrote:
It went from a core i7 (4 core 8 thread) with 32GB ram and a pair of 120GB SSDs in RAID1 to a Ryzen 5 3600 (6 core 12 thread) with 32GB ram and a 1TB NVME M.2 drive. Of course for current AMD chips that's not a high end CPU and they have plenty of much more powerful chips if there is actually a need for that.
So, what is your initial comparison? Roughly same? -- William Park <opengeometry@yahoo.ca>
On Wed, Jul 15, 2020 at 10:38:03PM -0400, William Park via talk wrote:
On Wed, Jul 15, 2020 at 02:48:16PM -0400, Lennart Sorensen via talk wrote:
It went from a core i7 (4 core 8 thread) with 32GB ram and a pair of 120GB SSDs in RAID1 to a Ryzen 5 3600 (6 core 12 thread) with 32GB ram and a 1TB NVME M.2 drive. Of course for current AMD chips that's not a high end CPU and they have plenty of much more powerful chips if there is actually a need for that.
So, what is your initial comparison? Roughly same?
Well after the 15 seconds or so the BIOS (well UEFI) takes to initialize the hardware, windows 10 boots to login prompt in about 3 seconds. Not sure what I could change to make the BIOS work faster. :) -- Len Sorensen
So in the end I went with a Ryzen 3700X CPU and the Asus Prime X570-Pro motherboard, adding in an NVMe drive as well for my boot/root device. The results have been mixed. The Good News: When I boot the Arch Linux installation image from a flash drive, then chroot into my old root filesystem, it all seems to run smoothly (within the limitations of the chroot). Nice and zippy, with good heat monitoring hardware and so on. The Bad News: The Asus BIOS will not recognize any of the SATA drives or the NVMe drive as bootable. I don't know why, since the BIOS does see all the drives otherwise. After some google search, I tried enabling CSM, which at least got me as far as seeing the other drives in the boot priority list, but, again, none are bootable. My current guess is that it's the Secure Boot option, which was enabled by default, and which I have no idea how to turn off. But maybe it's something else -- after putting an EFI partition on the NVMe drive and installing the kernel, I did use efibootmgr from inside the chroot to try to write the efivars that would select that NVMe drive to boot from, but efibootmgr --verbose seemed to indicate that the option was written to the USB flash drive instead ... ? Any, and all, suggestions welcome. I don't have any experience with the Secure Boot option, if that might be the culprit. -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
On 2020-07-25 21:06, Peter King via talk wrote:
So in the end I went with a Ryzen 3700X CPU and the Asus Prime X570-Pro motherboard, adding in an NVMe drive as well for my boot/root device. The results have been mixed.
Nice choice, been eyeing something similar myself. How much RAM and what speed did you go with?
Any, and all, suggestions welcome. I don't have any experience with the Secure Boot option, if that might be the culprit.
That the bootable USB works is curious, and makes me wonder if secure boot is really the issue. I've had great success using rEFInd to manage booting various OSes on my desktop. So my suggestions: --- 1. Try installing rEFInd - it will detect quite a few different bootable drives. http://www.rodsbooks.com/refind/installing.html#installsh --- 2. If you find that after running the install script rEFInd installs to the USB stick, try the manual steps on that page, from within your chroot. --- 3. Or, combine both. Bind mount /proc, /sys, and /dev from the USB stick into the chroot and then try the install script that way. --- 4. Otherwise, the more labour intensive option: your USB stick works, so hit escape while it is in the grub screens and examine all the arguments for the working installer kernel. You may be able to do something like run your own grub commands: `set root=(hdx,1)` (where you tab complete after the 'hd' part and you'll get a list of partitions to choose from). Once you're pointing at your Linux boot partition, load the kernel and initrd using the usual arguments for your previously working Arch+Grub. One thing to watch out for is that you get the correct root=LABEL=foo, or root=LABEL=$UUID, or root=/dev/nvmXXX argument right, otherwise you'll end up in your init recovery shell. Once you're in that way, you can try installing rEFINd again. Of course, messing with bootloaders, make a backup of your working bootable partition(s) if you don't have one already, ideally using dd. For reference, here's the EFI partition that I use with rEFInd and Grub as seen by fdisk: fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors Disk model: Samsung SSD 960 EVO 500GB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: C56F030C-9CDB-2A45-ABDE-A64263DFC0F4 Device Start End Sectors Size Type /dev/nvme0n1p1 2048 526335 524288 256M EFI System . . . And by findmnt: findmnt -u /boot/efi TARGET SOURCE FSTYPE OPTIONS /boot/efi /dev/nvme0n1p1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro
On Sat, Jul 25, 2020 at 10:15:15PM -0400, Jamon Camisso via talk wrote:
On 2020-07-25 21:06, Peter King via talk wrote:
So in the end I went with a Ryzen 3700X CPU and the Asus Prime X570-Pro motherboard, adding in an NVMe drive as well for my boot/root device. The results have been mixed.
Nice choice, been eyeing something similar myself. How much RAM and what speed did you go with?
I put in 32GB of Corsair Vengeance DDR-4 3600. Seems to be more than enough.
Any, and all, suggestions welcome. I don't have any experience with the Secure Boot option, if that might be the culprit.
That the bootable USB works is curious, and makes me wonder if secure boot is really the issue.
I think the motherboard recognizes the need for "emergency" booting and will allow a UEFI flash drive to run -- but not to access/modify the disks at a low level. It is curious. Then again, I don't know anything about Secure Boot, and maybe this is exactly what it does...
I've had great success using rEFInd to manage booting various OSes on my desktop. So my suggestions:
--- 1. Try installing rEFInd - it will detect quite a few different bootable drives. http://www.rodsbooks.com/refind/installing.html#installsh
I used rEFInd some years back, to manage a recalcitrant Apple laptop boot, but since then I've used EFI-stub booting, since I don't dual-boot and only run one kernel at a time. Perhaps not the best choice, though it does make for extraordinarily low boot times. If I can't get this problem solved I'll try rEFInd, though I suspect it is just waiting for something with a Microsoft signature.
--- 2. If you find that after running the install script rEFInd installs to the USB stick, try the manual steps on that page, from within your chroot.
--- 3. Or, combine both. Bind mount /proc, /sys, and /dev from the USB stick into the chroot and then try the install script that way.
I did do a chroot into the system on the NVMe disk, which is set up with an EFI partition, from the flash drive -- and indeed that ran fine; I used pacman to update various packages, changed the microcode, and so on. It just won't boot from the NVMe drive (or from the old SSD drive either).
4. Otherwise, the more labour intensive option: your USB stick works, so hit escape while it is in the grub screens and examine all the arguments for the working installer kernel.
You may be able to do something like run your own grub commands: `set root=(hdx,1)` (where you tab complete after the 'hd' part and you'll get a list of partitions to choose from). Once you're pointing at your Linux boot partition, load the kernel and initrd using the usual arguments for your previously working Arch+Grub.
One thing to watch out for is that you get the correct root=LABEL=foo, or root=LABEL=$UUID, or root=/dev/nvmXXX argument right, otherwise you'll end up in your init recovery shell.
Once you're in that way, you can try installing rEFINd again.
I haven't tried accessing the firmware UEFI shell, and past very bad memories of using the GRUB shell to boot make me desperately not want to do this. But, again, I'll do it if other things fail. Thanks for the very detailed reply! -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
| From: Peter King via talk <talk@gtalug.org> | So in the end I went with a Ryzen 3700X CPU and the Asus Prime X570-Pro | motherboard, adding in an NVMe drive as well for my boot/root device. The | results have been mixed. | | The Good News: When I boot the Arch Linux installation image from a flash | drive, then chroot into my old root filesystem, it all seems | to run smoothly (within the limitations of the chroot). | Nice and zippy, with good heat monitoring hardware and so | on. | | The Bad News: The Asus BIOS will not recognize any of the SATA drives or | the NVMe drive as bootable. I don't know why, since the | BIOS does see all the drives otherwise. After some google | search, I tried enabling CSM, which at least got me as far | as seeing the other drives in the boot priority list, but, | again, none are bootable. My current guess is that it's the | Secure Boot option, which was enabled by default, and which | I have no idea how to turn off. But maybe it's something | else -- after putting an EFI partition on the NVMe drive | and installing the kernel, I did use efibootmgr from inside | the chroot to try to write the efivars that would select | that NVMe drive to boot from, but efibootmgr --verbose | seemed to indicate that the option was written to the USB | flash drive instead ... ? Superstitious mode: - update the motherboard firmware if there is newer firmware. Sometimes things like this are bugs in the firmware. MBR booting and UEFI booting are very different. Your old system (and its disks) might have been set up for MBR booting. Your new system by default will only do UEFI booting. You can change this by turning on CSM and "legacy booting". Could this be the source of your problems? - your new system's UEFI firmware, by default, will only offer to boot from things that have an ESP (EFI System Partition, a FAT filesystem). - CSM should only be needed if you boot MBR-style (i.e. not UEFI) - was your old system (from which the disks were removed) using MBR or UEFI booting? If it was using MBR, and you wish to boot from those disks, you will need to enable "legacy booting" or whatever euphemism the firmware uses. - it isn't clear to me that it is a good idea to boot using MBR except for a short-term rescue mission. MBR is the (now distant) past. - MBR partitioning is a dead weight -- it puts low limits on disk sizes. Luckily, Linux uses GUID partitioning these days, with just enough gunk to get an MBR BIOS to boot. So even if your disks are set up for MBR booting, they probably use GUID partitioning. - I don't know an easy way of converting an already installed MBR-bootable Linux system into a UEFI-bootable system. - It might make sense to install a bootable Linux system with at least the ESP on your new NVMe drive. UEFI booting involves running some .efi file from the ESP. That Linux could mount the filesystems from your old disks (but not /boot/esp).
On Sun, Jul 26, 2020 at 10:41:50PM -0400, D. Hugh Redelmeier via talk wrote:
Superstitious mode:
- update the motherboard firmware if there is newer firmware. Sometimes things like this are bugs in the firmware.
Did that, so it should be good to go...
MBR booting and UEFI booting are very different. Your old system (and its disks) might have been set up for MBR booting. Your new system by default will only do UEFI booting. You can change this by turning on CSM and "legacy booting". Could this be the source of your problems?
The old system booted UEFI, indeed EFI-stub. The NVMe drive is formatted with an EFI "boot" partition as VFAT-32 and a regular root partition as ext4 -- pretty standard fare.
- your new system's UEFI firmware, by default, will only offer to boot from things that have an ESP (EFI System Partition, a FAT filesystem).
- CSM should only be needed if you boot MBR-style (i.e. not UEFI)
Ahh, I didn't know that.
- was your old system (from which the disks were removed) using MBR or UEFI booting? If it was using MBR, and you wish to boot from those disks, you will need to enable "legacy booting" or whatever euphemism the firmware uses.
Right. It wasn't, and I don't; that was the point behind putting in the NVMe drive.
- It might make sense to install a bootable Linux system with at least the ESP on your new NVMe drive. UEFI booting involves running some .efi file from the ESP. That Linux could mount the filesystems from your old disks (but not /boot/esp).
That's what I'm trying to do! But the motherboard won't see it as a "bootable drive" (nor does it see the old SSD as a bootable drive). Admittedly, when I was in the chroot to the old root filesystem and then tried to use efibootmgr to write the parameters of the NVMe drive to the system, it claimed to have "installed" only the USB flash drive, not the new NVMe system. I have no idea why. While chrooted I could run pacman, modify files, do all the sorts of things one can normally do within the confines of a chroot (so nothing that involved systemd running at boot). It's ... odd. All the more so since this is, it seems, a fairly popular motherboard in the linux world... -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
Secure Boot: Microsoft requires PC hardware to be shipped with Secure Boot enabled. I think that they also require that it be possible to disable it (but only manually, not by program). Secure boot requires that there be a cryptographically authenticated unbroken chain of things that lead to loading the OS. Authentication of things loaded by the UEFI amounts to being signed by a key for which the firmware knows the public key. The only public key most UEFI firmware knows is controlled by Microsoft. Red Hat has arranged for Microsoft to sign a loader that will then load other things: shim.efi. Red Hat made this available to any other Linux Distro, I think. Some other Linux systems have adopted this. For example, UBUNTU and SuSE. I don't know if your distro has. Suggestion: disable secure boot and continue your experiments. I know you said that you cannot find the setting, but it must be there somewhere in the firmware setup screen. Odd: googling seems to suggest that the only way to turn off SB on Asus boards is to delete the PK key. If you are going to do this, please save the key first in case you need to restore it. =================================================== Anecdote: I have a computer that every once in a while stops being able to boot. The problem is that a power failure has left the ESP in a bad state (I don't know why: there should have been now writing to it immediately before the power failure). My cure used to be: - boot from a USB stick - run fsck against the ESP. After that, the system boots. I eventually gave up and put the computer on a UPS. Take-away: perhaps you need to fsck the ESP on your hard drive. =================================================== | From: Peter King via talk <talk@gtalug.org> | The old system booted UEFI, indeed EFI-stub. The NVMe drive is formatted | with an EFI "boot" partition as VFAT-32 and a regular root partition as | ext4 -- pretty standard fare. The EFI-stub is certainly not signed.
On Mon, Jul 27, 2020 at 01:57:02PM -0400, D. Hugh Redelmeier via talk wrote:
Microsoft requires PC hardware to be shipped with Secure Boot enabled. I think that they also require that it be possible to disable it (but only manually, not by program).
Secure boot requires that there be a cryptographically authenticated unbroken chain of things that lead to loading the OS. Authentication of things loaded by the UEFI amounts to being signed by a key for which the firmware knows the public key.
The only public key most UEFI firmware knows is controlled by Microsoft. Red Hat has arranged for Microsoft to sign a loader that will then load other things: shim.efi. Red Hat made this available to any other Linux Distro, I think.
Some other Linux systems have adopted this. For example, UBUNTU and SuSE. I don't know if your distro has.
Suggestion: disable secure boot and continue your experiments. I know you said that you cannot find the setting, but it must be there somewhere in the firmware setup screen.
Odd: googling seems to suggest that the only way to turn off SB on Asus boards is to delete the PK key. If you are going to do this, please save the key first in case you need to restore it.
Thanks! That is an admirably clear description of Secure Boot, which makes it seem like, well, like not a crazy idea. Yes, I'm pretty sure Secure Boot is the culprit. Googling tells me that I can only disable it on the Asus Prime X570-Pro motherboard by deleting the keys listed under "Key Management" (or at least the PK key), which I was hesitant to try -- it seemed like a one-way street -- but I'll save the key in several places just in case. I guess Arch Linux doesn't have any arrangment with Microsoft. -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
| From: Peter King via talk <talk@gtalug.org> | On Mon, Jul 27, 2020 at 01:57:02PM -0400, D. Hugh Redelmeier via talk wrote: | > Odd: googling seems to suggest that the only way to turn off SB on Asus | > boards is to delete the PK key. If you are going to do this, please save | > the key first in case you need to restore it. | ... I'll save the key | in several places just in case. The key is a Public Key. It isn't a secret. You can probably copy it from any modern PC in the universe, assuming it is formatted identically. So extreme care may not be needed. Typing it in would be painful. | I guess Arch Linux doesn't have any arrangment with Microsoft. As I understand it, Arch would only have to talk to Red Hat. My guess is that Arch would have to present a binary to be signed by RH, and then shim.efi would be willing to load it. But the process is fairly rigid so as not to dilute the meaning of Secure Boot. So user-built kernels probably cannot be loaded. Nor can kernels with tainted drivers. You could add your own key to the firmware setup. Then you could sign your own kernels. I don't know of any individual being that fastidious.
On Mon, Jul 27, 2020 at 01:57:02PM -0400, D. Hugh Redelmeier via talk wrote:
Secure Boot:
Microsoft requires PC hardware to be shipped with Secure Boot enabled. I think that they also require that it be possible to disable it (but only manually, not by program).
Secure boot requires that there be a cryptographically authenticated unbroken chain of things that lead to loading the OS. Authentication of things loaded by the UEFI amounts to being signed by a key for which the firmware knows the public key.
The only public key most UEFI firmware knows is controlled by Microsoft. Red Hat has arranged for Microsoft to sign a loader that will then load other things: shim.efi. Red Hat made this available to any other Linux Distro, I think.
Some other Linux systems have adopted this. For example, UBUNTU and SuSE. I don't know if your distro has.
Suggestion: disable secure boot and continue your experiments. I know you said that you cannot find the setting, but it must be there somewhere in the firmware setup screen.
Odd: googling seems to suggest that the only way to turn off SB on Asus boards is to delete the PK key. If you are going to do this, please save the key first in case you need to restore it.
No need. There is a load default keys option to restore the microsoft keys. -- Len Sorensen
Well, no joy in Mudville. I disabled Secure Boot by deleted the PK key, which did indeed result in the motherboard BIOS recognizing that Secure Boot was disabled. And, it recognizes the NVMe drive as the boot device, indeed the only boot device, which is good. But ... despite all that, it still does not boot. I tried it with CSM on and CSM off, still no boot. Efibootmgr this time *did* list the NVMe drive as an EFI option (after the USB flash drive), but still no boot. Tried it with various options enabled and disabled, still no joy. Damned if I can figure it out. I feel like I'm getting closer ... but no way forward seems obvious. Any ideas? Any reason to think that another motherboard might be less difficult to get up and running? -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
On 7/27/20 9:05 PM, Peter King via talk wrote:
Well, no joy in Mudville.
I disabled Secure Boot by deleted the PK key, which did indeed result in the motherboard BIOS recognizing that Secure Boot was disabled. And, it recognizes the NVMe drive as the boot device, indeed the only boot device, which is good.
But ... despite all that, it still does not boot. I tried it with CSM on and CSM off, still no boot. Efibootmgr this time *did* list the NVMe drive as an EFI option (after the USB flash drive), but still no boot. Tried it with various options enabled and disabled, still no joy.
Damned if I can figure it out. I feel like I'm getting closer ... but no way forward seems obvious. Any ideas? Any reason to think that another motherboard might be less difficult to get up and running?
--- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Are you able to get to a grub boot screen or not. Does it not reach Linux or it a issue with the BIOS still. There are one of three issues it seems: 1. Buggy BIOS and therefore you may need to flash it 2. If your getting to grub then its a Linux issue somewhere in the runlevels configuration so try single user mode 3. There is a missing option in the BIOs that you need to check, not sure which as I'm not aware of that board's firmware I has this issue with my system after reinstalling a drive and it was a missed setting in the firmware. Maybe this helps, Nick -- Fundamentally an organism has conscious mental states if and only if there is something that it is like to be that organism--something it is like for the organism. - Thomas Nagel
On 2020-07-27 21:05, Peter King via talk wrote:
Well, no joy in Mudville.
I disabled Secure Boot by deleted the PK key, which did indeed result in the motherboard BIOS recognizing that Secure Boot was disabled. And, it recognizes the NVMe drive as the boot device, indeed the only boot device, which is good.
But ... despite all that, it still does not boot. I tried it with CSM on and CSM off, still no boot. Efibootmgr this time *did* list the NVMe drive as an EFI option (after the USB flash drive), but still no boot. Tried it with various options enabled and disabled, still no joy.
Damned if I can figure it out. I feel like I'm getting closer ... but no way forward seems obvious. Any ideas? Any reason to think that another motherboard might be less difficult to get up and running?
Try installing rEFInd to a USB stick, then boot from it. It will (hopefully) autodetect your various EFI partitions and build a list of target systems that you can boot. The USB image is available here: https://sourceforge.net/projects/refind/files/0.12.0/refind-flashdrive-0.12.... Since you managed to boot from a USB stick before, this might be enough of a bodge to get you going. Cheers, Jamon
On Mon, Jul 27, 2020, 9:06 PM Peter King via talk, <talk@gtalug.org> wrote:
Well, no joy in Mudville.
I disabled Secure Boot by deleted the PK key, which did indeed result in the motherboard BIOS recognizing that Secure Boot was disabled. And, it recognizes the NVMe drive as the boot device, indeed the only boot device, which is good.
But ... despite all that, it still does not boot. I tried it with CSM on and CSM off, still no boot. Efibootmgr this time *did* list the NVMe drive as an EFI option (after the USB flash drive), but still no boot. Tried it with various options enabled and disabled, still no joy.
I don't use Arch myself but the various GPT or MBR and Hybrid schemes are covered, along with issues, notes and warnings here.
https://wiki.archlinux.org/index.php/Arch_boot_process
Damned if I can figure it out. I feel like I'm getting closer ... but no way forward seems obvious. Any ideas? Any reason to think that another motherboard might be less difficult to get up and running?
I don't think so. You are making progress. It might be that the bootloader can't actually access /boot or because of some confusion in addressing the partition table format. HTH Russell
-- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA
http://individual.utoronto.ca/pking/
========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42 --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On Mon, Jul 27, 2020 at 09:05:58PM -0400, Peter King via talk wrote:
Well, no joy in Mudville.
I disabled Secure Boot by deleted the PK key, which did indeed result in the motherboard BIOS recognizing that Secure Boot was disabled. And, it recognizes the NVMe drive as the boot device, indeed the only boot device, which is good.
But ... despite all that, it still does not boot. I tried it with CSM on and CSM off, still no boot. Efibootmgr this time *did* list the NVMe drive as an EFI option (after the USB flash drive), but still no boot. Tried it with various options enabled and disabled, still no joy.
Damned if I can figure it out. I feel like I'm getting closer ... but no way forward seems obvious. Any ideas? Any reason to think that another motherboard might be less difficult to get up and running?
Is the nvme using GPT partitions and a UEFI boot loader? Often UEFI boot required adding an entry to the nvram unless it happens to use one of the default filenames for the boot loader. You could go to the UEFI shell and try to manually boot grub and then reinstall the boot loader after booting to linux. Usually something like: blk1: cd \EFI dir (find where grub is) cd ubuntu (or debian or arch or whatever it named it) grubx64.efi Once booted efibootmgr or some other tool should let you reinstalle the boot entry in nvram. The default that it looks for I believe is \EFI\BOOT\BOOTX64.EFI but most linux distributions don't use that name as far as I know. -- Len Sorensen
| From: Lennart Sorensen via talk <talk@gtalug.org> | You could go to the UEFI shell and try to manually boot grub and then | reinstall the boot loader after booting to linux. I seem to remember that Microsoft forbids system from shipping with the UEFI shell. This only applies to ones clainming Windows compatability, but that is all of them. So you have to add your own UEFI shell. Where do you recommend getting one?
On 7/28/20 3:48 PM, D. Hugh Redelmeier via talk wrote:
| From: Lennart Sorensen via talk <talk@gtalug.org>
| You could go to the UEFI shell and try to manually boot grub and then | reinstall the boot loader after booting to linux.
I seem to remember that Microsoft forbids system from shipping with the UEFI shell. This only applies to ones clainming Windows compatability, but that is all of them.
So you have to add your own UEFI shell.
Where do you recommend getting one? --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
It depends on the system but for the x570 board after checking the manual online it seems possible using a USB drive. From memory this was the common way to do that. Hopefully that answers Huge's and Peter's questions about this. Nick -- Fundamentally an organism has conscious mental states if and only if there is something that it is like to be that organism--something it is like for the organism. - Thomas Nagel
On Tue, Jul 28, 2020 at 03:48:42PM -0400, D. Hugh Redelmeier via talk wrote:
I seem to remember that Microsoft forbids system from shipping with the UEFI shell. This only applies to ones clainming Windows compatability, but that is all of them.
So you have to add your own UEFI shell.
Where do you recommend getting one?
Oh, good point. I am used to UEFI on servers. Apppartently to get the shell you need shellx64.efi on a USB key in order to do that and then pick launch EFI shell from usb. https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#SHELL seems to have links to some places one can download a build UEFI shell binary. Could you perhaps give a list of what files you have on the EFI boot partition? ie: find /boot/efi -ls (assuming that is where it is mounted). I guess you would need to mount the nvme drive's efi partition somewhere and run find on that location instead actually. Might be able to find what boot files are there. You should even be able to go in there and make a copy of the boot file into the default location which might make it automatically boot it. That would be EFI/BOOT/BOOTX64.EFI on the FAT boot partition. Often you will have something like EFI/ARCH/GRUBX64.EFI or similar, so making a new directory called BOOT and copying the grub file there as BOOTX64.EFI should make it automatically boot. -- Len Sorensen
| From: D. Hugh Redelmeier via talk <talk@gtalug.org> | - CSM should only be needed if you boot MBR-style (i.e. not UEFI) This turns out not to be the case. CSM is a fake BIOS. It is used to implement things link BIOS service calls. These are used by: - MBR boot loaders (lilo, grub-for-MBR) - old OSes (like DOS) - initialization code that might be present in som plug-in cards. This initialization code was considered an extension of the BIOS initialization code. I imagine that these cards are all obsolete now. My comment left out the last case. Note: theses service calls assume the CPU is in 16-bit more, something unlikely for any modern operating system.
On Mon, Jul 27, 2020 at 12:12:27PM -0400, D. Hugh Redelmeier via talk wrote:
| - CSM should only be needed if you boot MBR-style (i.e. not UEFI)
This turns out not to be the case.
CSM is a fake BIOS. It is used to implement things link BIOS service calls. These are used by:
- MBR boot loaders (lilo, grub-for-MBR)
- old OSes (like DOS)
- initialization code that might be present in som plug-in cards. This initialization code was considered an extension of the BIOS initialization code. I imagine that these cards are all obsolete now.
My comment left out the last case.
I definitely am trying to get UEFI to boot, not MBR, and while *NIX is an old OS in some sense it isn't the sense that matters here. So, I'll turn off CSM. Thanks! -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
A measure of success! Instead of trying to boot from the NVMe drive, I updated the SATA SSD drive and set it up to boot EFI-stub. It booted right up, updated things, and generally settled into the new hardware with only minor problems. So far, then, it seems clear that I had at least two problems: (a) disabling Secure Boot, and (b) some undiagnosed problems about booting from the NVMe drive. While (a) might have been anticipated, (b) was a surprise, and I still don't know why the NVMe drive is problematic. But I can solve that problem later, with the help of all the suggestions and advice people have offered. Once I iron out the minor problems (no network), I'll then try booting from the NVMe drive via a bootloader -- rEFInd and GRUB2 have been proposed -- to see if that helps. But having a working system makes it much less urgent. Thanks again to one and all! -- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA http://individual.utoronto.ca/pking/ ========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
On Tue, Jul 28, 2020 at 9:44 AM Peter King via talk <talk@gtalug.org> wrote:
A measure of success!
Instead of trying to boot from the NVMe drive, I updated the SATA SSD drive and set it up to boot EFI-stub. It booted right up, updated things, and generally settled into the new hardware with only minor problems. So far, then, it seems clear that I had at least two problems: (a) disabling Secure Boot, and (b) some undiagnosed problems about booting from the NVMe drive.
While (a) might have been anticipated, (b) was a surprise, and I still don't know why the NVMe drive is problematic. But I can solve that problem later, with the help of all the suggestions and advice people have offered. Once I iron out the minor problems (no network), I'll then try booting from the NVMe drive via a bootloader -- rEFInd and GRUB2 have been proposed -- to see if that helps. But having a working system makes it much less urgent.
If you are currently using GRUB apparently a package update has blundered an initramfs hook. https://forum.manjaro.org/t/arch-new-kernel-packages-and-mkinitcpio-hooks/11... According to this post, that issue is solvable. https://bbs.archlinux.org/viewtopic.php?id=250674 In a nutshell ... sudo mkinitcpio -P sudo update-grub
Thanks again to one and all!
-- Peter King peter.king@utoronto.ca Department of Philosophy 170 St. George Street #521 The University of Toronto (416)-946-3170 ofc Toronto, ON M5R 2M8 CANADA
http://individual.utoronto.ca/pking/
========================================================================= GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42) gpg --keyserver pgp.mit.edu --recv-keys 7587EC42 --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
-- Russell
participants (10)
-
D. Hugh Redelmeier -
Don Tai -
James Knott -
Jamon Camisso -
Kevin Cozens -
lsorense＠csclub.uwaterloo.ca -
Nicholas Krause -
Peter King -
Russell Reiter -
William Park