Re: [9fans] usbd problem
Hello, Thank you for working for usb support. In trying usb/disk I have a question: term% usb/disk term% disk/partfs /n/disk/0/data term% disk/mbr /dev/sdXX/data term% disk/fdisk -baw /dev/sdXX/data term% disk/prep /dev/sdXX/plan9 empty0 2 (2 sectors, 1.00 KB) 9fat 2 3 (29998 sectors, 14.64 MB) fs 3 256913(226913 sectors, 110.79 MB) nvram 256913 256914(1 sectors, 512 B ) >>> q term% ls -l /dev/sdXX /dev/sdXX/ctl /dev/sdXX/data /dev/sdXX/plan9 term% Where is 9fat, fs and nvram created by disk/prep? Kenji Arisawa
Re: [9fans] Can't find CD-ROM
Take a look at Qemu Manager: http://www.davereyn.co.uk/about.htm 2008/2/12, Chris Saunders <[EMAIL PROTECTED]>: > Thanks, I have downloaded but not yet installed QEMU. I will try this soon. > > Regards > Chris Saunders > > "Eris Discordia" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > On Mon, 11 Feb 2008 14:54:20 -, Chris Saunders > > <[EMAIL PROTECTED]> wrote: > > > >> As far as I know there is no Open dialog box in Plan9. > > > > Not in Plan 9. I thought you might be getting the Virtual PC settings > > wrong and was referring to the settings on the menu bar on top of your > > virtual machine window (which belongs to VPC). > > > >> I have several times brought the instalation up to > >> this point and the installer suggests that the install image should be at > >> /dev/sdD0/data. > > > > > > If you have come this far, it is clear I was wrong. The install image is > > indeed where the installer suggests, at /dev/sdD0/data. > > > > I guess you get the problem later on when you are asked (by the Plan 9 > > installer) to "browse" for the distribution (at the copydist stage of the > > installation). At that point, having supplied /dev/sdD0/data as your data > > source before, you have to tell the installer to look in the / directory > > of the image for the distribution to copy. Just type in "/" (without the > > quotes) there. > > > > I think it is acceptable to reiterate that: "Plan 9 does NOT work on VPC's > > current version. Try QEMU instead." I have the latest version of VPC for > > Windows XP x64 and no amount of usual tweaking would make Plan 9 work on > > it. The installation finishes but the installed system will not boot past > > the startup scripts. Yours will probably fail, too. My two cents of > > failure :-) > > > > -- > > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > >
Re: [9fans] Re: Booting problem after fresh install from 20080203 iso.
> I'll take a look, but I'm afraid it's not going to help. I've already > tried NetBSD's MBR and Plan 9's MBR (using disk/mbr), and they both > don't fix the problem. That makes two of us. I have the same problem with compact flash devices. If I don't get the geometry exactly right (I did, a couple of times, bu no more) the devices are positively useless. And I cannot figure out why a while back I could find the right geometry it and now I have no idea how. Just like you. And, ironically, that may be your problem, too. ++L
Re: [9fans] usbd problem
thanks for the update. i have switched to a slightly more agreeable key but i have a new way to fail. the key works the first time. but the second time i connect the same key, i get ; usbfat: setupreq: write err: No response usb/disk: describedevice: error writing usb device request: get device descriptor: No response No response mount: mount /n/usb: unknown format initially in this state, i could restart usbd and got this information. ; usb/usbd -fvD usbd: probing usb2/0.1 usbd: probing usb3/0.1 usbd: probing usb4/0.1 usbd: probing usb0/0.1 out 5 [8] 80 06 00 01 00 00 08 00 in 5 [8] 12 01 00 02 00 00 00 40 usb1/0.1 maxpkt: 64 out 5 [8] 00 05 02 00 00 00 00 00 describedevice out 24 [8] 80 06 00 01 00 00 18 00 in 24 [18] 12 01 00 02 00 00 00 40 ec 08 08 00 00 01 01 02 03 01 loadconfig out 24 [8] 80 06 00 02 00 00 ff 03 in 24 [32] 09 02 20 00 01 01 00 80 64 09 04 00 00 02 08 06 50 00 07 05 81 02 40 00 00 07 05 02 02 40 00 00 out 24 [8] 00 09 01 00 00 00 00 00 checking usb1/0.1 ... but two devices (1 and 2) with the identical status files existed. i've got things pretty wedged now -- usbd won't start so it's hard to get much more information. but i did get two "done > started, 1 0" messages on the console. sorry for the poor bug report. - erik
Re: [9fans] usbd problem
We added booting via the BIOS to 9load specifically for USB (though it may have other uses), so that we wouldn't have to add to 9load and maintain 8,000 lines, and growing, of complex USB code (though that's likely due to the inherent complexity of USB rather than being the fault of those who have contributed USB code). See sdB0 and bios0 in 9load(8). The BIOSes have been somewhat uncooperative, but if you make a USB floppy or USB disk be the first item in your BIOS boot order, remove *nobiosload=something from your plan9.ini, see the example in prep(8) for how to prepare such a USB disk, and the phase of the moon is right, it should work. It's worked here for us. If we get an EHCI driver written, this will all become much more interesting.
Re: [9fans] usbd problem
> geoff pointed out that usb/disk pulls in a lot of stuff and might need > some work to run in the kernel. Usb root can be done by putting usb/disk and usb/usbd into /boot and hacking /sys/src/9/boot/local.c a bit. I tried it once and it worked albeit slowly. However, getting 9load to use usb disk would be a bigger task.
Re: [9fans] usbd problem
> Do you mean why doesn't the ctl file accept partition commands? > You can always use fs(3) for that. But usb root is not very > practical anyway, at least with uhci, because of a stubborn > bug in the driver which makes transfers very very slow. Now > there's ohci support I would be interested to know if that works > at more like normal usb speed. you're assuming that i want to continue to do i/o once i've booted. :-) the basic problem is that, e.g., ich9r boards have no pata at all. it used to be easy to boot from CF or a DOM. but that's becoming more of a problem. booting from usb might be the only cheep solid-state choice. geoff pointed out that usb/disk pulls in a lot of stuff and might need some work to run in the kernel. so perhaps i don't fully appreciate how interconnected /dev/usb?, usb/usbd, and usb/disk. i was under the impression that usb/disk was just a bit of glue that turns an endpoint into a block device. - erik
Re: [9fans] usbd problem
> Actually, partfs(8) provides devsd-compatible partitions Cool - I hadn't noticed when that appeared.
Re: [9fans] usbd problem
Actually, partfs(8) provides devsd-compatible partitions and is probably a better choice for this than fs(3). It wasn't cited in usbdisk(4)'s SEE ALSO, but it is now.
Re: [9fans] usbd problem
> one final question, is there an advantage to usb/disk creating a fs > that's incompatable with devsd? it would seem to make booting > from usb root difficult. Do you mean why doesn't the ctl file accept partition commands? You can always use fs(3) for that. But usb root is not very practical anyway, at least with uhci, because of a stubborn bug in the driver which makes transfers very very slow. Now there's ohci support I would be interested to know if that works at more like normal usb speed.
Re: [9fans] Re: Booting problem after fresh install from 20080203 iso.
On Feb 12, 2008 10:19 AM, <[EMAIL PROTECTED]> wrote: > > 1. I zeroed the target harddisk before installation like this: "dd -if > > /dev/zero -of /dev/sdC1/data". > > You wiped out the MBR on the disk, use DOS's FDISK/MBR (sic) to > restore it, it is the least painful way to fix this type of problem, > in my experience. I'll take a look, but I'm afraid it's not going to help. I've already tried NetBSD's MBR and Plan 9's MBR (using disk/mbr), and they both don't fix the problem. I've got the feeling that the problem has something to do with the addressing that the Plan 9 partition's boot block uses (When I install /386/pbslba it works, with /386/pbs it doesn't). So why don't I just install /386/pbslba then? Because a week ago, /386/pbs was working on this machine, and now all the sudden it isn't, and I can't stand that I can't explain why... Anyway, thanks for your suggestion, I'll give it a go and see if it helps. Greetings, Sander.
Re: [9fans] 9pfuse adventure
On Feb 9, 2008 4:25 AM, Russ Cox <[EMAIL PROTECTED]> wrote: > > provide any facility to attach as a different user. So, I modified the > > attach strategy to look for a USER environment variable before falling > > back on getuser(). I've attached the diff, hopefully I got everything. > > The name in the attach is almost just a comment. > What matters is the name used inside the authentication > protocol. (The name in the attach is really only there for > non-authenticated connections.) So these changes > shouldn't be necessary. Hm, I guess u9fs is misbehaving then? > This is the problem: you should never be prompted for a > role=speakfor key. You should be prompted for a role=client key. > If that happened correctly then I think things would have just > worked. Try pre-loading a role=client key into factotum and > see if that works better. I'm pretty sure I did have a role=client key in factotum in my previous attempts, added by drawterm (I have a cpu/authserver on my home network aswell, with the same user/pass/dom as my u9fs.key). I reran the tests to be sure, the log is below. It turns out I only get asked for a speakfor key when using my modified USER code, but it's still the only way I've got a usable connection. I had a quick look at u9fs and it does appear to be checking against the Tattach uname in p9anyattach(), but if that check was failing I should be getting "authentication failed" not "unknown user". Um, but that was a pretty silly place to look anyway. There's only one place "unknown user" is actually returned, and that is after uname2user fails in rattach() (which was probably the original reason for my USER hack). I suspect there is no good solution here since if you called uname2user() on the auth username, every user would connect with the same permissions (I assume everyone connecting needs an auth key matching /etc/u9fs.key?). Maybe it would work with tighter coupling with the auth server? I never fully grasped the reason behind /etc/u9fs.key... Otherwise, u9fs needs to be told remotely what uid to use. $ 9p read factotum/ctl key dom=sqweek.dnsdojo.org proto=p9sk1 role=client user=sqweek !password? $ rm `namespace`/wren $ srv -a sqweek.dnsdojo.org wren $ 9p ls wren/ 9p: mount: unknown user $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/ /opt/plan9/src/cmd/o.9p: mount: unknown user $ rm `namespace`/wren $ srv sqweek.dnsdojo.org wren $ 9p ls wren/ 9p: mount: unknown user $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/ !adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org -sqweek, thinking he should probably have set inferno up a long time ago
Re: [9fans] s3venti
> For the record, s3venti does encrypt blocks that it writes to S3. It > uses a single key, making it rather vulnerable to dictionary attacks, > but I haven't come up with a way to do better without changing the > venti protocol. Suggestions are welcome. Beware: I am no security expert, I know just enough to be dangerous. Ensure you have plenty of entropy - insist on long pass phrases. sha1 this with the block number to give you the key for a particular block. This at least permutes the venti tree info blocks - its real purpose is to ensure the duplicate blocks look different when encrypted but venti doesn't have duplicate blocks as such. you could repeat the sha1 as it may be possible to infer some info given all the sha1s start with the same (or known) prefix - the pass phrase (or block number). If you are likely to have multiple ventis with the same password on the server (one for work stuff and one for home) then stir a random string into the sha1, and keep this in factotum; generate this string when the venti is initialised. your venti blocks are compressed which gives you some obscurity, guessing plaintext is not so easy but huffman tables and the like still stand out. If you want to be obsessive you could generate a block of random data, say 64k which you hold locally and xor this with your venti blocks before encryption. offset your start position in the random data by a value generated from the sha1(sha1(blocknumber, passphrase)) (eg the checksum), this would make cracking your data much harder. Note this block of random data needs to be really random, not a PRBS like rand() which is predictable. you could slowly suck bytes from /dev/random on a busy machine. as ever its a case of: how valuable is it? how long to you want to keep it secret? who are you trying to keep it secret from? caveat emptor -Steve
Re: [9fans] Re: Booting problem after fresh install from 20080203 iso.
> 1. I zeroed the target harddisk before installation like this: "dd -if > /dev/zero -of /dev/sdC1/data". You wiped out the MBR on the disk, use DOS's FDISK/MBR (sic) to restore it, it is the least painful way to fix this type of problem, in my experience. ++L
Re: [9fans] usbd problem
Warning!, the dump.c I sent Sape has a bug.
search for "len = b[0]-1", in pdesc(), replace that with
"len = b[0]".
sorry for the mistake.
> From: [EMAIL PROTECTED]
> To: 9fans@cse.psu.edu
> Reply-To: 9fans@cse.psu.edu
> Date: Tue Feb 12 15:36:36 CET 2008
> Subject: Re: [9fans] usbd problem
>
> >> Nemo found a bug in usb/lib/dump.c that may well account for
> >> this. I incorporated his change (and fixed a bug in his code :-).
> >> I'll ask Geoff to push it out today.
> >>
> >> Sape
> >
> > excellent. i'll give it a shot.
> >
> > - erik
>
> Give it a shot now:
> /sys/src/cmd/usb/lib/dump.c
>
>
> !— dump.c.txt
>
> #include
> #include
> #include
> #include
> #include "usb.h"
>
> int verbose;
>
> typedef struct Flags Flags;
> typedef struct Classes Classes;
>
> struct Flags {
> int bit;
> char* name0;
> char* name1;
> };
>
> struct Classes {
> char* name;
> struct {
> char* name;
> char* proto[4];
> } subclass[4];
> };
>
> static Classes classname[] = {
> [CL_AUDIO] {"audio", {[1]{"control"}, [2]{"stream"},
> [3]{"midi"}}},
> [CL_COMMS] {"comms", {[1] {"abstract", {[1]"AT",
> [CL_HID]{"hid", {[1] {"boot", {[1]"kbd", [2]"mouse",
> [CL_PRINTER]{"printer", {[1]"printer", {[1]"uni", [2]"bi"}}},
> [CL_HUB]{"hub", {[1]{"hub"}}},
> [CL_DATA] {"data"},
> };
>
> static voidpflag(Flags*, uint);
>
> char *
> sclass(char *p, char *e, ulong csp)
> {
> Classes *cs;
> int c, s, pr;
>
> c = Class(csp);
> s = Subclass(csp);
> pr = Proto(csp);
> if(c < 0 || c >= nelem(classname) || (cs = &classname[c])->name == nil)
> return seprint(p, e, "%d.%d.%d", c, s, pr);
> p = seprint(p, e, "%s.", cs->name);
> if(s < 0 || s >= nelem(cs->subclass) || cs->subclass[s].name == nil)
> p = seprint(p, e, "%d.%d", s, pr);
> else{
> p = seprint(p, e, "%s.", cs->subclass[s].name);
> if(pr < 0 || pr >= nelem(cs->subclass[s].proto) ||
> cs->subclass[s].proto[pr] == nil)
> p = seprint(p, e, "%d", pr);
> else
> p = seprint(p, e, "%s", cs->subclass[s].proto[pr]);
> }
> return p;
> }
>
> void
> pdevice(Device *, int, ulong, void *b, int n)
> {
> DDevice *d;
> char scbuf[64];
>
> if(n < DDEVLEN)
> return;
> d = b;
> if(debug & Dbginfo) {
> fprint(2, "usb (bcd)%c%c%c%c",
> '0'+((d->bcdUSB[1]>>4)&0xf),
> '0'+(d->bcdUSB[1]&0xf),
> '0'+((d->bcdUSB[0]>>4)&0xf),
> '0'+(d->bcdUSB[0]&0xf));
> sclass(scbuf, scbuf + sizeof scbuf,
> CSP(d->bDeviceClass, d->bDeviceSubClass,
> d->bDeviceProtocol)),
> fprint(2, " class %d subclass %d proto %d [%s] max0 %d",
> d->bDeviceClass, d->bDeviceSubClass, d->bDeviceProtocol,
> scbuf,
> d->bMaxPacketSize0);
> fprint(2, " vendor %#x product %#x device (bcd)%c%c%c%c",
> GET2(d->idVendor), GET2(d->idProduct),
> '0'+((d->bcdDevice[1]>>4)&0xf),
> '0'+(d->bcdDevice[1]&0xf),
> '0'+((d->bcdDevice[0]>>4)&0xf),
> '0'+(d->bcdDevice[0]&0xf));
> fprint(2, " man %d prod %d serial %d nconfig %d",
> d->iManufacturer, d->iProduct, d->iSerialNumber,
> d->bNumConfigurations);
> }
> }
>
> void
> phid(Device *, int, ulong, void *b, int n)
> {
> DHid *d;
>
> if(n < DHIDLEN){
> fprint(2, "%s: hid too short\n", argv0);
> return;
> }
> d = b;
> if(debug & Dbginfo)
> fprint(2, "HID (bcd)%c%c%c%c country %d nhidclass %d classdtype
> %#x dlen %d\n",
> '0'+((d->bcdHID[1]>>4)&0xf), '0'+(d->bcdHID[1]&0xf),
> '0'+((d->bcdHID[0]>>4)&0xf), '0'+(d->bcdHID[0]&0xf),
> d->bCountryCode, d->bNumDescriptors,
> d->bClassDescriptorType, GET2(d->wItemLength));
> }
>
> static Flags ioflags[] = {
> {0, "Data", "Constant"},
> {1, "Array", "Variable"},
> {2, "Absolute", "Relative"},
> {3, "NoWrap", "Wrap"},
> {4, "Linear", "NonLinear"},
> {5, "PreferredState", "No Preferred State"},
> {6, "No Null position", "Null state"},
> {7, "Non Volatile", "Volatile"},
> {8, "Bit Field", "Buffered Bytes"},
> {-1, nil, nil},
> };
>
> static void
> pflag(Flags *tab, uint v)
> {
> char buf[200], *s;
> int n;
>
> n = 0;
> buf[0] = 0;
> for(; tab->name0 != nil; tab++){
>
Re: [9fans] usbd problem
>> Nemo found a bug in usb/lib/dump.c that may well account for
>> this. I incorporated his change (and fixed a bug in his code :-).
>> I'll ask Geoff to push it out today.
>>
>> Sape
>
> excellent. i'll give it a shot.
>
> - erik
Give it a shot now:
/sys/src/cmd/usb/lib/dump.c
#include
#include
#include
#include
#include "usb.h"
int verbose;
typedef struct Flags Flags;
typedef struct Classes Classes;
struct Flags {
int bit;
char* name0;
char* name1;
};
struct Classes {
char* name;
struct {
char* name;
char* proto[4];
} subclass[4];
};
static Classes classname[] = {
[CL_AUDIO] {"audio", {[1]{"control"}, [2]{"stream"},
[3]{"midi"}}},
[CL_COMMS] {"comms", {[1] {"abstract", {[1]"AT",
[CL_HID]{"hid", {[1] {"boot", {[1]"kbd", [2]"mouse",
[CL_PRINTER]{"printer", {[1]"printer", {[1]"uni", [2]"bi"}}},
[CL_HUB]{"hub", {[1]{"hub"}}},
[CL_DATA] {"data"},
};
static voidpflag(Flags*, uint);
char *
sclass(char *p, char *e, ulong csp)
{
Classes *cs;
int c, s, pr;
c = Class(csp);
s = Subclass(csp);
pr = Proto(csp);
if(c < 0 || c >= nelem(classname) || (cs = &classname[c])->name == nil)
return seprint(p, e, "%d.%d.%d", c, s, pr);
p = seprint(p, e, "%s.", cs->name);
if(s < 0 || s >= nelem(cs->subclass) || cs->subclass[s].name == nil)
p = seprint(p, e, "%d.%d", s, pr);
else{
p = seprint(p, e, "%s.", cs->subclass[s].name);
if(pr < 0 || pr >= nelem(cs->subclass[s].proto) ||
cs->subclass[s].proto[pr] == nil)
p = seprint(p, e, "%d", pr);
else
p = seprint(p, e, "%s", cs->subclass[s].proto[pr]);
}
return p;
}
void
pdevice(Device *, int, ulong, void *b, int n)
{
DDevice *d;
char scbuf[64];
if(n < DDEVLEN)
return;
d = b;
if(debug & Dbginfo) {
fprint(2, "usb (bcd)%c%c%c%c",
'0'+((d->bcdUSB[1]>>4)&0xf),
'0'+(d->bcdUSB[1]&0xf),
'0'+((d->bcdUSB[0]>>4)&0xf),
'0'+(d->bcdUSB[0]&0xf));
sclass(scbuf, scbuf + sizeof scbuf,
CSP(d->bDeviceClass, d->bDeviceSubClass,
d->bDeviceProtocol)),
fprint(2, " class %d subclass %d proto %d [%s] max0 %d",
d->bDeviceClass, d->bDeviceSubClass, d->bDeviceProtocol,
scbuf,
d->bMaxPacketSize0);
fprint(2, " vendor %#x product %#x device (bcd)%c%c%c%c",
GET2(d->idVendor), GET2(d->idProduct),
'0'+((d->bcdDevice[1]>>4)&0xf),
'0'+(d->bcdDevice[1]&0xf),
'0'+((d->bcdDevice[0]>>4)&0xf),
'0'+(d->bcdDevice[0]&0xf));
fprint(2, " man %d prod %d serial %d nconfig %d",
d->iManufacturer, d->iProduct, d->iSerialNumber,
d->bNumConfigurations);
}
}
void
phid(Device *, int, ulong, void *b, int n)
{
DHid *d;
if(n < DHIDLEN){
fprint(2, "%s: hid too short\n", argv0);
return;
}
d = b;
if(debug & Dbginfo)
fprint(2, "HID (bcd)%c%c%c%c country %d nhidclass %d classdtype
%#x dlen %d\n",
'0'+((d->bcdHID[1]>>4)&0xf), '0'+(d->bcdHID[1]&0xf),
'0'+((d->bcdHID[0]>>4)&0xf), '0'+(d->bcdHID[0]&0xf),
d->bCountryCode, d->bNumDescriptors,
d->bClassDescriptorType, GET2(d->wItemLength));
}
static Flags ioflags[] = {
{0, "Data", "Constant"},
{1, "Array", "Variable"},
{2, "Absolute", "Relative"},
{3, "NoWrap", "Wrap"},
{4, "Linear", "NonLinear"},
{5, "PreferredState", "No Preferred State"},
{6, "No Null position", "Null state"},
{7, "Non Volatile", "Volatile"},
{8, "Bit Field", "Buffered Bytes"},
{-1, nil, nil},
};
static void
pflag(Flags *tab, uint v)
{
char buf[200], *s;
int n;
n = 0;
buf[0] = 0;
for(; tab->name0 != nil; tab++){
if(v & (1name1;
else
s = tab->name0;
if(s != nil && *s)
n += snprint(buf+n, sizeof(buf)-n, ", %s", s);
}
if((debug & Dbginfo) && buf[0])
fprint(2, "[%s]", buf+2);
}
void
preport(Device *, int, ulong, byte *b, int n)
{
byte *s, *es;
int tag, nb, i, indent;
int v;
Flags *tab;
s = b+2;
es = b+n;
indent = 0;
w
Re: [9fans] usbd problem
> Nemo found a bug in usb/lib/dump.c that may well account for > this. I incorporated his change (and fixed a bug in his code :-). > I'll ask Geoff to push it out today. > > Sape excellent. i'll give it a shot. - erik
Re: [9fans] usbd problem
> usbd is exiting when i have a camera which is off > attached: > > ; usb/usbd -v > ; echo $status > usbd 1827: usbd: setup0: usb0/1: transaction error > > - erik Nemo found a bug in usb/lib/dump.c that may well account for this. I incorporated his change (and fixed a bug in his code :-). I'll ask Geoff to push it out today. Sape
Re: [9fans] Re: Booting problem after fresh install from 20080203 iso.
> I believe my writing turns out a bit unclear. What I meant to say was > that I actually did a "dd -if /dev/zero -f /dev/sdC1/raw" before I > figured out that it should have been "dd -if /dev/zero -of > /dev/sdC1/data" instead. Hence I was wondering if writing those zeroes > to the raw file could be the source of my problem (in case those > zeroes translate to a command I really shouldn't have given), because > this is one of the things I did right before the problem appeared. > Anyway, thanks for the reference, I'll take a look at scuzz(8). p. 361 ata 6.1 notes that command 0 is NOP. ata nop does put the drive into an error state so it could have screwed things up into you reboot. it shouldn't, but you'd have to trace through the code to prove it doesn't. - erik
Re: [9fans] Re: Booting problem after fresh install from 20080203 iso.
On Feb 12, 2008 1:50 PM, erik quanstrom <[EMAIL PROTECTED]> wrote: > > 1. I zeroed the target harddisk before installation like this: "dd -if > > /dev/zero -of /dev/sdC1/data". > > 2. I also accidentally did this first when I really meant to zero the > > disk: "dd -if /dev/zero -f /dev/sdC1/raw". > > you did the right thing. the raw file is for issuing raw commands to > the drive. (not raw like you're thinking. they're raw scsi commands > which might be translated (loosely) into ata.) see scuzz(8). I believe my writing turns out a bit unclear. What I meant to say was that I actually did a "dd -if /dev/zero -f /dev/sdC1/raw" before I figured out that it should have been "dd -if /dev/zero -of /dev/sdC1/data" instead. Hence I was wondering if writing those zeroes to the raw file could be the source of my problem (in case those zeroes translate to a command I really shouldn't have given), because this is one of the things I did right before the problem appeared. Anyway, thanks for the reference, I'll take a look at scuzz(8). Greetings, Sander.
Re: [9fans] usbd problem
> Looking at /sys/src/cmd/usb/usbd/usbd.c, I wonder whether > your problem has something to do with these lines? > > //unconscionable kludge (testing camera) > if(d->class == 10) setup0(d, RH2D|Rinterface, SET_INTERFACE, 10, 0, 0); thanks for the suggestion, but the camera was a red herring. it was actually the usb key that i'd plugged in. the key works fine with xp. so i engineered a swap of usb keys. it was dying in setup0 with Estalled. shouldn't usbd be resistant to badly-behaving devices? it seems that any error on any endpoint will topple usbd, at least during configure. one final question, is there an advantage to usb/disk creating a fs that's incompatable with devsd? it would seem to make booting from usb root difficult. - erik
Re: [9fans] Re: Booting problem after fresh install from 20080203 iso.
> 1. I zeroed the target harddisk before installation like this: "dd -if > /dev/zero -of /dev/sdC1/data". > 2. I also accidentally did this first when I really meant to zero the > disk: "dd -if /dev/zero -f /dev/sdC1/raw". you did the right thing. the raw file is for issuing raw commands to the drive. (not raw like you're thinking. they're raw scsi commands which might be translated (loosely) into ata.) see scuzz(8). - erik
Re: [9fans] s3venti
> You could reduce your storage bill by using file names to store the data > through information hiding rather than the content ;) > > http://www.geocities.com/patchnpuki/other/compression.htm > > One of these days .. my reading of the sla seemed to indicate they count bucket names against you. - erik
Re: [9fans] How to move to rc from sh/bash
* Uriel ([EMAIL PROTECTED]) wrote: > It is more likely that the information you want is not even in the man > page, gnu man pages are severely crippled, and if you want the real > documentation you have to travel to info hell which is likely to > contain ten times as much (mis)information and be ten times harder to > browse. > > And there you have the greatest innovation GNU has ever brought to > unix, in gnu systems I rarely even bother checking the docs, because > even random trial and error usually takes much less effort than > navigating the fetid info swamp. > > uriel Damn, I was just going to ignore that mess.
Re: [9fans] s3venti
You could reduce your storage bill by using file names to store the data through information hiding rather than the content ;) http://www.geocities.com/patchnpuki/other/compression.htm One of these days ..
Re: [9fans] usbd problem
Looking at /sys/src/cmd/usb/usbd/usbd.c, I wonder whether your problem has something to do with these lines? //unconscionable kludge (testing camera) if(d->class == 10) setup0(d, RH2D|Rinterface, SET_INTERFACE, 10, 0, 0);
Re: [9fans] Can't find CD-ROM
Thanks, I have downloaded but not yet installed QEMU. I will try this soon. Regards Chris Saunders "Eris Discordia" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Mon, 11 Feb 2008 14:54:20 -, Chris Saunders > <[EMAIL PROTECTED]> wrote: > >> As far as I know there is no Open dialog box in Plan9. > > Not in Plan 9. I thought you might be getting the Virtual PC settings > wrong and was referring to the settings on the menu bar on top of your > virtual machine window (which belongs to VPC). > >> I have several times brought the instalation up to >> this point and the installer suggests that the install image should be at >> /dev/sdD0/data. > > > If you have come this far, it is clear I was wrong. The install image is > indeed where the installer suggests, at /dev/sdD0/data. > > I guess you get the problem later on when you are asked (by the Plan 9 > installer) to "browse" for the distribution (at the copydist stage of the > installation). At that point, having supplied /dev/sdD0/data as your data > source before, you have to tell the installer to look in the / directory > of the image for the distribution to copy. Just type in "/" (without the > quotes) there. > > I think it is acceptable to reiterate that: "Plan 9 does NOT work on VPC's > current version. Try QEMU instead." I have the latest version of VPC for > Windows XP x64 and no amount of usual tweaking would make Plan 9 work on > it. The installation finishes but the installed system will not boot past > the startup scripts. Yours will probably fail, too. My two cents of > failure :-) > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [9fans] s3venti
Richard Bilson <[EMAIL PROTECTED]> schrieb: >> and an issue related to the >> fact that we need to encrypt users' data. > > For the record, s3venti does encrypt blocks that it writes to S3. It > uses a single key, making it rather vulnerable to dictionary attacks, > but I haven't come up with a way to do better without changing the > venti protocol. Suggestions are welcome. Any sort of encryption which does not change the key from time to time is not very secure. If the attacker has enough time, security is not easy to get. I propose to divide the files to store, e.g. into upper and lower 4bit nibbles and put them into different places. In this case both halves are likely to be less worthy for themselves, and much more difficult to decipher, too. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key
[9fans] Re: Booting problem after fresh install from 20080203 iso.
It's getting stranger. I just did a fresh install from the 20071222 image (from which I've done a succesfull install on the same machine and disk before), and it gives me the same error. Two things that I haven't mentioned before and that may be relevant are these: 1. I zeroed the target harddisk before installation like this: "dd -if /dev/zero -of /dev/sdC1/data". 2. I also accidentally did this first when I really meant to zero the disk: "dd -if /dev/zero -f /dev/sdC1/raw". Does anyone know if either of these (specifically number 2) could have caused my issue? I'm not sure what (if anything) number two did. Greetings, Sander.
Re: [9fans] usbd problem
> ; usb/usbd -v Try 'usb/usbd -d1' for more information.
