Re: [9fans] syscall 53
I will use pull -n from now on. But it will still not help if one needs to recompile kernel with new syscalls or similar. Erics procedure helps to recover to old state, but i never tried it, it may be that some commands needed new syscall too, i tried to copy to 9fat with same error, maybe it was the same with copying to /sys/src or /386/bin, cause fs, faces, webfs and many others were all in a broken state. So I just booted puppy linux from usb stick and copied kernels from http://9legacy.org/download/kernel.tar.bz2 to 9fat partition, then booted plan9, recompiled custom kernel. Thanks.
Re: [9fans] syscall 53
The safe way to upgrade your file server is simply to update the kernel binaries (for example, with the ones I'm providing) on your 9fat and reboot. Then, you can pull the updated program binaries from /n/sources. There is no need to wait, because you have to be running the new kernel before pulling the new binaires anyway. In the case you need a custom kernel to boot your file server, you will have to grab the changes manually (like http://9fans.eu/pegasus/sources/plan9/plan9-2014-05-15.diff), and recompile/reinstall/reboot your kernel. -- David du Colombier
Re: [9fans] syscall 53
note to self: add /dev/sdE?/9fat to vac streamline getting 9LOAD in place w/o corruption
Re: [9fans] syscall 53
i got the impression that sources were in some inconsistent state. if the only change is the new system call, isn't it sufficient to: * pull only /sys/src/9 * build the kernels you need and install on boot medium * reboot * pull again and rebuild all the binaries since existing binaries would work on the new kernel? On Sun, May 18, 2014 at 1:29 AM, David du Colombier <0in...@gmail.com>wrote: > The safe way to upgrade your file server is simply to update the kernel > binaries (for example, with the ones I'm providing) on your 9fat and reboot. > > Then, you can pull the updated program binaries from /n/sources. > > There is no need to wait, because you have to be running the new kernel > before pulling the new binaires anyway. > > In the case you need a custom kernel to boot your file server, you will > have to grab the changes manually (like > http://9fans.eu/pegasus/sources/plan9/plan9-2014-05-15.diff), and > recompile/reinstall/reboot your kernel. > > -- > David du Colombier >
Re: [9fans] syscall 53
0intro's last paragraph says the same thing. On Sun, May 18, 2014 at 8:32 AM, Skip Tavakkolian < skip.tavakkol...@gmail.com> wrote: > i got the impression that sources were in some inconsistent state. > > if the only change is the new system call, isn't it sufficient to: > > * pull only /sys/src/9 > * build the kernels you need and install on boot medium > * reboot > * pull again and rebuild all the binaries > > since existing binaries would work on the new kernel? > > > > On Sun, May 18, 2014 at 1:29 AM, David du Colombier <0in...@gmail.com>wrote: > >> The safe way to upgrade your file server is simply to update the kernel >> binaries (for example, with the ones I'm providing) on your 9fat and reboot. >> >> Then, you can pull the updated program binaries from /n/sources. >> >> There is no need to wait, because you have to be running the new kernel >> before pulling the new binaires anyway. >> >> In the case you need a custom kernel to boot your file server, you will >> have to grab the changes manually (like >> http://9fans.eu/pegasus/sources/plan9/plan9-2014-05-15.diff), and >> recompile/reinstall/reboot your kernel. >> >> -- >> David du Colombier >> > >
Re: [9fans] syscall 53
> * pull only /sys/src/9 * pull -s sys/src/libc > * build the kernels you need and install on boot medium > * reboot I recovered by using 9fs snap so I could get an earlier state of /386. 9fs dump triggered the syscall error.
Re: [9fans] syscall 53
rebuilding/installing the binaries from local sources takes very little time and guarantees that pull will not overwrite them (unless forced). On Sun, May 18, 2014 at 8:38 AM, Jeff Sickel wrote: > > > * pull only /sys/src/9 > > * pull -s sys/src/libc > > > * build the kernels you need and install on boot medium > > * reboot > > > I recovered by using 9fs snap so I could get an earlier state > of /386. 9fs dump triggered the syscall error. > > > >
Re: [9fans] syscall 53
fyi, pulling/merging (e.g. adding IL back), building the kernels, booting and building the binaries works as expected for all cpu types in my environment (pc, bcm, rb and kw). On Sun, May 18, 2014 at 9:03 AM, Skip Tavakkolian < skip.tavakkol...@gmail.com> wrote: > rebuilding/installing the binaries from local sources takes very little > time and guarantees that pull will not overwrite them (unless forced). > > > > On Sun, May 18, 2014 at 8:38 AM, Jeff Sickel wrote: > >> >> > * pull only /sys/src/9 >> >> * pull -s sys/src/libc >> >> > * build the kernels you need and install on boot medium >> > * reboot >> >> >> I recovered by using 9fs snap so I could get an earlier state >> of /386. 9fs dump triggered the syscall error. >> >> >> >> >
Re: [9fans] syscall 53
On Sun May 18 18:56:49 EDT 2014, skip.tavakkol...@gmail.com wrote: > fyi, pulling/merging (e.g. adding IL back), building the kernels, booting > and building the binaries works as expected for all cpu types in my > environment (pc, bcm, rb and kw). i'd put a vote into restoring il to the standard kernels. there's no downside. - erik
Re: [9fans] syscall 53
On May 18, 2014, at 8:54 PM, erik quanstrom wrote: > On Sun May 18 18:56:49 EDT 2014, skip.tavakkol...@gmail.com wrote: > >> fyi, pulling/merging (e.g. adding IL back), building the kernels, booting >> and building the binaries works as expected for all cpu types in my >> environment (pc, bcm, rb and kw). > > i'd put a vote into restoring il to the standard kernels. there's no > downside. I vote getting ether82563.c updated. I’m merging, but not done yet. The big fail was my auth server sitting on a Soekris net6501. Great machine, on 9atom. Plan 9 faults if you try to boot it w/o *nomp=1. And when you do boot it w/ *nomp=1, Plan 9 doesn’t recognize the mSATA device in it, which kind of ruins the whole idea of using it as an auth server. -jas
Re: [9fans] syscall 53
> i'd put a vote into restoring il to the standard kernels. there's no > downside. My vote, too. ++L
Re: [9fans] syscall 53
> Great > machine, on 9atom. Which raises another question: are 9atom and 9front in synch with the BL distribution (itself in question) regarding syscall 53? ++L
