From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 22:42:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AD9A853 for ; Tue, 26 Feb 2013 22:42:06 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from vps.van-laarhoven.org (www.hibma.org [178.21.117.90]) by mx1.freebsd.org (Postfix) with ESMTP id AA41C705 for ; Tue, 26 Feb 2013 22:42:05 +0000 (UTC) Received: from [192.168.178.106] (thuis.van-laarhoven.org [80.100.41.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by vps.van-laarhoven.org (Postfix) with ESMTPSA id 5AA465F22C6 for ; Tue, 26 Feb 2013 23:40:14 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: No console, not even serial, does not work (init fails) - init from HEAD works From: Nick Hibma In-Reply-To: Date: Tue, 26 Feb 2013 23:41:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2820BD0B-BCFA-4068-AFE7-D123630828E4@van-laarhoven.org> References: <96A2B40B-4191-4C4F-8AA5-39526E252D40@van-laarhoven.org> To: =?windows-1252?Q?=93FreeBSD_Current_Mailing_List=94?= X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:42:06 -0000 [feels like I am talking to myself in this thread ...] After copying the /usr/src/sbin/init/ directory from HEAD to 8.3-RELEASE = and building init there (without changes), things started working again, = and the image now succesfully boots. Thanks for that. The downside of this approach is the lack of logging of the output of = the console output. I've tried quickly to throw together a 'null' = console which would make the console output at least appear in the = output of 'dmesg -a', but that change requires a tty device, which I = couldn' be asked to throw together. Ed was going to think this over, = especially because a null console might come in handy in jails. Hope this is of use to anyone. Nick Hibma nick@van-laarhoven.org How many todos are on YOUR To Do lists? - GTD On 19 Feb 2013, at 10:03, Nick Hibma wrote: > Ed sent me a answer to my ramblings: >=20 > "It is indeed true that init(8) is a bit picky when you don't have a > console. If /dev/console cannot be opened, init(8) will just break > completely. This has been fixed in FreeBSD -HEAD, where I've extended > init(8) to handle this gracefully, specifically for cases where you > have hardware without a console or potentially want to run init(8) in > a jail (though we're not there yet)." >=20 > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D232977 >=20 > I'll try that, and will follow up here. >=20 > Nick Hibma > nick@van-laarhoven.org >=20 > Collect, process, organize, review and do. - GTD >=20 > On 18 Feb 2013, at 20:30, Nick Hibma wrote: >=20 >> We run our NanoBSD images on Soekris and ALIX hardware. In some cases = we need all available serial ports for other hardware like GPS, and = modems. The boards have no video, so with all serial ports unavailable = as a console no other console is available. >>=20 >> The problem is that FreeBSD does not handle well the case where there = is no console at all: >>=20 >> 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/102515 >>=20 >> fsck_ufs crashes (6.1-STABLE). Because of the unitialised console = libc somehow gets corrupted and crashes fsck_ufs. This problem can be = circumvented by replacing 'fsck -p' with 'fsck < /dev/null > /dev/null'. >>=20 >> 2) In 8.3-RELEASE init exits prematurely because it cannot open = /dev/console for reading and writing in setctty(). Removing the calls to = _exit(1) in that function makes the boot complete. I haven't checked = whether the fsck_ufs problem still appears as our builds run with a = patched rc.d script. >>=20 >>=20 >> As far as I can see this is still a problem in CURRENT. >>=20 >>=20 >> My attempt at resolving this was to create a null terminal in = dev/null/null.c, see the patch below, but that did not work as expected. = After booting the system with a modified init the response to 'echo > = /dev/console' was 'Device not configured'. I've added another CN_* = priority to make sure a null console does not take precedence over for = example gdb console. >>=20 >>=20 >> Any pointers as to who/how to resolve this issue? Any reason why the = null console approach does not work? >>=20 >> Nick Hibma >> nick@van-laarhoven.org >>=20 >> GTD: Time management for chaotic people. >>=20 >> Index: /usr/src/sys/sys/cons.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/sys/cons.h (revision 242660) >> +++ /usr/src/sys/sys/cons.h (working copy) >> @@ -69,10 +69,11 @@ >>=20 >> /* values for cn_pri - reflect our policy for console selection */ >> #define CN_DEAD 0 /* device doesn't exist */ >> -#define CN_LOW 1 /* device is a last restort only = */ >> -#define CN_NORMAL 2 /* device exists but is nothing special = */ >> -#define CN_INTERNAL 3 /* "internal" bit-mapped display */ >> -#define CN_REMOTE 4 /* serial interface with remote bit set = */ >> +#define CN_NULL 1 /* no console at all */ >> +#define CN_LOW 2 /* device is a last restort only = */ >> +#define CN_NORMAL 3 /* device exists but is nothing special = */ >> +#define CN_INTERNAL 4 /* "internal" bit-mapped display */ >> +#define CN_REMOTE 5 /* serial interface with remote bit set = */ >>=20 >> /* Values for cn_flags. */ >> #define CN_FLAG_NODEBUG 0x00000001 /* Not supported with = debugger. */ >> Index: /usr/src/sys/dev/null/null.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/dev/null/null.c (revision 242660) >> +++ /usr/src/sys/dev/null/null.c (working copy) >> @@ -41,6 +41,9 @@ >> #include >> #include >>=20 >> +#include >> +#include >> + >> #include >>=20 >> /* For use with destroy_dev(9). */ >> @@ -173,3 +176,45 @@ >>=20 >> DEV_MODULE(null, null_modevent, NULL); >> MODULE_VERSION(null, 1); >> + >> +static cn_probe_t null_cnprobe; >> +static cn_init_t null_cninit; >> +static cn_term_t null_cnterm; >> +static cn_getc_t null_cngetc; >> +static cn_putc_t null_cnputc; >> + >> +CONSOLE_DRIVER(null); >> + >> +static void >> +null_cnprobe(struct consdev *cp) >> +{ >> + sprintf(cp->cn_name, "null"); >> + cp->cn_pri =3D CN_NULL; >> +} >> + >> +static void >> +null_cninit(struct consdev *cp) >> +{ >> +} >> + >> + >> +static void >> +null_cnputc(struct consdev *cp, int c) >> +{ >> + (void) cp; >> + >> + (void) c; >> +} >> + >> +static int >> +null_cngetc(struct consdev * cp) >> +{ >> + (void) cp; >> +=09 >> + return -1; >> +} >> + >> +static void >> +null_cnterm(struct consdev * cp) >> +{ >> +} >>=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"