[9fans] 9atom usb image

[9fans] 9atom usb image

[erik quanstrom]

i think it's time to get rid of the +usbinstamd64.bz image.  the
process seems to work pretty well.  updates to the image will be
here starting immediately:

	http://ftp.9atom.org/other/usbinstamd64.bz2

- erik

Re: [9fans] 9atom usb image

[Adriano Verardo]

erik quanstrom ha scritto:
> i think it's time to get rid of the +usbinstamd64.bz image.  the
> process seems to work pretty well.  updates to the image will be
> here starting immediately:
>
> 	http://ftp.9atom.org/other/usbinstamd64.bz2
>
> - erik
>
>
This image behaves as follows:
...
8._cp 8.unicode /386/bin/unicode
8._cp 8.tweak /386/bin/tweak
8._cp 8.uniq /386/bin/uniq
8^c -FTVw units.c
8._cp 8.unmount /386/bin/unmount
8._cp 8.webfsget /386/bin/webfsget
8._cp 8.wc /386/bin/wc
8._cp 8.winwatch /386/bin/winwatch
8._cp 8.webcookies /386/bin/webcookies
8._cp 8.xb /386/bin/xb
8._cp 8.wsprint /386/bin/wsprint
8._cp 8.xd /386/bin/xd
8._cp 8.μlawdec /386/bin/μlawdec
8._cp 8.yacc /386/bin/yacc
8._cp 8.bc /386/bin/bc
8^l  -o 8.units units.8
8._cp 8.units /386/bin/units
for(i in 1a 1c 1l 2a 2c 2l 5a 5c 5i 5l 6a 6c 6l 7a 7c 7l 8a 8c 8l 
9660srv 9a 9c 9l 9nfs abaco acid acme aoedbfs aoesnap aquarela astro 
atazz auth aux awk bitsy bzip2 cb cc cdfs cec cfs cifs compose compress 
con cpp cwfs db dial dict diff disk dossrv eqn execnet exifsrv exportfs 
ext2srv faces fax fossil grap graph grep gs gzip hoc htmlfmt htmlroff 
icrop imgloop iostats ip jpg jtag ka kc ki kl lex lnfs lp map mk ndb opc 
page paqfs pci pic plot plumb postscript proof qa qc qi ql ratfs rbfs rc 
rchistory replica rio runetype sam samterm scat scuzz sftpfs snap spell 
spin srvold9p ssh1 ssh2 syscall tapefs tarsplit tbl tcs telco troff 
troff2html upas usb va vac vblade vc venti vi vl vnc vt webfs wikifs 
θfs) @{
     cd $i
     echo mk $i
     mk $MKFLAGS install
}
mk 1a
yacc -D1 -d a.y
8c -FTVw y.tab.c
8c -FTVw lex.c
8l  -o 8.out y.tab.8 lex.8
cp 8.out /386/bin/1a
cp: error writing /386/bin/1a: file system full
mk: cp 8.out /386/bin/1a  : exit status=rc 8787: cp 8789: errors
mk: for(i in 1a ...  : exit status=rc 8769: rc 8771: mk 8774: error
mk: test -e 8._cp ...  : exit status=rc 7466: mk 8757: error
mk: date for (i ...  : exit status=rc 416: rc 7452: mk 7454: error
halt system? (yes, no, skip)[no default]:

---------------------------

; disk/kfscmd check
checking file system: main
check free list
lo = 0; hi = 0
    21694 files
    48616 blocks in the file system
    48616 used blocks
        0 free blocks
    21703 maximum qid path

---------------------------

; disk/kfscmd -n inst check
checking file system: main
check free list
lo = 50580; hi = 61035199
    23209 files
61035199 blocks in the file system
    50579 used blocks
60984620 free blocks
    23415 maximum qid path
;

The fresh key have about 3000 free blocks.

adriano

Re: [9fans] 9atom usb image

[erik quanstrom]

thanks, i'll look into this.

- erik

Re: [9fans] 9atom usb image

[David Hoskin]

Here's a procedure that worked for me.

- download new usbinstamd64.bz2 from 9atom.org
- boot it up, run through the installer
- answer no to ``build full amd64 set?''
- answer no to ``halt system?''
- mount new disk's 9fat and copy over /386/9paed
- edit plan9.ini to boot 9paed

This will boot up just fine in 386/pae.

>From there, you can build amd64 on the host system.

-- David

Re: [9fans] 9atom usb image

[erik quanstrom]

On Thu Mar 27 16:50:18 EDT 2014, root@davidrhoskin.com wrote:
> Here's a procedure that worked for me.
>
> - download new usbinstamd64.bz2 from 9atom.org
> - boot it up, run through the installer
> - answer no to ``build full amd64 set?''
> - answer no to ``halt system?''
> - mount new disk's 9fat and copy over /386/9paed
> - edit plan9.ini to boot 9paed
>
> This will boot up just fine in 386/pae.
>
>  From there, you can build amd64 on the host system.

there is something odd here.

where do the 386 executables come from?  they're not on the usb key.

it's also hard to explain that the usb key 64-bit kernel works just fine,
but doesn't (i happen to know) appear to boot from your hard drive.

- erik

Re: [9fans] 9atom usb image

[David Hoskin]

> there is something odd here.

I agree.

>  where do the 386 executables come from?  they're not on the usb key.

It has some in /386/bin.

> it's also hard to explain that the usb key 64-bit kernel works just fine,
but doesn't (i happen to know) appear to boot from your hard drive.

The usb key's amd64 kernel doesn't boot on my machine; I have to use
the 386pae option in the key's boot menu.

-- David

Re: [9fans] 9atom usb image

[Matthew Bonner]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

On 28 March 2014 07:49, David Hoskin <root@davidrhoskin.com> wrote:

> Here's a procedure that worked for me.
>
> - download new usbinstamd64.bz2 from 9atom.org
> - boot it up, run through the installer
> - answer no to ``build full amd64 set?''
> - answer no to ``halt system?''
> - mount new disk's 9fat and copy over /386/9paed
> - edit plan9.ini to boot 9paed


The first four steps is exactly how I installed 9atom. My edit to plan9.ini
added bootargs, mouseport, removed user=

Then a reboot and 'mk install' in /sys/src/ resulted in a working amd64
system for me.

One issue is networking - to successfully get a dhcp lease I have to use
generic dhcp options ( ip/ipconfig -G ) That could be a specific quirk to
my network.

Cheers,

Matthew

[-- Attachment #2: Type: text/html, Size: 1244 bytes --]

Re: [9fans] 9atom usb image

[Adriano Verardo]

erik quanstrom ha scritto:
> thanks, i'll look into this.
>
> - erik
>
As i wrote in a previous mail,  I tried this procedure:
(pcbox is a working Atom/fossil, using the key to install on dell1).

download usbinstamd64.bz2, load the usb key
pcbox% usbsd
pcbox% disk/kfs -f /dev/sdu0/fs
pcbox% mount /srv/kfs /n/k
pcbox% du -a /n/k > /tmp/du_before
pcbox% disk/kfscmd check    # Only one kfs on pcbox
   ...
   ...   3005 free blocks
...
pcbox%

unmount the key from pcbox, use it to install dell1 ...
when the compilation stops, remove the key from dell1 and re-mount it
on pcbox

pcbox% usbsd
pcbox% disk/kfs -f /dev/sdu0/fs
pcbox% mount /srv/kfs /n/k
pcbox% du -a /n/k > /tmp/du_after
pcbox% disk/kfscmd check
   ...
   ...   0 free blocks
   ...
pcbox%
pcbox% wc /tmp/du_before /tmp/du_after
pcbox% diff /tmp/du_before /tmp/du_after

Looking at the diff output it seems that the compiled executables
are installed on the key instead of the target hdd.

This makes me think to a damned typo in a "bind" somewhere.

adriano