From nobody Mon Aug 22 21:51:03 2022 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MBQzS5mn5z4ZmHJ for ; Mon, 22 Aug 2022 21:51:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MBQzR4xY0z3stm for ; Mon, 22 Aug 2022 21:51:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe29.google.com with SMTP id o123so12668886vsc.3 for ; Mon, 22 Aug 2022 14:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=vGHNRj0LdpEPhvooX5pk+3ll+Xcy0K8YW5C30tGCAA8=; b=GaWN8yB34ArZ7mAZuW3r5gYqCH1F8N/IF4s6Ou9H0zCPXwmwnlXxXX9YGFSxO71cyR 0LAOOns+jGGtIuiCQ2Fy6ceOrIWOz42I/DkKg2w+iwAQeNXGWCRBYzG104HSv0nubq6O ud2d+O6m8mD3+lN2amhY3SY4v/qFajGRaga23Xb2RGlW3vX2gu8Zw6DRRQal/M6xzMlV OX/5HLca1Ga91PCmxT83i6xEqf1iP4RggNEUktBW5RVPdDtknfdWz84Bg5M459FFG9Rn aN59nxtN5mGJRWD5pY/IfxiJDIkx4kU16LJVN53F7g9V6AHTc7v2hK5JEbMXRy4SLAk1 4Epg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=vGHNRj0LdpEPhvooX5pk+3ll+Xcy0K8YW5C30tGCAA8=; b=Jv4x7Xy2k2drgGw9dgvTRGa9ZGguEVkc2FsScKa88tnSaLcy0wW6fAD4J/B/uxSxBz IPaR5ydK3ob210PVwwvN7VnQKsgqXYvwYBAPcfPUmw6sEkCfRFUd0kIILx2er/LXmq4Y 5IbXO5dWJEVpfOY/QSBnZuxQ4CK0qJx3ZFdZ6t2Am3oE8zF0FcrCvaOXE+e+2164wbCz ia191GsO6pGrF7+GQpV2ccsR2/KvUq2A7ovg0eTFJ7FnrtyBpjnUn2EYUEe79bi3k3MY HukeNnZSuw2XrHUbQPckQ3mkVl0na/ncOxtHoOfltIhsdhXzfem7H8dd7yS4oUo7WZxU RtUQ== X-Gm-Message-State: ACgBeo2MguPVWt+XJ0lBlK+M+MeKv/2EU4mXJ+JKJsTHi22vsyRlEj3d V2pHVsvw2yMLSN4Zt/DPBkx9Cg3nZOZGSSwKi+E2AQ== X-Google-Smtp-Source: AA6agR4bsmUjNXiXntTekx4KcZ2AUvsXRBSo1XftsjsQhT9/qmHXeGoYCMLiwFV7cWJ9ZoCxCTYV1mczlWEs4myLuS4= X-Received: by 2002:a67:b205:0:b0:390:793f:9fd3 with SMTP id b5-20020a67b205000000b00390793f9fd3mr1260127vsf.67.1661205074900; Mon, 22 Aug 2022 14:51:14 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 22 Aug 2022 15:51:03 -0600 Message-ID: Subject: Re: init (/rescue/sh) died To: "Bjoern A. Zeeb" Cc: Konstantin Belousov , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000006390d905e6db72cb" X-Rspamd-Queue-Id: 4MBQzR4xY0z3stm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=GaWN8yB3; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e29) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[current@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --0000000000006390d905e6db72cb Content-Type: text/plain; charset="UTF-8" On Mon, Aug 22, 2022 at 12:29 PM Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Mon, 22 Aug 2022, Warner Losh wrote: > > Hi, > > > On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov > > > wrote: > > > >> On Mon, Aug 22, 2022 at 02:56:47PM +0000, Bjoern A. Zeeb wrote: > >>> Hi, > >>> > >>> I am trying to get some arm64 up and running a bit but cannot use > >>> loader. I have an MD_ROOT embedded in the kernel with /rescue on it. > >>> I set INIT_PATH=/rescue/sh . > >>> > >>> However that doesn't seem to work: > >>> > >>> start_init: trying /rescue/sh > >>> init died (signal 0, exit 0) > >>> panic: Going nowhere without my init! > >>> > >>> Anyone any ideas? > >> > >> Kernel does not set up the standard file descriptors for stdin/out/err > >> for init. When you try to directly exec /rescue/sh (or /bin/sh), it > cannot > >> perform any io. > >> > > > > Agreed. init does lots of magic, in addition to setting up stdin/out/err > > (like > > deal with process groups, etc). /bin/sh doesn't do any of that magic, so > it > > can't possibly work as init (PID 1). > > > > Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=yes in > the > > boot loader). You'd think you'd be able to symbolically link /etc/rc to > > /rescue/sh, > > but that will result in sh trying to execute /rescue/sh as a shell script > > and no good > > can come from it. I've had luck with "echo sh > $DESTDIR/etc/rc; > > chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried that trick in > > ages... > > The simple equivalent to a tmp file does work. > > /rescue/init was simply "hanging" on earlier boots which is why I > had initially switche dto sh. > > Here's a few things I did overall: > - disable GDB in kernel config (it gave 2 lines of jitterish on > initial kernel printf lines before Copyrights. > - Added bootargs = FreeBSD:-vs to the chosen section in FDT > given I cannot have loader (no EFI); the guard trick is nice if you > know about it ;) > No EFI doesn't mean you can't have a loader :). What environment are you booting in? Seems interesting... > - Removed my previous env file I had added to the kernel to set > tunables. > - linked /bin/sh to /rescue/sh > - put a printf "hello world\n"; exit 1 in the top of /etc/rc just in > case -s wouldn't work > - changed INIT_PATH=/rescue/init > > Got a sh and can run sysctl and dmesg and type echo * in /rescue :) > Even reboot works :) > > Now that basic netbooting and user space work I can start adding SoC > drivers bit by bit over the next weeks/months :) That'll be a lot > more unfun. > > Thanks you two! Along with help from Andy earlier this made my day! > Glad I could help... Warner --0000000000006390d905e6db72cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 22, 2022 at 12:29 PM Bjoe= rn A. Zeeb <bzeeb-list= s@lists.zabbadoz.net> wrote:
On Mon, 22 Aug 2022, Warner Losh wrote:

