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
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.
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.
That is extremely odd. How much larger is the modified disc1.iso?
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.
(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.
^Triage: commit bit was taken in for safekeeping. To submitter: is this aging PR still relevant?
I appreciate that you added that you also noticed a drastic size difference when re-rolling a powerpc iso, and the detail that the second attempt with a clean /usr/obj seemed to resolve the size issue. Maybe the clean /usr/obj detail would be worth adding to related documentation for a headless install and/or customizing ISOs, but I'm not sure of the best place to put this in current documentation.