The primary shard
The term primary shard refers to the shard of a cluster on which the non-sharded collections of a database are located. This can can (and in the case that you only had one shard when creating a database will) be the first shard added to a cluster. But if you have multiple shards, any of those may be selected as the primary shard for new databases.
What happens if the primary shard fails
Ok, let's assume you only have standalone servers as shards. If the primary fails, all unsharded collections residing on that shard become unavailable. Additionally, all chunks residing on that shard become unavailable, too. Another effect is that writing documents with shard keys currently associated with the failed shard becomes impossible.
With reads and writes from and to the failed shard being impossible, there is a more subtle effect caused: chunk migrations from and to said shard can't be executed. This may lead to jumbo chunks, which have to be identified and then split manually before they can be migrated by the balancer.
All of the above makes it very clear why a shard should be a replica set and not a standalone server, except when using MongoDB for caching purposes (maybe).
If the primary replica set member of a shard goes down, elections will be held, the new primary will be announced and everything (except for the failed machine) is back to normal. Even on heavily loaded clusters I haven't seen Jumbo chunks because of a failover, yet.