Hi,

> On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov <kostikbel@gmail.com>
> wrote:
>
>> On Mon, Aug 22, 2022 at 02:56:47PM +0000, Bjoern A. Zeeb wrote: >>> Hi,
>>>
>>> I am trying to get some arm64 up and running a bit but cannot = use
>>> loader. I have an MD_ROOT embedded in the kernel with /rescue = on it.
>>> I set INIT_PATH=3D/rescue/sh .
>>>
>>> However that doesn't seem to work:
>>>
>>> start_init: trying /rescue/sh
>>> init died (signal 0, exit 0)
>>> panic: Going nowhere without my init!
>>>
>>> Anyone any ideas?
>>
>> Kernel does not set up the standard file descriptors for stdin/out= /err
>> for init.=C2=A0 When you try to directly exec /rescue/sh (or /bin/= sh), it cannot
>> perform any io.
>>
>
> Agreed. init does lots of magic, in addition to setting up stdin/out/e= rr
> (like
> deal with process groups, etc). /bin/sh doesn't do any of that mag= ic, so it
> can't possibly work as init (PID 1).
>
> Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=3Dyes= in the
> boot loader). You'd think you'd be able to symbolically link /= etc/rc to
> /rescue/sh,
> but that will result in sh trying to execute /rescue/sh as a shell scr= ipt
> and no good
> can come from it. I've had luck with "echo sh > $DESTDIR/e= tc/rc;
> chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried th= at trick in
> ages...
> The simple equivalent to a tmp file does work.

/rescue/init was simply "hanging" on earlier boots which is why I=
had initially switche dto sh.

Here's a few things I did overall:
- disable GDB in kernel config (it gave 2 lines of jitterish on
=C2=A0 =C2=A0initial kernel printf lines before Copyrights.
- Added bootargs =3D FreeBSD:-vs to the chosen section in FDT
=C2=A0 =C2=A0given I cannot have loader (no EFI); the guard trick is nice i= f you
=C2=A0 =C2=A0know about it ;)

No EFI do= esn't mean you can't have a loader :). What environment are you
booting in? Seems interesting...
=C2=A0
- Removed my previous env file I had added to the kernel to set
=C2=A0 =C2=A0tunables.
- linked /bin/sh to /rescue/sh
- put a printf "hello world\n"; exit 1 in the top of /etc/rc just= in
=C2=A0 =C2=A0case -s wouldn't work
- changed INIT_PATH=3D/rescue/init

Got a sh and can run sysctl and dmesg and type echo * in /rescue :)
Even reboot works :)

Now that basic netbooting and user space work I can start adding SoC
drivers bit by bit over the next weeks/months :)=C2=A0 That'll be a lot=
more unfun.

Thanks you two!=C2=A0 Along with help from Andy earlier this made my day!

Glad I could help...

Warner=C2=A0
--0000000000006390d905e6db72cb--