Bug 213651

Summary: include serial console support in install media by default, via /usr/src/release/Makefile adjustments?
Product: Base System Reporter: slvr32
Component: confAssignee: Glen Barber <gjb>
Status: New ---    
Severity: Affects Only Me    
Priority: ---    
Version: 10.3-RELEASE   
Hardware: Any   
OS: Any   

Description slvr32 2016-10-20 17:26:53 UTC
I'm aware that there are a couple of different methods to accommodate serial console install, e.g. via boot floopy or by modifying install media to add 'console=comconsole' to /boot/loader.conf, but would it be worth entertaining serial console support by default?

With FreeBSD 10.3, I noticed that it would be quite easy to accomplish this with a few changes to /usr/src/release/Makefile

(add the console=comconsole detail after the vfs.mountroot.timeout entries in /usr/src/release/Makefile, e.g. for context...

echo vfs.mountroot.timeout=\"10\" >> ${.TARGET}/boot/loader.conf
echo console=\"comconsole\" >> ${.TARGET}/boot/loader.conf
Comment 1 Glen Barber freebsd_committer 2016-10-20 17:48:54 UTC
There are a few problems with this, because of my own observations on some systems with multiple COM ports that I'm still trying to understand.

On some systems, for example, doing as suggested will prevent keyboard input via serial console and only allow keyboard input on the system (and loader actually stops the system from booting on one system I have).

Could you try instead adding 'boot_multicons="YES"' to your modification to see if you see the desired behavior?  I'm a bit overly-paranoid about this because of some behavior I have witnessed, and do not want to introduce regressions on hardware that used to work out-of-box without loader.conf changes.
Comment 2 slvr32 2016-10-20 17:59:05 UTC
I fully appreciate that my particular suggestion may not be portable, and I'm really only bringing this up because I generally build (i386) releases at a particular patch level, and then modify the disc1.iso image after the fact to add the console=comconsole detail, but I've found that when I create the ISO with just that modification, the size of that ISO is significantly larger than the original disc1 ISO, to the point that it no longer will fit on a single CD, even with overburning.
Comment 3 Glen Barber freebsd_committer 2016-10-20 18:01:50 UTC
That is extremely odd.  How much larger is the modified disc1.iso?
Comment 4 slvr32 2016-10-20 22:05:00 UTC
So, just to try to be thorough, the ISO modification approach is based on https://docs.freebsd.org/doc/9.1-RELEASE/share/doc/freebsd/handbook/install-advanced.html but I've personally found that the suggested instructions fail with tar-related errors on a FreeBSD box...

# mkdir /path/to/headless-iso
# tar -C /path/to/headless-iso -pxvf FreeBSD-9.1-RELEASE-i386-disc1.iso

And I instead typically do the following on a Linux box...

# mount -t iso9660 -o loop /var/tmp/FreeBSD-9.3-RELEASE-p38-i386-disc1.iso /mnt/cdrom
# cd
# (cd /mnt; tar cvf - cdrom) | tar xvf -
# echo 'console="comconsole"' >> cdrom/boot/loader.conf
# cd cdrom
# mkisofs -R -no-emul-boot -b boot/cdboot -o /var/tmp/FreeBSD-9.3-RELEASE-p38-i386-disc1-headless.iso .

# cd /var/tmp
# du -hsc *.iso

568M FreeBSD-9.3-RELEASE-p38-i386-disc1.iso
690M FreeBSD-9.3-RELEASE-p38-i386-disc1-headless.iso

The significant size increase for the headless iso has always been curious, but I haven't been concerned as long as it's still fit on a 700 MB CD.

If I repeat the same process for the FreeBSD 10.3 disc1 iso, it just happens that I end up well north of 700 MB...

618M	FreeBSD-10.3-RELEASE-i386-disc1.iso
792M	FreeBSD-10.3-RELEASE-i386-disc1-headless.iso

and that's what's motivating me to just add the console=comsole configuration to boot/loader.conf in the original release build.

Of course the size increase on the before/after iso images may be more about mkiosofs behavior with certain options, depending what gets put in a particular iso, etc...

I don't doubt that boot_multicons=YES may work just as well, and the console=comsole is more just based on habit over the years.
Comment 5 Glen Barber freebsd_committer 2016-10-20 22:22:16 UTC
(In reply to slvr32 from comment #4)

Thank you very much for the detailed information.

The reason I asked is because I have seen this just before 11.0-RC3 while testing something and re-rolling disc1.iso for PowerPC, and could not understand why the image size difference was so drastic.  Then I re-rolled the ISO with a clean /usr/obj, and the resulting image was "normal."  But, due to time constraints, did not investigate further.

So at least now I know there is something strange is happening.

This, however, does not resolve the original reason for the bug report, but at least now I know something odd is indeed happening, and I will investigate.