From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 9 Jul 2014 17:55:08 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <4746421b5d0b3f6493c796728bc718dc@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Revo L80 Topicbox-Message-UUID: 0260a94e-ead9-11e9-9d60-3106f5b1d025 On Wed Jul 9 16:10:16 EDT 2014, riddler876@gmail.com wrote: > I've been looking into it a bit more today. It actually seems to be quite stuck. > > I get as far as the 'live usb' boot, with glenda, rio, acme etc > starting up. The "plan 9 install" screen and its live log are there. > While working through the install the only disk appears to be > /dev/sdu0. This is ~4GB in size and is the USB stick. > The PC HDD does not seem the be listed in /dev; there is however a > /dev/sdU0, but this seems to be a duplicate of /dev/sdu0 (based on ls > -l showing the exact same size and the PC HDD should be much bigger > than 4GB). sdU0.0 is provided directly by usb/disk. usb/disk does not do partitioning, so it is remounted with the sd loopback driver (sdloop(3)). this is what you see as sdu0. the pc hard drive would be listed as /dev/sdE? where ? in [0..f], assuming that your machine uses ahci. the output of /dev/sdctl would be useful, otherwise you can use sos/sos (see sos(8)). > Took a look at /dev/kmesg and there is only only three lines that look > relevant that I've put in at the end of this email. I can attach more > of it if required. > > I attempted running sos/sos but some files appear to be missing. It > says it can not find bin/aux/cpuid, bin/aux/dmi, bin/bzip2. > The /tmp/sos.mkfs.bz2 file is created, but empty. i wonder if the fact that syscall(1) was broken by the nsec thing caused fewer programs to be built than normal. this is fixed in the current image. i would recommend doing the following @{cd /sys/src/cmd/aux; mk install} @{cd /sys/src/cmd/bzip2; mk install} and running sos again. really want you're interested in is the full output of /dev/kmesg, and /dev/sdctl. > I suspect it's more likely I've unknowingly missed a step somewhere > rather than the bin directory is actually missing files. > > ----/dev/kmesg output snippet---- > #A0: hda; mem fffffe00f7e30000 irq 4 > #A0: hda: coded #0, vendor 10ec0662, rev 00100300 > #A0: hda: coded #c, vendor 80862806, rev 00100000 > > Any help appreciated! this is cool, and expected. - erik