* [9front]
@ 2025-01-19 22:42 sl
0 siblings, 0 replies; 45+ messages in thread
From: sl @ 2025-01-19 22:42 UTC (permalink / raw)
To: 9front
9FRONT "THIS TIME DEFINITELY" RELEASED
======================================

NOTABLE CHANGES
---------------
In this release:
- New file system gefs(4) now enabled in the installer.
- CVE-2024-8158 fixed.
- ip/ipconfig now support dhcpv6 dynaic allocations and handles prefix expirations
DOWNLOAD
--------
Multiple installation media are provided for PC, Raspberry Pi, MNT
Reform, and QEMU. For PC, burn an .iso file to CD, or dd it directly
to USB media. For Raspberry Pi or MNT Reform, dd an .img file
directly to sdcard.
The pi.img file can be used for Raspberry Pi 1, 2, and 3. The pi3.img
file can be used for Raspberry Pi 3 and 4.
QEMU images are provided in QCOW2 format.
<http://iso.only9fans.com/release/9front-10931.386.iso.gz.torrent>
<http://iso.only9fans.com/release/9front-10931.amd64.iso.gz.torrent>
<http://iso.only9fans.com/release/9front-10931.amd64.qcow2.gz.torrent>
<http://iso.only9fans.com/release/9front-10931.arm64.qcow2.gz.torrent>
<http://iso.only9fans.com/releases/9front-10931.honeycomb.img.gz.torrent>
<http://iso.only9fans.com/release/9front-10931.pi.img.gz.torrent>
<http://iso.only9fans.com/release/9front-10931.pi3.img.gz.torrent>
<http://iso.only9fans.com/release/9front-10931.reform.img.gz.torrent>
; sha1sum -2 256 9front-*
6a3228b26726843e8f0f0367499aa9a2371e7877165b39f8a1f1313312e7a6cc 9front-10931.386.iso.gz
1c517c91f53b47cd9cf45ef781ad35eb6ece4d3b0aebb46c6a361a87cacace66 9front-10931.386.iso.gz.torrent
de873b02a5235940dc6e671c8f0b9d8ef42c524c59917fa97c1d921f8c37d49e 9front-10931.amd64.iso.gz
48927d8d1ff8d108e4abfec5d4b336737039aad1ab26e9dfb63374fb507f93d8 9front-10931.amd64.iso.gz.torrent
25dedc64d29e78519abfcedece647020d3bcae57a9e26fb2d658edca6bb1b6dc 9front-10931.amd64.qcow2.gz
1dc6a1956174f8992e1a2d85ccc2df6e319ce913f242c3cc0b928d071e8f9d68 9front-10931.amd64.qcow2.gz.torrent
36df268aba76b5c97e71ab55782d749692d79742954794731f66bd1925c321c1 9front-10931.arm64.qcow2.gz
88f8470d9404823b1f233257c15ce8e649f27a81f7f70c9adf9b4c770fe41730 9front-10931.arm64.qcow2.gz.torrent
be35cf3c79568e0ea4ef0cac5a6d4904055160befde491faf4d4028aa2fbdd49 9front-10931.honeycomb.img.gz
b2df6fc0fdb5a32c514e2dd1a440dc99c33af606afedbb2985590155c749cd3e 9front-10931.honeycomb.img.gz.torrent
752595241c8b2cc40b33b131ea425339c47cd7faa05258bc7f79d89bc510c656 9front-10931.pi.img.gz
9ff792fd5a4b1c8aa76ba712ef4c0a1fb725f848a0f426eefaf48d4a38ea80d9 9front-10931.pi.img.gz.torrent
d16fef44970a3f1e7c7242ec1ec496627df9fe346ef500bc2812c675dcf1f3bc 9front-10931.pi3.img.gz
0b5ea23a88dba547faa23c6eba69dd6e95279a3768e01721cff740f7f8a77fef 9front-10931.pi3.img.gz.torrent
54fc90bd833b05746eae9afc05c92f989d1ebe28810d0156bbf08f9dbfecbc6f 9front-10931.reform.img.gz
922a5712c6852ae59ec6fae71ef8161dc80323c0941086afebe80d629c96db2a 9front-10931.reform.img.gz.torrent
MIRRORS
-------
<https://9front.org/iso/>
<https://iso.only9fans.com/release/>
GIT REPOSITORY
--------------
<http://git.9front.org/plan9front/plan9front/HEAD/info.html>
DASH 1 MANUAL
-------------
<http://fqa.9front.org/dash1.thistimedefinitely.pdf>
dash 1 manual: <http://9front.org/propaganda/books>
SONGS
-----
by qwx
<http://9front.org/mp3/retrospective.r03.flac>
by cinap_lenrek
<http://9front.org/mp3/nexttime2.mp3>
THANKS
------
The MITRE Corporation
KERNEL AND DRIVERS
------------------
9boot: add honeycomb
audiohda: add vid/did for Intel Tiger Lake
boot/net.rc: redirect grep error to /dev/null
devether: Fix memory leaks in ifstat reads
devether: don't print link-status until netif is initialized
devether: handle input queue size for bypass mode
devether: make link status prints consistent
devether: print mbps only on link-up
devether: provide ethersetspeed() function to adjust queue sizes
devfloppy: fix unreachable code warning after cmderror()
devip: Fix bugus RouteHint* pointer to be passed to ipoput4()
devip: allow (NAT) hole punching for ICMP and UDP
devip: correctly return when allocating an ipmedium slot
devip: do not raise error from ipoput*()
devip: don't send and ignore MLD messages for invalid multicast groups
devip: dont shoot the messenger (dont unbind the interface when ipipu4/ipiput6 errors)
devip: fix masks in ipmux filters
devip: increase MTU to 64k for loopback medium
devip: make "null" medium bindable
devip: panic if we exceed the number of media entries (thanks k0ga)
devsegment: don't use ulong as negative index
devuart: Fix memory leak when reading status file
devusb: prevent double-detach and other invalid state changes
devusb: better usbid allocation, fix locking, remove dump ctl
devusb: destruct usb tree from the leaves, split epclose() into epstop()/epclose()
devusb: fix TT properties, checking, and bugs
devusb: fix enable delays to avoid device suspend (thanks cgnarne)
devusb: handle root-port reset delays outside of hci driver, rootport power control
ether2114x: fix automatic media detection
ether8169: add pci id for RTL8111/8168/8411 (thanks Sylvie)
etherimx: fix missing barrier for doorbell (thanks sigrid)
etheriwl: add support for 3168
ethervgbe: implement proper speed and link detection
ipmux: implement hangup ctl
kernel: Limit parsecmd() to a maximum of READSTR bytes
kernel: add honeycomb kernel
kernel: add imx8, lx2k and mt7688 to kernel ARCH list
kernel: allocb: implement buffer pools for ethernet drivers
kernel: avoid recursive lockloop() prints from screenputs() (thanks noam)
kernel: hack processor affinity to allow load sharing
kernel: improve nlocks print in sleep()
kernel: make cmderror() _Noreturn
kernel: make fixedpri work.
kernel: make schedinit() _Noreturn void
kernel: only reset processor affinity p->mp when p->wired == nil
kernel: remove global balancetime variable -> make function static
kernel: remove unused cruft: delaylink, normalprint
kernel: remove unused lockstats and make lock() return type void
kernel: reorganize bootfs.paq generation
kernel: sched() should not imply spllo()
kernel: use flag and integer to handle affinity
kprof: don't downsample the pc
netif: fix potential memory leak in netifwstat()
netif: simplify locking and cleanup
nusb/*: improve usbd to handle transaction translater properties correctly
nusb/audio: don't add a control if getvalues errored
nusb/audio: fix wrong emallocz() call in getclockrange()
nusb/audio: use correct buffer size for d2h requests, else some devices stalls
nusb/disk: kill 9p procs before sysfatal(), devctl() before opendevdata()
nusb/ether: Don't pass ethernet fcs to the network stack for smsc and lan78xx
nusb/joy: support xbox360 controllers
nusb/lib: decode classcode() 0xFF -> vendor, 0xFE -> application (-specific)
nusb/lib: decode more base class codes in classname()
nusb/usbd: impelement warm-reset for usb3 ports, attempt port reset on failed hubs, enable port-power for rootports
nusb/usbd: improve debugging, dont portfail() when port attaches/detaches too fast, cleanup
nusb/usbd: make it less noisy: fprint() -> dprint()
nusb/usbd: use longer reset delay for rootports
nusb/usbd: maintain hublist order with rootports first
nusbrc: add Prolific and CP2102 serial uart
nusbrc: pass $usbdebug to nusb/usbd
nusbrc: support the pine64 UART
pc: Remove unused lm78 driver
pc, pc64: refactor pcibios code so we dont pollute the amd64 kernel
pc64: remove reference to stale conf
pci: make sure MSI-X is off before enabling and disabling MSI
sdodin: fix set but not used warning
sdaoe: remove unfinished atapi code (thanks arne)
usbdwc: preserve Prtpwr bit for portstatus, turn off power by default, handle channel timeout
usbehci: implement portpower control for rootports
usbuhci, usbehci: remove portlck qlock
usbxhci: preserve RsvdP bits in registers, print recovery reason, print base address.
wifi: don't try to associate when bypassed
COMPILERS, LINKERS, DEBUGGERS
-----------------------------
/sys/lib/acid: add power64
/sys/src/cmd: ?[cl] mkfile consistency
2c: fix indirect calls
6l: relocate operands with REX correctly
8[al]: support CMPXCHG and CMPXCHG8B
8[al]: support XADD
9[acl], libmach: L?AR/ST?CCC
9[acl], libmach: LWSYNC/CMPW/CMPWU
9a, 9c, 9l: import from 9legacy
9a: mkfile was pointing to wrong header
9c/9l/libmach: handle 64 bit constants
9c/9l: do not have the linker rewrite OSUB to negative OADD
9c: allow switches on 64bit values
9c: avoid generating immediates that make the linker use REGTMP
9c: copy warning from other compilers regarding pointer -> int truncation
9c: mind which CMP is used when handling constants
9l: add -H6 for elf targeting kexec
9l: do consize check for SB relative as well
9l: fix ELF generation
acid: remove outdated 8.out binary default (thanks Tekk)
cc: dont' try compiling invalid code
cc: logical operations (& | ^) operate on integers only (thanks sigrid)
cpp: implement empty arg handling for function-like macros (thanks rod)
cpp: remove stray line from tests
flambe: flame graphs for prof(1) data
flambe: pass correct name to initdraw()
flambe: right click to plumb functions
leak: properly sign-extend kernel callerpc for arm64
prof: increase precision of measurements
LIBRARIES
---------
lib9p: add "authok" flag to Srv struct
lib9p: verify uname against returned AuthInfo from factotum (thanks humm)
libc/libap: update power64 entrypoints to new _callmain standard
libc/runeistype: accept out of range runes
libc/runeistype: out of range is only > Runemax, Rune is a uint
libc: cleanup hangup() function (avoid duplicated literal string)
libc: compress directly recursive functions while profiling
libc: increase default allocation for profiling
libc: provide netmkaddrbuf() function avoiding the static buffer
libc: refactor va_arg in u.h to fix warnings for power64
lib*: cleanup power64 assembly
lib*: power64 target
libdraw: fix bytesperline() for negative coordinates (thanks qwx)
libdisk: cleanname() paths for setname()/mkpath(), avoid utfrrune()
libframe: always draw tick with current TEXT color.
libgeometry: add lineXsphere function
libgeometry: add ptincylinder and ptincone
libgeometry: add quaternion sandwich product functions
libgeometry: simplify rframes
libmach: clean up power64 tests
libmach: power64 catch up
libmach: power64 vector mov and cleanup
libmach: remove unused 6c subdirectory
libmp: remove stale test file
libmp: sidestep git bug for now
libmp/convtest: fix format string type warning uint -> %ud and remove unused variables
libpcm: fix buggy use of clip macro (evaluates its arg twice)
limbach: remove unused 9c subdirectory
libmemdraw: change openmemsubfont() to accept rune minimum as argument
PROGRAMS
--------
acme, abaco: render scrollbar like rio
ape/diff: one more ancient, unmaintained, buggy gnu utility gone
ape/patch: also kill ape/patch
audio/zuke: icy: use http 1.1, specify host, follow redirects
auth/as: dont pollute parents environment or namespace (thanks jrmu, sl)
auth/factotum: add support for TOTP code generation
auth/factotum: avoid static buffer from netmkaddr()
auth/factotum: mount factotum onto /mnt/factotum instead of /mnt by default
auth/userpasswd: remove factotum-bug work-around from 2002, cruft (thanks ori)
aux/cddb: fix artist line splitting
aux/cddb: support very long artist+album name combos
aux/listen: remove namespace from procsetname.
aux/mnihongo: formatting
aux/mnihongo: use memdraw instead of draw
cpiofs: add newc support for cpiofs (thanks rminnich)
cpurc, termrc: dont kill gefs
cpurc: use ndb/query -cia instead of ndb/ipquery
doctype: fix custom options (thanks sirjofri)
eqn: fix silly mkfile
fontsel: fix text buffer oob and crash due to insufficient stack size after IOUNIT change
g: add .in, fix earlier fuckup (thanks mkf)
g: add cxx and hxx
gefs: acquire mutation lock around ORCLOSE upsert
gefs: add command to show free ranges on console
gefs: add lock assertion for paranoia
gefs: allow halting read-only file system
gefs: avoid holding the wrlock when syncing the file system
gefs: bring back write cancellation for free blocks.
gefs: change log compression heuristic
gefs: check name lengths before packing them
gefs: clean up blk logging code
gefs: clunk dent and mnt when dropping rclose message
gefs: convert to atomic instructions
gefs: copy mode down on create, don't truncate walks with no DMEXEC
gefs: correct in-memory directory length for DMAPPEND files (thanks cinap)
gefs: correct mode check for other group
gefs: correctly serialize updates to mounts
gefs: correctly set duid/dgid on Tcreate
gefs: don't abort when the fs breaks
gefs: dump dirs are dirs too
gefs: dump set of directory entry attributes
gefs: fix Fid refcounting bugs
gefs: fix allocation log compression
gefs: fix block leak when merging tree nodes
gefs: fix deadlock between epochclean and truncwait
gefs: fix dlist cache limit by maintaining fs->dlcount
gefs: fix error handling in readsnap()
gefs: fix fidtab locking order in clunkfid()
gefs: fix file truncation performance (thanks cinap)
gefs: fix memory leak on nop syncs
gefs: fix use after free in putconn()
gefs: fix waserror() bugs
gefs: flush limbo lists on halt
gefs: getblk(): remove duplicate getcallerpc(), check b->bp.gen from cache
gefs: improve 'print fid' on cons
gefs: improve flow of blocks/frees
gefs: improve heuristic for arena selection
gefs: initial import
gefs: make dent cache per-mount
gefs: make it impossible for clunkfid to error
gefs: modifying a directory should update qid.vers
gefs: more/stricter asserts and checks
gefs: only allow 'none' attach when previously authenticated
gefs: only start epochs for console procs that need them
gefs: properly close and free connections
gefs: protect fids with rwlock
gefs: remove daed mkfile bits
gefs: remove nokill code
gefs: remove trace noise
gefs: remove unused blk field
gefs: remove useless cachedel
gefs: remove vestigial bucket lock
gefs: revert cacheflag()
gefs: set gid correctly when creating directory entries
gefs: set super dir in Qadm correctly
gefs: skip writeback on data blocks
gefs: temporarily disable log compression
gefs: tweak block address heuristic to sequentialize allocation
gefs: use a single syncer proc to flush to disk
gefs: use broke() when we get a corrupt block
gefs: use correct snap name with autosnaps
gefs: use freeblk() instead of freebp() when we already have the block
gefs: we need an agetv for the qgen on 32 bit systems
gefs: weaken overzealous assert
gefs: work around 8c bug
git/branch: change '-d' flag to '-r' flag for consistency
git/branch: handle dirents changing between file and dir correctly (thanks cinap)
git/branch: make it more robust
git/branch: missed changing a var name
git/clone: allow cloning into an empty directory
git/commit: filter to changed files for git/save
git/diff: fix -c flag
git/export: don't try to diff dirs
git/fs: don't allow walking blobs
git/get: support side-band and multi-ack
git/pull: fix typo
git/pull: only show commit summary after updating branches
git/query: process full contents of queue, even with skips
git/query: use git entry sorting when computing dir diff
git/save: and try again...
git/save: fix the "noam" bug
git/save: handle all cases correctly when walking args
git/save: sort argv lexicographically
git/serve: we don't do thin packs -- advertise it.
git/test: add noam.rc testcase
git/test: improve ftype test (also test dir -> file transition)
git/test: run tests with a temporary install bound to /bin/git
git/walk: dirs should not count as tracked
git: allow longer authors in commits
git: bikeshed git/walk relative path calculation and add tests
git: fix off by one in strncmp
git: make git/diff -s print relative file paths
git: make tests less verbose
git: provide symref extension
git: refactor capability parsing
git: rewrite entcmp to be single pass, less stupid
gs: don't track autogenerated header (thanks James)
gs: ignore more autogenerated headers
history: add support for gefs dumps
hjfs: check mount spec (aname) in Tauth
hjfs: implement "none" attaches properly
htmlroff: fix tcs pipe leak
inst: make gefs visible in the installer
inst: add hidden 'gefs' file system type option
inst: add option to use esp as 9fat
inst: adjust phrasing on file system state/usecases
ip/*: sprint() -> snprint() in a bunch of old copy-pasted network announce routines.
ip/dhcpd: don't get confused by ipv6 addresses for bootp Info
ip/dhcpd: impvoe validip(), make validipmask() reject ipv6 masks
ip/ipconfig: add "null" verb to bind nullmedium
ip/ipconfig: ask devip to delete expired ipv6 prefixes (thanks arne)
ip/ipconfig: don't use sprint() when we have variable strings.
ip/ipconfig: fix logic bug (thanks cgnarne)
ip/ipconfig: handle dhcpv6 IA options, pass gateway from RA
ip/ipconfig: implement dhcpv6 prefix delegation, dynamic client
ip/ipconfig: make ra limiter less agressive (thanks cgnarne)
ip/ipconfig: ndbvalfmt() strings when formatting ndb entries.
ip/ipconfig: only write out /net/ndb when something changed
ip/ipconfig: ... but unconditionally refresh when adding addresses manually (thanks chilledfrogs)
ip/ipconfig: properly handle ipv6 address deprecations
ip/ppp: rc-quote ipnet value, to prevent accidents.
ip/ppp: pass -i flag to ip/ipconfig (-i for ipv4, -I for ipv6) to populate ipnet= entries
ip/pppoe: properly zero-pad ethernet frames, optimize framing, limit mtu
ip/tftpd: accept an address to announce to as an argument.
ip/torrent: fix webseed
ip/torrent: fix wrong interval check
ip/torrent: support compact peers6 list
ip/traceroute: sprint() -> snprint()
jpg/tga: decode TGA32 images into RGBA32 ones
kbdfs: consult also escaped scancode table when decoding runes (thanks aap)
look: fix case sensitivity when using base > 10
man: also attempt to interpret argument as path
mkfiles: check for test/mkfile when recursing
mkfiles: stop cargo culting UPDATE=
Mail: Add support for message filtering
Mail: correct message line number for partially hidden threads
Mail: don't move cursor when flags are unchanged
Mail: fix redrawn line offsets, add support for flag filters
Mail: provide runnable command to view html
ndb/dns: don't refuse queries when delegated subareas
ndb/dns: refuse recursive requests harder when given -R (thanks be0ba)
patch: fix not applying each input patch file atomically
patch: show expected line number for hunk when rejecting it
pstree: reimplement in awk, optionally restrict to a given process
pstree: remove unnecessary globbing and environment pollution (thanks cgnarne, cinap_lenrek)
qcowfs: add 9p debug flag
rx: add ssh
sam: M: don't require a current file to operate (thanks umbraticus)
sam: introduce a new command M for adding commands to mouse b2 menu
sam: make X/.../b work
sam, samterm: rfork to copy env vars and namespace
samterm: avoid division-by-zero when $tabstop is zero or empty
samterm: make right arrow move to the right of dot (thanks llamaa)
spin: make generated code match installed headers
sshnet: update usage text to match man page
stats: add etherovf value (hw and software overflows on input queue)
tar: use IOUNIT to compute Dblock
telnetd: fix getremote()
timezones: Add Indonesia (thanks AlfredPros)
units: accept negative numbers
upas/smtp: add -C flag to disable thumbprint verification (thanks sirjofri)
vcrop - graphical image cropping tool
vcrop: fix image panning
vdiff: accept diff as filename argument and man page touch-up (thanks humm)
vdiff: exit if diff is empty
vdiff: fix scrolling and mouse button handling.
vdiff: show filename instead of "/dev/null" when removing entire file
vt: skip over vertical line marks (Contour terminal)
walk: error on mutually exclusive flags
walk: fix skipped files, simplify seen()
walk: qid.vers should be ignored (thanks BurnZeZ)
walk: show siblings with the same qid
DOCUMENTATION
-------------
/sys/doc/fs: don't make fs.html by default
/sys/doc: add mk clean
/sys/doc: remove generated files
2c(1): add 9c
2l(1): add 7l and 9l
9p(2): typos
bio(2): fix formatting
dhcpd(8): typos
factotum(4): minor typo
gefs(8): docment user creation commands
gefs(8): fix indent of empty snapshot paragraph
gefs(8): say some words about snapshots
gefs(8): small formatting fixes (thanks kvik)
gefs.ms: add gefs to /sys/doc/mkfile
gefs.ms: Minor fixes and improvements.
gefs.ms: sycer => syncer (thanks sigrid)
geometry(2): correct typo (thanks ndeuteron!)
geometry(2): fix little typo
ipconfig(8): document loopback and null media
ipconfig(8): fix /net/null vs /dev/null (thanks humm)
isalpharune(2): invalid Runes are just > Runemax
ip(3): ra6 routerlt is in seconds, not ms.
mp(2): typos (thanks sirjofri)
plan9.ini(8): document the existence of git.9front.org/plan9front/firmware (thanks, orib)
rio(1), rio(4): wctl /srv pipe is dead, mention 'none' attach (thanks unobe)
rio(4): fix paragraph spacing (thanks humm)
riow(1): mention having to put the rc pipeline into its own script
sam(1): ^ does not take any range
sshnet(4): fix title (thanks arne)
tmdate(2): fix formatting for sub-second specifiers
tmdate(2): fix two little typos in the examples
totp(1): fix example for adding totp key to factotum
totp(1): separate docs for auth/totp, auth/userpasswd
upasfs(4): make the name match the executable path
users(6): it's not just older servers
webfs(4): typo around connection close (thanks halfwit)
OTHER
-----
/lib/1oct1993: add troff files.
/lib/1oct1993: replace text file with directory of troff source files.
/lib/rsc: Please always feel free to continue to reach out whenever you need anything.
/lib/theo: If we can't do it right, we don't do it until we figure out a way to do it right.
/lib/theo: This thread is too long. Please just stop.
/sys/games/lib/fortunes: redaction day
/sys/lib/dist/ndb/common: add git and gits
/sys/lib/dist/ndb/common: add hjgit port, remove unused
/sys/src/cmd/test: enable zones.rc test (thanks unobe)
mkmany: check more carefully for test folder

^ permalink raw reply [flat|nested] 45+ messages in thread
* [9front]
2024-05-22 9:43 ` sirjofri
@ 2024-05-22 12:07 ` Tomás Ciccola
0 siblings, 0 replies; 45+ messages in thread
From: Tomás Ciccola @ 2024-05-22 12:07 UTC (permalink / raw)
To: 9front
unsubscribe
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-06-22 12:28 [9front] roy niang
@ 2022-06-22 12:32 ` stefncb
0 siblings, 0 replies; 45+ messages in thread
From: stefncb @ 2022-06-22 12:32 UTC (permalink / raw)
To: 9front
Quoth roy niang <roy@royniang.com>:
> unsubscribe
You send that at 9front-owner@9front.org :)
^ permalink raw reply [flat|nested] 45+ messages in thread
* [9front]
@ 2022-06-22 12:28 roy niang
2022-06-22 12:32 ` [9front] stefncb
0 siblings, 1 reply; 45+ messages in thread
From: roy niang @ 2022-06-22 12:28 UTC (permalink / raw)
To: 9front
unsubscribe
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 14:59 ` [9front] thinktankworkspaces
2022-01-12 16:56 ` [9front] hiro
@ 2022-01-14 11:45 ` cinap_lenrek
1 sibling, 0 replies; 45+ messages in thread
From: cinap_lenrek @ 2022-01-14 11:45 UTC (permalink / raw)
To: 9front
it is supporting the multiboot standard.
any multiboot capable bootloader (grub, coreboot, qemu,
syslinux, linux kexec) can start our kernel file directly,
the plan9.ini is (optionally) passed as a "module"
(like initrd).
this is done by having a second entry point in the kernel
dedicated for multiboot, which also handles things like
getting the framebuffer configuration and memory map from
multiboot parameters and converting them into internal
plan9.ini format.
9boot and /dev/reboot (yes, you can start a plan9 kernel
from a plan9 kernel) enter the kernel thru the classical
a.out entry point.
--
cinap
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 14:59 ` [9front] thinktankworkspaces
@ 2022-01-12 16:56 ` hiro
2022-01-14 11:45 ` [9front] cinap_lenrek
1 sibling, 0 replies; 45+ messages in thread
From: hiro @ 2022-01-12 16:56 UTC (permalink / raw)
To: 9front
On 1/12/22, thinktankworkspaces@gmail.com <thinktankworkspaces@gmail.com> wrote:
> No. Is it that easy. can I just swap out vmlinuz with 9bootfat and 9pc
https://fqa.9front.org/fqa3.html#3.3.1.2.1
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 14:18 ` [9front] Stanley Lieber
@ 2022-01-12 15:04 ` thinktankworkspaces
0 siblings, 0 replies; 45+ messages in thread
From: thinktankworkspaces @ 2022-01-12 15:04 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 53 bytes --]
OMG thanks. So the mk files handles the ISO creation
[-- Attachment #2: Type: message/rfc822, Size: 3260 bytes --]
From: Stanley Lieber <sl@stanleylieber.com>
To: 9front@9front.org
Subject: Re: [9front]
Date: Wed, 12 Jan 2022 14:18:24 +0000
Message-ID: <D9C8C87A-E18D-4127-B204-31E6C8731A28@stanleylieber.com>
clues here:
http://fqa.9front.org/fqa5.html#5.3
sl
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 13:40 ` [9front] hiro
@ 2022-01-12 14:59 ` thinktankworkspaces
2022-01-12 16:56 ` [9front] hiro
2022-01-14 11:45 ` [9front] cinap_lenrek
0 siblings, 2 replies; 45+ messages in thread
From: thinktankworkspaces @ 2022-01-12 14:59 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
No. Is it that easy. can I just swap out vmlinuz with 9bootfat and 9pc I feel like when an EC2 is
launched for the first time its amazon linux or ubuntu which ever you pick. By default it picks up
a t3.micro which also includes an EBS of about 2G. Kind of small but you can resize it. The mbr is
is already written and the bootlaoder is vmlinuz.
If I swap it out I'm still in an ext2 or ext3/4 file system so it wouldn't matter. So basically
I create another EBS then tell linux to format it fdisk and set fat then format it. I can set mbr. But
then its a matter of placing the files in the right directories on that new EBS. Then telling my ec2 linux
to reboot but on a different ebs volume and boom! I'm booting in 9front. I still feel this is a waste or
I'm doing it in the wrong order.
So right now I have my ec2 running qemu and its working fine. I could also try and tell AWS to spin
up another EBS volume and creatively mount it then run dd if=/mnt/9front.img of=/dev/to_new_volume etc...
with the right flags.
Then tell ec2 to boot on a new volume.
I guess the only benefit is speed because qemu works but I was hoping to retire it. At this moment I'm
starting to feel lazy do I push forward or settle. I need to think.
Thanks again!
[-- Attachment #2: Type: message/rfc822, Size: 6202 bytes --]
From: hiro <23hiro@gmail.com>
To: 9front@9front.org
Subject: Re: [9front]
Date: Wed, 12 Jan 2022 14:40:09 +0100
Message-ID: <CAFSF3XNCiHtVyg=p7jnjuRYWA3LvfMceRH__gqOq-y97oc9LzA@mail.gmail.com>
correct, and the plan 9 kernel supports being directly loaded by linux
bootloaders just like a linux kernel (where you would have vmlinuz for
example).
On 1/12/22, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
>
> 12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>:
>
>>> 9front has its own bootloader, at least for x86/amd64 standard
>>> machines. However, some people got 9front booting with other linux
>>> bootloaders.
>>
>> correct, but IMO that works like:
>>
>> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
>>
>> where the 9pc/9pc64 plan9 bootloader still needs to be in a given
>> position or to be contiguous on disk - refer "bootloader magic" or the
>> like somewhere in the fqa.
>
> Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd
> /sys/src/9/pc64 && mk install.
>
> But there's also the minimal initial disk or something like that,
> containing some basic programs for networking etc.
>
> sirjofri
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 9:29 ` [9front] Eckard Brauer
2022-01-12 13:09 ` [9front] sirjofri
@ 2022-01-12 14:40 ` thinktankworkspaces
1 sibling, 0 replies; 45+ messages in thread
From: thinktankworkspaces @ 2022-01-12 14:40 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Simply brilliant. I need to save this email somewhere and remember this logic. But honestly I'm
tired of qemu. I really need to read up on how the booatloader works and how to bootstrap an
AWS ec2 instance. I never used 'xd' command before so thats interesting. There seems to be
some sort of syntatical magic here in plan9 thats missing in other OS's
[-- Attachment #2: Type: message/rfc822, Size: 8663 bytes --]
From: Eckard Brauer <eckard.brauer@gmx.de>
To: 9front@9front.org
Subject: Re: [9front]
Date: Wed, 12 Jan 2022 10:29:48 +0100
Message-ID: <20220112102948.4a6d7d53@gmx.de>
> [...]
>
> Since you dd'd the iso to the usb drive before you can also just dd
> that amount of data back to an image file. I don't exactly know the
> parameter now, but the man page lists it.
>
> [...]
As long as you're on P9, that should work:
dd -if /dev/sdXXX/disk -of outfile.iso -bs 4k -count 8192k
as long as the product of bs and count args are exactly the 32 GB. With
Unix/linux/bsd it should be the same, except that args are as in MVS
(if=/dev/sdY of=outfile.iso etc.).
Problem could be that the initial dd when preparing the usb went to the
(1st?) partition of the USB instead of the raw (whole) device. Maybe
it's possible to read&compare the first few bytes, e.g.
dd -if /dev/sdXXX -bs 1b -count 1 | xd -1x
the same for image.iso
> The sdUxxx directory contails lots of files for lowlevel interaction.
> E.g it contains a ctl and data, and a file for each partition you can
> mount.
>
> In this case I'm pretty sure you can call the command on the data
> file (which is the disk ignoring all partitions).
>
> [...]
>
> 9front has its own bootloader, at least for x86/amd64 standard
> machines. However, some people got 9front booting with other linux
> bootloaders.
correct, but IMO that works like:
BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
where the 9pc/9pc64 plan9 bootloader still needs to be in a given
position or to be contiguous on disk - refer "bootloader magic" or the
like somewhere in the fqa.
But didn't try that with qemu at all, IIRC that was the init. problem.
> [...]
>
> Have you tried dding the iso to a usb drive and edit the file in the
> fat directory? (And dding back)
>
> It might even be possible that you can mount the iso somehow and
> change the file there. I'm not sure about it and I don't know how it
> handles the mbr then...
For little edits NOT violating block boundaries, even in-binary-edits
are fine, did that a few time using sed, but you have to double
(triple,...) check the boundaries before. Or you could even split the
image file apart (with dd) into prefix + file contents + suffix, edit
the 2nd one, compare size and reassemble, if it's contiguous - but all
that's bit dangerous.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 8:30 ` [9front] sirjofri
2022-01-12 9:29 ` [9front] Eckard Brauer
@ 2022-01-12 14:18 ` Stanley Lieber
2022-01-12 15:04 ` [9front] thinktankworkspaces
1 sibling, 1 reply; 45+ messages in thread
From: Stanley Lieber @ 2022-01-12 14:18 UTC (permalink / raw)
To: 9front
clues here:
http://fqa.9front.org/fqa5.html#5.3
sl
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 13:09 ` [9front] sirjofri
@ 2022-01-12 13:40 ` hiro
2022-01-12 14:59 ` [9front] thinktankworkspaces
0 siblings, 1 reply; 45+ messages in thread
From: hiro @ 2022-01-12 13:40 UTC (permalink / raw)
To: 9front
correct, and the plan 9 kernel supports being directly loaded by linux
bootloaders just like a linux kernel (where you would have vmlinuz for
example).
On 1/12/22, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
>
> 12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>:
>
>>> 9front has its own bootloader, at least for x86/amd64 standard
>>> machines. However, some people got 9front booting with other linux
>>> bootloaders.
>>
>> correct, but IMO that works like:
>>
>> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
>>
>> where the 9pc/9pc64 plan9 bootloader still needs to be in a given
>> position or to be contiguous on disk - refer "bootloader magic" or the
>> like somewhere in the fqa.
>
> Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd
> /sys/src/9/pc64 && mk install.
>
> But there's also the minimal initial disk or something like that,
> containing some basic programs for networking etc.
>
> sirjofri
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 9:29 ` [9front] Eckard Brauer
@ 2022-01-12 13:09 ` sirjofri
2022-01-12 13:40 ` [9front] hiro
2022-01-12 14:40 ` [9front] thinktankworkspaces
1 sibling, 1 reply; 45+ messages in thread
From: sirjofri @ 2022-01-12 13:09 UTC (permalink / raw)
To: Eckard Brauer
12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>:
>> 9front has its own bootloader, at least for x86/amd64 standard
>> machines. However, some people got 9front booting with other linux
>> bootloaders.
>
> correct, but IMO that works like:
>
> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
>
> where the 9pc/9pc64 plan9 bootloader still needs to be in a given
> position or to be contiguous on disk - refer "bootloader magic" or the
> like somewhere in the fqa.
Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd
/sys/src/9/pc64 && mk install.
But there's also the minimal initial disk or something like that,
containing some basic programs for networking etc.
sirjofri
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 8:30 ` [9front] sirjofri
@ 2022-01-12 9:29 ` Eckard Brauer
2022-01-12 13:09 ` [9front] sirjofri
2022-01-12 14:40 ` [9front] thinktankworkspaces
2022-01-12 14:18 ` [9front] Stanley Lieber
1 sibling, 2 replies; 45+ messages in thread
From: Eckard Brauer @ 2022-01-12 9:29 UTC (permalink / raw)
To: 9front
> [...]
>
> Since you dd'd the iso to the usb drive before you can also just dd
> that amount of data back to an image file. I don't exactly know the
> parameter now, but the man page lists it.
>
> [...]
As long as you're on P9, that should work:
dd -if /dev/sdXXX/disk -of outfile.iso -bs 4k -count 8192k
as long as the product of bs and count args are exactly the 32 GB. With
Unix/linux/bsd it should be the same, except that args are as in MVS
(if=/dev/sdY of=outfile.iso etc.).
Problem could be that the initial dd when preparing the usb went to the
(1st?) partition of the USB instead of the raw (whole) device. Maybe
it's possible to read&compare the first few bytes, e.g.
dd -if /dev/sdXXX -bs 1b -count 1 | xd -1x
the same for image.iso
> The sdUxxx directory contails lots of files for lowlevel interaction.
> E.g it contains a ctl and data, and a file for each partition you can
> mount.
>
> In this case I'm pretty sure you can call the command on the data
> file (which is the disk ignoring all partitions).
>
> [...]
>
> 9front has its own bootloader, at least for x86/amd64 standard
> machines. However, some people got 9front booting with other linux
> bootloaders.
correct, but IMO that works like:
BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
where the 9pc/9pc64 plan9 bootloader still needs to be in a given
position or to be contiguous on disk - refer "bootloader magic" or the
like somewhere in the fqa.
But didn't try that with qemu at all, IIRC that was the init. problem.
> [...]
>
> Have you tried dding the iso to a usb drive and edit the file in the
> fat directory? (And dding back)
>
> It might even be possible that you can mount the iso somehow and
> change the file there. I'm not sure about it and I don't know how it
> handles the mbr then...
For little edits NOT violating block boundaries, even in-binary-edits
are fine, did that a few time using sed, but you have to double
(triple,...) check the boundaries before. Or you could even split the
image file apart (with dd) into prefix + file contents + suffix, edit
the 2nd one, compare size and reassemble, if it's contiguous - but all
that's bit dangerous.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-12 1:16 ` [9front] thinktankworkspaces
@ 2022-01-12 8:30 ` sirjofri
2022-01-12 9:29 ` [9front] Eckard Brauer
2022-01-12 14:18 ` [9front] Stanley Lieber
0 siblings, 2 replies; 45+ messages in thread
From: sirjofri @ 2022-01-12 8:30 UTC (permalink / raw)
To: 9front
12.01.2022 02:16:57 thinktankworkspaces@gmail.com:
> Super frustrating. I'm sure I'm making it more difficult
>
> I tried following 4.2.2.1
>
> It seems like things should be easier. 9bootfat, 9pc, ini and
> 9front.iso. I think the frustrating part was being stuck dealing with a
> usb device. I don't care about thumb drives. All of this should
> be accomplished with an iso or 9front.bin or something similar.
>
> I ended up doing a dd from /dev/SDUxxx -of cd.iso
>
> But it was exactly 32G image. I have a limitation because its on
> AWS with an EBS of 32G maximum.
Since you dd'd the iso to the usb drive before you can also just dd that
amount of data back to an image file. I don't exactly know the parameter
now, but the man page lists it.
> In theory I should have been mount the ISO and dump the data, then
> modify ini. But how in the world do you write the mbr you can't do
> that to a directory
>
> disk/mbr -r mbr /dev/sdUxxx
The sdUxxx directory contails lots of files for lowlevel interaction. E.g
it contains a ctl and data, and a file for each partition you can mount.
In this case I'm pretty sure you can call the command on the data file
(which is the disk ignoring all partitions).
> So really I'm not sure how iso's are created in 9front. I suspect
> some sort of rockridge format and a generic bootloader.
9front has its own bootloader, at least for x86/amd64 standard machines.
However, some people got 9front booting with other linux bootloaders.
As for the iso, I can't really help you. I never created an iso (I
planned to do it) on 9front with the 9front system.
However, there are commands and filesystem that support the generation of
iso files in general. I did it some time ago since it is easier to burn
an iso to cd than a whole directory of files.
lookman iso
> Here is what I ended up doing. I fired up qemu locally and performed
> the install. Then I logged in and changed the ini file and added
> console=0. Then I copied the 9front.img to the AWS ec2 instance.
> Everything came up fine text mode. Nice! and thak you for the help.
Have you tried dding the iso to a usb drive and edit the file in the fat
directory? (And dding back)
It might even be possible that you can mount the iso somehow and change
the file there. I'm not sure about it and I don't know how it handles the
mbr then...
I hope this helps
sirjofri
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-10 23:33 ` [9front] sirjofri
@ 2022-01-12 1:16 ` thinktankworkspaces
2022-01-12 8:30 ` [9front] sirjofri
0 siblings, 1 reply; 45+ messages in thread
From: thinktankworkspaces @ 2022-01-12 1:16 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
Super frustrating. I'm sure I'm making it more difficult
I tried following 4.2.2.1
It seems like things should be easier. 9bootfat, 9pc, ini and 9front.iso. I think the frustrating part was being stuck dealing with a
usb device. I don't care about thumb drives. All of this should
be accomplished with an iso or 9front.bin or something similar.
I ended up doing a dd from /dev/SDUxxx -of cd.iso
But it was exactly 32G image. I have a limitation because its on
AWS with an EBS of 32G maximum.
In theory I should have been mount the ISO and dump the data, then
modify ini. But how in the world do you write the mbr you can't do
that to a directory
disk/mbr -r mbr /dev/sdUxxx
So really I'm not sure how iso's are created in 9front. I suspect
some sort of rockridge format and a generic bootloader.
Here is what I ended up doing. I fired up qemu locally and performed
the install. Then I logged in and changed the ini file and added
console=0. Then I copied the 9front.img to the AWS ec2 instance.
Everything came up fine text mode. Nice! and thak you for the help.
Honestly I would like to use the ec2 bare metal. Its already a
hypervisor. I just don't know what to do to make that happen. I
suspect I would need to dump the data into another EBS then force
the EC2 to load it. But i'm also not sure of the files required
beyond digging into inst/start and looking at the rc scripts.
Or a docker would be nice. I saw a docker out there but it was two
years old. It also ran on alpine linux, so someone manged to copy
some files over. Maybe I don't want docker. Bare metal is better any thoughts would be much appreciated.
[-- Attachment #2: Type: message/rfc822, Size: 4587 bytes --]
From: sirjofri <sirjofri+ml-9front@sirjofri.de>
To: 9front@9front.org
Subject: Re: [9front]
Date: Mon, 10 Jan 2022 23:33:38 +0000 (UTC)
Message-ID: <89cc4583-2f86-49f0-98b6-69dec8c45816@sirjofri.de>
10.01.2022 18:25:59 thinktankworkspaces@gmail.com:
> Okay this is where it get confusing. So I suspect I mount the
> 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the
> contents into another directory and edit the plan9.ini file. Then
> repackage the iso with the altered .ini file and reset the boot
> record? Now I have a new but modified iso that has console=0. I can
> then try to install it on my target remote system via ssh/
I guess after dd'ing the iso to a usb drive you can just edit the
plan9.ini file in the fat directory. It's not so easy when having to deal
with CDs for obvious reasons.
However, you should have luck with mounting a copy of the iso, changing
the file (and saving the iso), then overwriting the first sector(s) with
the contents of the original iso. Make soure you don't overwrite the FAT
and contents, the partition tables should be the same anyways.
It's also possible to generate a fresh iso with your settings if you have
an installed 9front system. You wouldn't need to run sysupdates after
installation, but this is definitely more work.
Disclaimer: I never did any of these things with 9front.
Good luck
sirjofri
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-10 17:25 ` [9front] thinktankworkspaces
@ 2022-01-10 23:33 ` sirjofri
2022-01-12 1:16 ` [9front] thinktankworkspaces
0 siblings, 1 reply; 45+ messages in thread
From: sirjofri @ 2022-01-10 23:33 UTC (permalink / raw)
To: 9front
10.01.2022 18:25:59 thinktankworkspaces@gmail.com:
> Okay this is where it get confusing. So I suspect I mount the
> 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the
> contents into another directory and edit the plan9.ini file. Then
> repackage the iso with the altered .ini file and reset the boot
> record? Now I have a new but modified iso that has console=0. I can
> then try to install it on my target remote system via ssh/
I guess after dd'ing the iso to a usb drive you can just edit the
plan9.ini file in the fat directory. It's not so easy when having to deal
with CDs for obvious reasons.
However, you should have luck with mounting a copy of the iso, changing
the file (and saving the iso), then overwriting the first sector(s) with
the contents of the original iso. Make soure you don't overwrite the FAT
and contents, the partition tables should be the same anyways.
It's also possible to generate a fresh iso with your settings if you have
an installed 9front system. You wouldn't need to run sysupdates after
installation, but this is definitely more work.
Disclaimer: I never did any of these things with 9front.
Good luck
sirjofri
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-10 10:21 ` [9front] sirjofri
@ 2022-01-10 17:25 ` thinktankworkspaces
2022-01-10 23:33 ` [9front] sirjofri
0 siblings, 1 reply; 45+ messages in thread
From: thinktankworkspaces @ 2022-01-10 17:25 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 389 bytes --]
Okay this is where it get confusing. So I suspect I mount the 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the contents into another directory and edit the plan9.ini file. Then
repackage the iso with the altered .ini file and reset the boot
record? Now I have a new but modified iso that has console=0. I can
then try to install it on my target remote system via ssh/
[-- Attachment #2: Type: message/rfc822, Size: 4319 bytes --]
From: sirjofri <sirjofri+ml-9front@sirjofri.de>
To: 9front@9front.org
Subject: Re: [9front]
Date: Mon, 10 Jan 2022 10:21:56 +0000 (UTC)
Message-ID: <3cd7037b-6fa3-4ebd-b602-e65f6989872e@sirjofri.de>
10.01.2022 09:44:51 thinktankworkspaces@gmail.com:
> Trying to do an install on a remote server via ssh that has qemu.
>
> I suppose i'm doing this with -nographic
>
> kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
> 9front-xxxx-i386.iso -m 1024
>
> With pipes such as /tmp/guest.in /tmp/guest.out
>
> I'm receiving data.
>
> Booting from DVD/CD... *e820 ..... ... ... cdboot=yes
> mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
>
>
> But it stops at that last line and nothing. Any thoughts or
> recommendations? Is it possible? Or do I have to build the image
> local then copy the 9front.img to remote system. I worry that I will
> run into same situation where it gets stuck.
Please check plan9.ini(8) man page and look for console=. I believe
that's what you want/need.
I can't give more advise since I didn't use it (yet).
sirjofri
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-10 8:44 [9front] thinktankworkspaces
2022-01-10 10:21 ` [9front] sirjofri
@ 2022-01-10 12:10 ` mkf
1 sibling, 0 replies; 45+ messages in thread
From: mkf @ 2022-01-10 12:10 UTC (permalink / raw)
To: 9front
-------- Original Message --------
> Trying to do an install on a remote server via ssh that has qemu.
>
> I suppose i'm doing this with -nographic
>
> kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
> 9front-xxxx-i386.iso -m 1024
>
> With pipes such as /tmp/guest.in /tmp/guest.out
>
> I'm receiving data.
>
> Booting from DVD/CD... *e820 ..... ... ... cdboot=yes
> mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
>
>
> But it stops at that last line and nothing. Any thoughts or
> recommendations? Is it possible? Or do I have to build the image
> local then copy the 9front.img to remote system. I worry that I will
> run into same situation where it gets stuck.
>
try console=0.
(before 9boot timeouts and tries to boot)
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2022-01-10 8:44 [9front] thinktankworkspaces
@ 2022-01-10 10:21 ` sirjofri
2022-01-10 17:25 ` [9front] thinktankworkspaces
2022-01-10 12:10 ` [9front] mkf
1 sibling, 1 reply; 45+ messages in thread
From: sirjofri @ 2022-01-10 10:21 UTC (permalink / raw)
To: 9front
10.01.2022 09:44:51 thinktankworkspaces@gmail.com:
> Trying to do an install on a remote server via ssh that has qemu.
>
> I suppose i'm doing this with -nographic
>
> kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
> 9front-xxxx-i386.iso -m 1024
>
> With pipes such as /tmp/guest.in /tmp/guest.out
>
> I'm receiving data.
>
> Booting from DVD/CD... *e820 ..... ... ... cdboot=yes
> mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
>
>
> But it stops at that last line and nothing. Any thoughts or
> recommendations? Is it possible? Or do I have to build the image
> local then copy the 9front.img to remote system. I worry that I will
> run into same situation where it gets stuck.
Please check plan9.ini(8) man page and look for console=. I believe
that's what you want/need.
I can't give more advise since I didn't use it (yet).
sirjofri
^ permalink raw reply [flat|nested] 45+ messages in thread
* [9front]
@ 2022-01-10 8:44 thinktankworkspaces
2022-01-10 10:21 ` [9front] sirjofri
2022-01-10 12:10 ` [9front] mkf
0 siblings, 2 replies; 45+ messages in thread
From: thinktankworkspaces @ 2022-01-10 8:44 UTC (permalink / raw)
To: 9front
Trying to do an install on a remote server via ssh that has qemu.
I suppose i'm doing this with -nographic
kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
9front-xxxx-i386.iso -m 1024
With pipes such as /tmp/guest.in /tmp/guest.out
I'm receiving data.
Booting from DVD/CD... *e820 ..... ... ... cdboot=yes
mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
But it stops at that last line and nothing. Any thoughts or
recommendations? Is it possible? Or do I have to build the image
local then copy the 9front.img to remote system. I worry that I will
run into same situation where it gets stuck.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [9front]
@ 2021-09-16 22:17 Drew Fargo
0 siblings, 0 replies; 45+ messages in thread
From: Drew Fargo @ 2021-09-16 22:17 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 10 bytes --]
subscribe
[-- Attachment #2: Type: text/html, Size: 31 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* [9front]
@ 2021-08-24 19:25 Jonas
0 siblings, 0 replies; 45+ messages in thread
From: Jonas @ 2021-08-24 19:25 UTC (permalink / raw)
To: 9front
unsubscribe
^ permalink raw reply [flat|nested] 45+ messages in thread
* [9front]
@ 2021-06-09 14:33 adr
0 siblings, 0 replies; 45+ messages in thread
From: adr @ 2021-06-09 14:33 UTC (permalink / raw)
To: 9front
unsubscribe
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-04-02 18:31 ` [9front] cinap_lenrek
@ 2021-04-03 0:41 ` Romano
0 siblings, 0 replies; 45+ messages in thread
From: Romano @ 2021-04-03 0:41 UTC (permalink / raw)
To: 9front, cinap_lenrek
On April 2, 2021 6:31:56 PM UTC, cinap_lenrek@felloff.net wrote:
>A quick follow up on the Pallocmem slots.
>
>I just eleminated the array in the last commit, as we can
>caclculate the user page allocation from the conf.mem[]
>array, so the xinit errors can be avoided completely.
>
>Can you confirm that this works on the macbook with
>just increasing the conf.mem[] array size?
I updated and built two ISOs, one with etherbcm added back in to pc64 and one without. The one without bcm boots, but slightly less overall mem is found, the difference being kernel data. Initial:
4009MB memory: 1688M kernel data, 2321M user, 2946M swap
vs changeset 8390:
3928MB memory: 1607M kernel data, 2321M user, 2946M swap
Both kmesgs are available at https://blog.fallglow.com/misc/mbpro
The other ISO, in which I added back in etherbcm, causes the same machine check error as before.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-04-02 21:24 ` [9front] Romano
@ 2021-04-02 21:54 ` cinap_lenrek
0 siblings, 0 replies; 45+ messages in thread
From: cinap_lenrek @ 2021-04-02 21:54 UTC (permalink / raw)
To: 9front
ok, i'll stop trying to get this macbook working in this release
as we obviously need to do more work with etherbcm to get it
supported out of the box.
--
cinap
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-04-02 14:31 ` [9front] cinap_lenrek
2021-04-02 18:31 ` [9front] cinap_lenrek
@ 2021-04-02 21:24 ` Romano
2021-04-02 21:54 ` [9front] cinap_lenrek
1 sibling, 1 reply; 45+ messages in thread
From: Romano @ 2021-04-02 21:24 UTC (permalink / raw)
To: 9front, cinap_lenrek
On April 2, 2021 2:31:24 PM UTC, cinap_lenrek@felloff.net wrote:
>This is why we'r loosing amlsost 2GB of user memory because
>of the high fragmentation of the memory map.
>
>The xinit errors are due to us running out of pallocmem slots.
>
>change the Palloc struct in /sys/src/9/port/portdat.h:
>
>- Pallocmem mem[16]; /* physical user page banks */
>+ Pallocmem mem[32]; /* physical user page banks */
Updated, and was able to boot.
>We could also try to minimize the memory loss by sorting the
>Conf.mem[] array by region size.
>
>For the machine check, do you confirm that it is related to
>the bcm ethernet driver? And when you removed the driver
>that it went away?
Yes, I removed the bcm driver and that's how I was able to boot successfully before changing Pallocmem.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-04-02 14:31 ` [9front] cinap_lenrek
@ 2021-04-02 18:31 ` cinap_lenrek
2021-04-03 0:41 ` [9front] Romano
2021-04-02 21:24 ` [9front] Romano
1 sibling, 1 reply; 45+ messages in thread
From: cinap_lenrek @ 2021-04-02 18:31 UTC (permalink / raw)
To: 9front
A quick follow up on the Pallocmem slots.
I just eleminated the array in the last commit, as we can
caclculate the user page allocation from the conf.mem[]
array, so the xinit errors can be avoided completely.
Can you confirm that this works on the macbook with
just increasing the conf.mem[] array size?
--
cinap
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-04-01 23:16 ` [9front] Romano
@ 2021-04-02 14:31 ` cinap_lenrek
2021-04-02 18:31 ` [9front] cinap_lenrek
2021-04-02 21:24 ` [9front] Romano
0 siblings, 2 replies; 45+ messages in thread
From: cinap_lenrek @ 2021-04-02 14:31 UTC (permalink / raw)
To: 9front
This is why we'r loosing amlsost 2GB of user memory because
of the high fragmentation of the memory map.
The xinit errors are due to us running out of pallocmem slots.
change the Palloc struct in /sys/src/9/port/portdat.h:
- Pallocmem mem[16]; /* physical user page banks */
+ Pallocmem mem[32]; /* physical user page banks */
We could also try to minimize the memory loss by sorting the
Conf.mem[] array by region size.
For the machine check, do you confirm that it is related to
the bcm ethernet driver? And when you removed the driver
that it went away?
--
cinap
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-04-01 19:03 ` [9front] cinap_lenrek
@ 2021-04-01 23:16 ` Romano
2021-04-02 14:31 ` [9front] cinap_lenrek
0 siblings, 1 reply; 45+ messages in thread
From: Romano @ 2021-04-01 23:16 UTC (permalink / raw)
To: 9front, cinap_lenrek
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On April 1, 2021 7:03:37 PM UTC, cinap_lenrek@felloff.net wrote:
>i dont see a kernelpanic here.
>
>it seems just that it locks up as soon as it tries to enable the
>broadcom ethernet?
>
>Does the bcm ethernet work before?
It initializes, and can send packets, but never receives any.
>and i see that we run out of conf.mem[] slots (is this 386 or amd64
>kernel?).
amd64
>The easiest is to just increase the number of Confmem slots in
>pc64/dat.h:
>
>- Confmem mem[16]; /* physical memory */
>+ Confmem mem[64]; /* physical memory */
>
>Can you be more specific on what is the regression here?
I know I've replied with my results off-list to your other email you sent, but hadn't tried this yet. I still get a machine check error, but the inital boot text has a lot of 'xinit' errors. I then commented out the bcm line in pc64 and rebuilt the kernel. That got me a little farther, but now loading hjfs with -m 581 I get an out of memory error. If I use -m 128, I get to rio. Then, if I switch back Confmem to use 16 instead of 64, I still grt the meminit errors but successfully boot using -m 581 with hjfs. (I noticed that the 64 for Confmem set aside a lot more for the kernel and loads more mem overall, but left little for user mem).
Hopefully some of this is helpful.
[-- Attachment #2: IMAG9254.jpg --]
[-- Type: image/jpeg, Size: 1549830 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-04-01 18:33 ` [9front] Romano
2021-04-01 18:54 ` [9front] Romano
@ 2021-04-01 19:03 ` cinap_lenrek
2021-04-01 23:16 ` [9front] Romano
1 sibling, 1 reply; 45+ messages in thread
From: cinap_lenrek @ 2021-04-01 19:03 UTC (permalink / raw)
To: 9front
i dont see a kernelpanic here.
it seems just that it locks up as soon as it tries to enable the broadcom ethernet?
Does the bcm ethernet work before?
and i see that we run out of conf.mem[] slots (is this 386 or amd64 kernel?).
The easiest is to just increase the number of Confmem slots in pc64/dat.h:
- Confmem mem[16]; /* physical memory */
+ Confmem mem[64]; /* physical memory */
Can you be more specific on what is the regression here?
--
cinap
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-04-01 18:33 ` [9front] Romano
@ 2021-04-01 18:54 ` Romano
2021-04-01 19:03 ` [9front] cinap_lenrek
1 sibling, 0 replies; 45+ messages in thread
From: Romano @ 2021-04-01 18:54 UTC (permalink / raw)
To: 9front, cinap_lenrek
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
Looks like the second image was not attached.
On April 1, 2021 6:33:48 PM UTC, Romano <unobe@cpan.org> wrote:
>
>
>On March 31, 2021 4:32:37 PM UTC, cinap_lenrek@felloff.net wrote:
>>Subject: state of emmc and usb on pi400 and cm4
>>I'm in preparation for a new 9front release,
>>fixing penting issues.
>>
>>I have confirmation that the XHCI (USB3) works
>>now on the pi400, but there are still issues with
>>the sdcard.
>>
>>On the CM4, we have to enable the usbdwc driver
>>(as it does not have the xhci controller chip)
>>in the kernel configuration, but i have no
>>confirmation if this works.
>>
>>So is it possible for anyone owning these devices
>>to troubleshoot this before the end of this week?
>
>I don't have a pi400, but I do have a macbook pro, 13", early 2011.
>With the last release's ISO (8013), it booted and installed fine
>(albeit with a bunch of i8042 warnings and bcm not functioning) . I
>resolved my networking issue by tethering to a pinephone. However, with
>tip I get a kernel panic. I have attached screenshots. Any idea what
>could be the cause?
[-- Attachment #2: IMAG9253.jpg --]
[-- Type: image/jpeg, Size: 1549944 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-03-31 16:32 [9front] cinap_lenrek
@ 2021-04-01 18:33 ` Romano
2021-04-01 18:54 ` [9front] Romano
2021-04-01 19:03 ` [9front] cinap_lenrek
0 siblings, 2 replies; 45+ messages in thread
From: Romano @ 2021-04-01 18:33 UTC (permalink / raw)
To: 9front, cinap_lenrek
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
On March 31, 2021 4:32:37 PM UTC, cinap_lenrek@felloff.net wrote:
>Subject: state of emmc and usb on pi400 and cm4
>I'm in preparation for a new 9front release,
>fixing penting issues.
>
>I have confirmation that the XHCI (USB3) works
>now on the pi400, but there are still issues with
>the sdcard.
>
>On the CM4, we have to enable the usbdwc driver
>(as it does not have the xhci controller chip)
>in the kernel configuration, but i have no
>confirmation if this works.
>
>So is it possible for anyone owning these devices
>to troubleshoot this before the end of this week?
I don't have a pi400, but I do have a macbook pro, 13", early 2011. With the last release's ISO (8013), it booted and installed fine (albeit with a bunch of i8042 warnings and bcm not functioning) . I resolved my networking issue by tethering to a pinephone. However, with tip I get a kernel panic. I have attached screenshots. Any idea what could be the cause?
[-- Attachment #2: IMAG9252.jpg --]
[-- Type: image/jpeg, Size: 1550115 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* [9front]
@ 2021-03-31 16:32 cinap_lenrek
2021-04-01 18:33 ` [9front] Romano
0 siblings, 1 reply; 45+ messages in thread
From: cinap_lenrek @ 2021-03-31 16:32 UTC (permalink / raw)
To: 9front
Subect: state of emmc and usb on pi400 and cm4
Hola,
I'm in preparation for a new 9front release,
fixing penting issues.
I have confirmation that the XHCI (USB3) works
now on the pi400, but there are still issues with
the sdcard.
On the CM4, we have to enable the usbdwc driver
(as it does not have the xhci controller chip)
in the kernel configuration, but i have no
confirmation if this works.
So is it possible for anyone owning these devices
to troubleshoot this before the end of this week?
It would be nice to get this fixed and include it
in the upcoming release...
--
cinap
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-01-23 13:38 ` [9front] Thaddeus Woskowiak
@ 2021-01-23 14:12 ` hiro
0 siblings, 0 replies; 45+ messages in thread
From: hiro @ 2021-01-23 14:12 UTC (permalink / raw)
To: 9front
send an e-mail message to 9front-owner@9front.org, this time
containing, on a single line, the unsubscribe command.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-01-22 16:32 [9front] Марко М. Костић
2021-01-22 23:41 ` [9front] Tanami Muller
@ 2021-01-23 13:38 ` Thaddeus Woskowiak
2021-01-23 14:12 ` [9front] hiro
1 sibling, 1 reply; 45+ messages in thread
From: Thaddeus Woskowiak @ 2021-01-23 13:38 UTC (permalink / raw)
To: 9front
On Fri, Jan 22, 2021 at 11:58 AM Марко М. Костић
<marko.m.kostic@gmail.com> wrote:
>
> unsubscribe
One does not simply unsubscribe from 9front.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-01-22 23:41 ` [9front] Tanami Muller
@ 2021-01-23 0:29 ` Stuart Morrow
0 siblings, 0 replies; 45+ messages in thread
From: Stuart Morrow @ 2021-01-23 0:29 UTC (permalink / raw)
To: 9front
Polo
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2021-01-22 16:32 [9front] Марко М. Костић
@ 2021-01-22 23:41 ` Tanami Muller
2021-01-23 0:29 ` [9front] Stuart Morrow
2021-01-23 13:38 ` [9front] Thaddeus Woskowiak
1 sibling, 1 reply; 45+ messages in thread
From: Tanami Muller @ 2021-01-22 23:41 UTC (permalink / raw)
To: 9front
It won't be that easy, my friend.
On Sat, Jan 23, 2021 at 3:28 AM Марко М. Костић
<marko.m.kostic@gmail.com> wrote:
>
> unsubscribe
--
Tanami Muller
Chief Technology Officer
Email: tanami@oneworldled.com
Mobile: 0450 107 311
Office: (08) 8374 4557
Address: 1024 South Road, Edwardstown
^ permalink raw reply [flat|nested] 45+ messages in thread
* [9front]
@ 2021-01-22 16:32 Марко М. Костић
2021-01-22 23:41 ` [9front] Tanami Muller
2021-01-23 13:38 ` [9front] Thaddeus Woskowiak
0 siblings, 2 replies; 45+ messages in thread
From: Марко М. Костић @ 2021-01-22 16:32 UTC (permalink / raw)
To: 9front
unsubscribe
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
@ 2018-08-20 19:42 umbraticus
0 siblings, 0 replies; 45+ messages in thread
From: umbraticus @ 2018-08-20 19:42 UTC (permalink / raw)
To: 9front
> Note, however, that there is a bug in hjfs(4) which means this last
> part won't work. I already have a patch for this; I'll send it to the
> list now.
Thanks! I didn't realise that the fact I'd switched to hjfs might be relevant
but that is clearly why it worked before and why I am tearing my hair out now.
Will someone commit the patch?
umbraticus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
@ 2018-08-20 12:11 Alex Musolino
0 siblings, 0 replies; 45+ messages in thread
From: Alex Musolino @ 2018-08-20 12:11 UTC (permalink / raw)
To: 9front
Hi,
This is not quite how I have it set up but I think this is probably
the way to go:
Have each mail box, /mail/box/$user/mbox, be owned by upas, with the
group set to $user and the mode set to 0770. Then run your upas/smtpd
listener as upas. This will allow upas access to all mail boxes, but
each user will only have access to their own. Files created by upas
in the mailboxes will be owned by upas and the group will be inherited
from the parent directory.
Note, however, that there is a bug in hjfs(4) which means this last
part won't work. I already have a patch for this; I'll send it to the
list now.
--
Cheers,
Alex Musolino
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2018-06-06 12:30 Stanislav Paskalev
@ 2018-06-06 15:50 ` Kurt H Maier
0 siblings, 0 replies; 45+ messages in thread
From: Kurt H Maier @ 2018-06-06 15:50 UTC (permalink / raw)
To: 9front
On Wed, Jun 06, 2018 at 03:30:13PM +0300, Stanislav Paskalev wrote:
> unsubscribe
if you send this message to 9front-owner@9front.org it might even work
khm
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
@ 2018-02-17 4:53 kokamoto
0 siblings, 0 replies; 45+ messages in thread
From: kokamoto @ 2018-02-17 4:53 UTC (permalink / raw)
To: 9front
> 9FRONT "CONTENTS, MAINTAINED, STABLE" RELEASED
> ==============================================
Thank you very much this release!
Now
(1) I can use sandy bridge (Dell desktop) machine without any problem
up tp 1920x1200x32 resolution.
(2) Now I don't need nupas, the generic upas now has its functionarity.
Now I'm wrinting this mail by the new upas program.
Kenji
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2016-12-28 23:31 sl
@ 2016-12-28 23:33 ` cinap_lenrek
0 siblings, 0 replies; 45+ messages in thread
From: cinap_lenrek @ 2016-12-28 23:33 UTC (permalink / raw)
To: 9front
nice! :-)
i like the back picture :-)
--
cinap
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2015-10-02 14:32 ` [9front] Kurt H Maier
@ 2015-10-04 21:18 ` Stanley Lieber
0 siblings, 0 replies; 45+ messages in thread
From: Stanley Lieber @ 2015-10-04 21:18 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
Guys, read the tin:
http://lists.9front.org
sl
On Oct 2, 2015, 10:32 AM, at 10:32 AM, Kurt H Maier <khm@sciops.net> wrote:
>On Fri, Oct 02, 2015 at 01:43:11PM +0200, Holger Sebert wrote:
>> X-Mailer: iPhone Mail (11D257)
>>
>> unsubscribe
>>
>
>hahaha
[-- Attachment #2: Type: text/html, Size: 216 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9front]
2015-10-02 11:43 Holger Sebert
@ 2015-10-02 14:32 ` Kurt H Maier
2015-10-04 21:18 ` [9front] Stanley Lieber
0 siblings, 1 reply; 45+ messages in thread
From: Kurt H Maier @ 2015-10-02 14:32 UTC (permalink / raw)
To: 9front
On Fri, Oct 02, 2015 at 01:43:11PM +0200, Holger Sebert wrote:
> X-Mailer: iPhone Mail (11D257)
>
> unsubscribe
>
hahaha
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2025-01-19 22:45 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-19 22:42 [9front] sl
-- strict thread matches above, loose matches on Subject: below --
2024-05-21 23:33 [9front] drawterm: add .gitignore Romano
2024-05-22 9:43 ` sirjofri
2024-05-22 12:07 ` [9front] Tomás Ciccola
2022-06-22 12:28 [9front] roy niang
2022-06-22 12:32 ` [9front] stefncb
2022-01-10 8:44 [9front] thinktankworkspaces
2022-01-10 10:21 ` [9front] sirjofri
2022-01-10 17:25 ` [9front] thinktankworkspaces
2022-01-10 23:33 ` [9front] sirjofri
2022-01-12 1:16 ` [9front] thinktankworkspaces
2022-01-12 8:30 ` [9front] sirjofri
2022-01-12 9:29 ` [9front] Eckard Brauer
2022-01-12 13:09 ` [9front] sirjofri
2022-01-12 13:40 ` [9front] hiro
2022-01-12 14:59 ` [9front] thinktankworkspaces
2022-01-12 16:56 ` [9front] hiro
2022-01-14 11:45 ` [9front] cinap_lenrek
2022-01-12 14:40 ` [9front] thinktankworkspaces
2022-01-12 14:18 ` [9front] Stanley Lieber
2022-01-12 15:04 ` [9front] thinktankworkspaces
2022-01-10 12:10 ` [9front] mkf
2021-09-16 22:17 [9front] Drew Fargo
2021-08-24 19:25 [9front] Jonas
2021-06-09 14:33 [9front] adr
2021-03-31 16:32 [9front] cinap_lenrek
2021-04-01 18:33 ` [9front] Romano
2021-04-01 18:54 ` [9front] Romano
2021-04-01 19:03 ` [9front] cinap_lenrek
2021-04-01 23:16 ` [9front] Romano
2021-04-02 14:31 ` [9front] cinap_lenrek
2021-04-02 18:31 ` [9front] cinap_lenrek
2021-04-03 0:41 ` [9front] Romano
2021-04-02 21:24 ` [9front] Romano
2021-04-02 21:54 ` [9front] cinap_lenrek
2021-01-22 16:32 [9front] Марко М. Костић
2021-01-22 23:41 ` [9front] Tanami Muller
2021-01-23 0:29 ` [9front] Stuart Morrow
2021-01-23 13:38 ` [9front] Thaddeus Woskowiak
2021-01-23 14:12 ` [9front] hiro
2018-08-20 19:42 [9front] umbraticus
2018-08-20 12:11 [9front] Alex Musolino
2018-06-06 12:30 Stanislav Paskalev
2018-06-06 15:50 ` [9front] Kurt H Maier
2018-02-17 4:53 [9front] kokamoto
2016-12-28 23:31 sl
2016-12-28 23:33 ` [9front] cinap_lenrek
2015-10-02 11:43 Holger Sebert
2015-10-02 14:32 ` [9front] Kurt H Maier
2015-10-04 21:18 ` [9front] Stanley Lieber
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).