9front - general discussion about 9front
 help / color / mirror / Atom feed
From: "Jay F. Shachter" <jay@m5.chicago.il.us>
To: 9front@9front.org
Subject: [9front] "init: starting /bin/rc" repeats endlessly when I boot a computer installed from 9front-9931.amd64.iso
Date: Fri, 21 Jul 2023 00:23:13 -0500 (EDT)	[thread overview]
Message-ID: <16899169930.eD0eB387.99539@lsd.chicago.il.us> (raw)


Esteemed Colleagues:

When I boot my computer into a 9front system that I just installed
from 9front-9931.amd64.iso, it repeats "init: starting /bin/rc"
endlessly.  Is this a known problem?  Is there a known fix?

Specifically: I turn on the computer, wait for the GRUB menu to
appear, interrupt the countdown with "c", and then I type (because I
haven't created a menuentry for it yet):

   set root=(hd0,14)
   chainloader +1
   boot

I then see (what I assume are) the normal startup messages, beginning
with "pbs ........... ok" (I may not have the right number of periods,
it disappears quickly from the screen) and ending with (there may be
typographical errors, I am typing this by hand from the screen):

   /dev/sdE0/9fat   dos
   /dev/sdE0/data
   /dev/sdE0/dos    dos
   /dev/sdE0/fscache         cwfs64x
   /dev/sdE0/fsworm
   /dev/sdE0/linux
   /dev/sdE0/linux1          dos
   /dev/sdE0/linux2
   /dev/sdE0/linuxlvm
   /dev/sdE0/netbsd
   /dev/sdE0/ntfs
   /dev/sdE0/ntfs1
   /dev/sdE0/nvram
   /dev/sdE0/openbsd
   /dev/sdE0/other
   /dev/sdE0/plan9
   /dev/sdE0/sysv386
   /dev/sdE1: HL-DT-STDVD-ROM DU90N D100
   /dev/sdE2:
   /dev/sdE3:
   /dev/sdM0: MMC Host Controller
   /dev/sdM1: MMC Host Controller
   /dev/sdM2: MMC Host Controller
   bootargs is (tcp, tls, il, local!device)[local!/dev/sdE0/fscache]

with a blinking underline cursor two characters to the right of the
right square bracket.  I then type Enter to accept the default,
whereupon I see:

   user[glenda]:

again with a blinking underline cursor two characters to the right of
the right square bracket.  I type Enter again and then see:

   current fs is "main"
   10 uids read, 3 groups used
   63-bit cwfs as of Sun Jun 25 10:07:41 2023
           last boot Thu Jul 20 20:54:23 2023

   init: starting /bin/rc

   init: starting /bin/rc

   init: starting /bin/rc

   init: starting /bin/rc

   init: starting /bin/rc

   init: starting /bin/rc

repeated endlessly.

Prior to the installation, I used Linux fdisk to create, on an
MBR-partitioned disk, a logical slice within the extended partition
5 gigabytes in size, which is surely big enough for 9front, to which I
gave the 8-bit code 0x39, thus designating it as a Plan 9 disk slice.
The installation was then done by copying 9front-9931.amd64.iso to a
USB stick and sticking the USB stick into the computer and instructing
the BIOS to boot in Legacy mode from the USB device.  I answered the
preliminary questions by typing Enter and accepting the defaults, and
then when rio started up (I think that's the right word -- rio is the
windowing system, yes?) I invoked the inst command.  The installation
went entirely by the book, except that the installer did not ask me to
partition my disk, because it found a 5-gigabyte slice of disk (the
only one I have of that size, so I knew it was the right one) on which
to install.  The only times I asked for anything other than the
default were when I named the computer m5, and when I selected the
US_Central timezone.  I typed "no" when I was asked whether to install
bootcode on the MBR, but that was the default, I just wanted to say it
explicitly.  And the only other time I typed anything other than Enter
during the entire installation was when I typed w and q to accept the
default subpartitioning.

I would suspect an incomplete installation due to a hardware error,
because of events that I shall relate shortly, if not for the fact
that a hardware error is totally implausible.  I have a half-dozen
operating systems installed on this computer, and not one of them
misbehaves, or has ever misbehaved, or has ever given any evidence of
a hardware failure.

Nevertheless, my every attempt to install 9front has failed, except
for the one time it has succeeded, and as far as I know I did nothing
different then than I did on all the other occasions, both before and
since, when it has failed.  When it fails, which as I stated it has
always done -- both when I boot from a USB stick to which
9front-9931.amd64.iso has been copied, and when I boot from a CD to
which 9front-9931.amd64.iso has been copied -- except the one case
when it succeeded, it always fails in the same way.  I boot the
computer from the USB stick, or from the CD, I see a bunch of numbers,
I see other preliminary stuff like:

    cdboot=yes
    mouseport=ask
    monitor=ask
    vgasize=ask
    bootfile=/amd84/9pc64
    boot

I then see something being counted very quickly, then I see

    Plan 9

and then a bunch of other stuff that flies off the screen, culminating
in the list of devices that you saw earlier, and then:

    bootargs is (tcp, tls, il, local!device)[local!/dev/sdE1/data]

with the same blinking underline cursor that was described earlier.  I
type Enter to accept the default, I then see:

    user[glenda]:

with the blinking underline described earlier, and when I type Enter
again to accept the default, there is a pause of a few seconds, and
then it says

    mount: mount root: I/O read error
    mount /srv/boot /root: mount 2156: mount

and then the list of devices (maybe preceded by other stuff that
quickly flew off the screen), and then the same

    bootargs is (tcp, tls, il, local!device)[local!/dev/sdE1/data]

prompt as before, and this time there is no "user[glenda]:" prompt
when I type Enter, it returns -- for as many times as I repeat the
procedure -- to the several-second pause, and then to the

    mount: mount root: I/O read error
    mount /srv/boot /root: mount 2156: mount

message as before, except that the number is different, it keeps on
going up.

So, how do I successfully run my already-installed 9front system?  Or,
if I must reinstall it, how do I do that?  I grant that it certainly
looks like a hardware error -- especially since an installation
procedure that usually fails did succeed once, maybe when the hardware
was well-rested and feeling healthy -- but, as I said, this computer
has never shown any evidence of any hardware error, even the smallest.
I would welcome any answer to this question, and I thank you in
advance for any and all replies.

	Jay F. Shachter
	6424 North Whipple Street
	Chicago IL  60645-4111
		(1-773)7613784   landline
		(1-410)9964737   GoogleVoice
                http://m5.chicago.il.us
		jay@m5.chicago.il.us

	"But when she traced the killer's IP address ... it was in the 192.168/16 block!"


             reply	other threads:[~2023-07-21  5:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-21  5:23 Jay F. Shachter [this message]
2023-07-21  7:50 ` qwx
2023-07-21 15:11   ` Jay F. Shachter
2023-07-21 15:20     ` Jacob Moody
2023-07-21 15:30     ` Dave Woodman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16899169930.eD0eB387.99539@lsd.chicago.il.us \
    --to=jay@m5.chicago.il.us \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).