The special case of checking the filesystem is added to reduce the other special case - the one for / - so it doesn't apply if the filesystem doesn't match. I kind of agree that "mount -u /" shouldn't be special, but as I've said - there might be something out there that will get broken by removing it. So instead I'm trying to just fix the case that's clearly broken (it results in mount(8) executing something like "mount_nfs -o remount,rw /dev/ada0 /") and not touching others.

Looks good. You might ask for testing in the freebsd-stable@ thread, "vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available)".

I don't have a slightest idea why the special case is required. But it might be, and removing it altogether might break somebody's system. Adding additional condition is much less intrusive, and thus safer.

Okay; Alex explained to me what it actually does. Geez, make(1) is hard...

Okay. But then what exactly is the purpose of the change, compared to eg just adding "-v" to the code currently in the tree?

I (believe I) understand the problem. I'm not sure what the patch does, though. Where's the "-v" there?

So, while the problem pointed by Rod is real, I don't really see no easy way to fix it. Meanwhile, this patch improves stuff a lot for the common case and shouldn't make matters any worse in the other case. So, I think I'll just commit it, noting the potential problem with resizing after logging in.

Bryan, does this look ok to you? Thanks!

Hm, that's a good point. On the other hand I'm not quite happy about moving stuff into getty(8).

No, this is just an ordinary getty. It works the same with literally everything I've tested it with. Terminal mismatch is possible, kind of - but that wouldn't explain why rows/cols are zero, even though the termcap entry for vt100 hardcodes them.

So, first of all, your terminal size is wrong. :-) Terminals are much larger these days, and people generally expect the stuff on the screen to use the available space.

I wonder if the line should be removed instead. BSD.usr.dist seems to already be handled in etc/Makefile.

On the other hand, the binary was 2.2GB big on amd64, so it _might_ be over the 1GB text size limit. I'll ask about bumping it, I guess.

Hm, for other 64 bit architectures MAXTSIZ seems to be equal to MAXDSIZ already, except that both are 1GB. Not sure if we need to do anything about that then.

Move the invocation to a more appropriate place.

Updates.

Comments from cem@.

Okay. Do you have any suggestions on what should happen in this case? How the buf should be handled?

To be honest I don't quite like that it either, but don't know any better place to put this. /root/{.profile,.login} perhaps?

The patch fixes an instapanic. Granted, the buffer won't get correctly handled later on - but that's a separate issue, and can't really be addressed until this one is fixed. That said, I don't quite follow: which buffer gets destroyed?