Re: [9fans] running plan9 : an ideal setup?
Could it be that snapshots induce the same type of wear and tear on the SD as atime? --Dante On 28.11.2014 07:54, David du Colombier wrote: fossil has no option to disable atime, but kfs does. The Fossil open command takes the option -a to disable atime. -- David du Colombier
Re: [9fans] running plan9 : an ideal setup?
The Fossil open command takes the option -a to disable atime. ... and that's the default on the 9pi distribution image. term% fossil/conf /dev/sdM0/fossil | grep open fsys main open -Va
Re: [9fans] running plan9 : an ideal setup?
The unfortunate one was a Scandisk Ultra 32GB, which I suppose is of very good quality. On 28.11.2014 10:12, Mats Olsson wrote: I have to agree with Erik when it comes to SD cards. I've used and abused many SD cards for years and have never had problems with them. I could recommend Sandisk Expert Pro that comes with a limited lifetime warranty (at least in Sweden). They are fast, up to 95 mb/s, and very reliable according to my experience. 2014-11-28 9:42 GMT+01:00, Dante subscripti...@posteo.eu: Could it be that snapshots induce the same type of wear and tear on the SD as atime? --Dante On 28.11.2014 07:54, David du Colombier wrote: fossil has no option to disable atime, but kfs does. The Fossil open command takes the option -a to disable atime. -- David du Colombier
Re: [9fans] running plan9 : an ideal setup?
Check, my SD's fossil also had an -a: fsys main open -aAV Thanks, I forgot how I configured it. But now what did it happen? We have a Plan9 doing nothing on my desktop. What does it write to the SD?? On 28.11.2014 10:17, Richard Miller wrote: The Fossil open command takes the option -a to disable atime. ... and that's the default on the 9pi distribution image. term% fossil/conf /dev/sdM0/fossil | grep open fsys main open -Va
Re: [9fans] running plan9 : an ideal setup?
On Fri Nov 28 01:15:32 PST 2014, 9f...@hamnavoe.com wrote: The Fossil open command takes the option -a to disable atime. ... and that's the default on the 9pi distribution image. term% fossil/conf /dev/sdM0/fossil | grep open fsys main open -Va oops. my bad. but... atta; man fossil | grep -i atime atta; atta; man fossilcons | grep -i atime atta; - erik
Re: [9fans] running plan9 : an ideal setup?
oops. my bad. but... atta; man fossil | grep -i atime atta; atta; man fossilcons | grep -i atime atta; You should have written: % man fossilcons | grep -i 'access time' -a do not update file access times; primarily to ☺ As far I remember, Geoff added this option when he implemented support for USB disk boot in 2011. -- David du Colombier
Re: [9fans] running plan9 : an ideal setup?
On Thu Nov 27 12:55:40 PST 2014, subscripti...@posteo.eu wrote: So, I didn't get too far with my tests, except for what apparently is a dead SD card, after about 3 Months uptime doing nothing. This is not stellar compared with more than on year uptime with no problems for a Linux running on the same Raspberry Pi (other SD card). Does Plan9 record the access times of files? Could this be a reason for the dead SD cards? Is there any way to disable recording atimes? Please note that the Linux experiment ran with atime disabled. If this is the problem, I could install Plan9 onto a magnetic USB disk and only boot from the SD. What do you folks think? fossil has no option to disable atime, but kfs does. now, i've run on rpi-based systems for some time with no issue, and it would be a mistake i think to assume that all sd cards are created equal. - erik
Re: [9fans] running plan9 : an ideal setup?
fossil has no option to disable atime, but kfs does. The Fossil open command takes the option -a to disable atime. -- David du Colombier
Re: [9fans] running plan9 : an ideal setup?
Hi dante! I copied your piclone script in Plan 9 but even though I've been digging I can't find out how to get the name of the SD card attached to the pi on which I want to clone my setup on. So, easily put, what command do I use to get to know that? So I wonder how to get the device name of the clean SD in the USB card adapter. In your post first mentioning the script you wrote: If the device is recognized as sdUXX, call piclone sdUXX. Well that is what I want to find out. If I get that I'm ready to rock and roll. Kind Greetings, Mats 2014-11-18 23:09 GMT+01:00, dante subscripti...@posteo.eu: Hi Mats, I posted it before; unfortunately the archive doesn't save the attached files. Here is the original post: http://9fans.net/archive/2014/08/78. Please see the attachment for the script. Cheers, Dante On 18.11.2014 22:28, Mats Olsson wrote: Hi dante! I would appreciate it a lot if you could send the clone script that you used to clone the 9pi imate to a larger SD card. Thanks beforehand! Kind Regards, Mats 2014-11-18 21:29 GMT+01:00, Richard Miller 9f...@hamnavoe.com: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
Hi Mats, Look in the /dev directory (ls /dev). If you only have the boot device and an additional USB drive (in your case, an USB-to-SD adapter), the boot device shall be /dev/sdM0 and the USB/SD device shall be /dev/sdU0.0 Kind Regards, Dante On 26.11.2014 18:16, Mats Olsson wrote: Hi dante! I copied your piclone script in Plan 9 but even though I've been digging I can't find out how to get the name of the SD card attached to the pi on which I want to clone my setup on. So, easily put, what command do I use to get to know that? So I wonder how to get the device name of the clean SD in the USB card adapter. In your post first mentioning the script you wrote: If the device is recognized as sdUXX, call piclone sdUXX. Well that is what I want to find out. If I get that I'm ready to rock and roll. Kind Greetings, Mats 2014-11-18 23:09 GMT+01:00, dante subscripti...@posteo.eu: Hi Mats, I posted it before; unfortunately the archive doesn't save the attached files. Here is the original post: http://9fans.net/archive/2014/08/78. Please see the attachment for the script. Cheers, Dante On 18.11.2014 22:28, Mats Olsson wrote: Hi dante! I would appreciate it a lot if you could send the clone script that you used to clone the 9pi imate to a larger SD card. Thanks beforehand! Kind Regards, Mats 2014-11-18 21:29 GMT+01:00, Richard Miller 9f...@hamnavoe.com: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
Hi! So piclone sdU0.0 would be right? I have the script in /usr/glenda/home does that matter? Yours Sincerely, Mats 2014-11-26 18:41 GMT+01:00, Dante subscripti...@posteo.eu: Hi Mats, Look in the /dev directory (ls /dev). If you only have the boot device and an additional USB drive (in your case, an USB-to-SD adapter), the boot device shall be /dev/sdM0 and the USB/SD device shall be /dev/sdU0.0 Kind Regards, Dante On 26.11.2014 18:16, Mats Olsson wrote: Hi dante! I copied your piclone script in Plan 9 but even though I've been digging I can't find out how to get the name of the SD card attached to the pi on which I want to clone my setup on. So, easily put, what command do I use to get to know that? So I wonder how to get the device name of the clean SD in the USB card adapter. In your post first mentioning the script you wrote: If the device is recognized as sdUXX, call piclone sdUXX. Well that is what I want to find out. If I get that I'm ready to rock and roll. Kind Greetings, Mats 2014-11-18 23:09 GMT+01:00, dante subscripti...@posteo.eu: Hi Mats, I posted it before; unfortunately the archive doesn't save the attached files. Here is the original post: http://9fans.net/archive/2014/08/78. Please see the attachment for the script. Cheers, Dante On 18.11.2014 22:28, Mats Olsson wrote: Hi dante! I would appreciate it a lot if you could send the clone script that you used to clone the 9pi imate to a larger SD card. Thanks beforehand! Kind Regards, Mats 2014-11-18 21:29 GMT+01:00, Richard Miller 9f...@hamnavoe.com: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
Hi dante! In answer to my own question: DONE. Thanks a lot! Kind Greetings, Mats 2014-11-26 18:56 GMT+01:00, Mats Olsson plan9@gmail.com: Hi! So piclone sdU0.0 would be right? I have the script in /usr/glenda/home does that matter? Yours Sincerely, Mats 2014-11-26 18:41 GMT+01:00, Dante subscripti...@posteo.eu: Hi Mats, Look in the /dev directory (ls /dev). If you only have the boot device and an additional USB drive (in your case, an USB-to-SD adapter), the boot device shall be /dev/sdM0 and the USB/SD device shall be /dev/sdU0.0 Kind Regards, Dante On 26.11.2014 18:16, Mats Olsson wrote: Hi dante! I copied your piclone script in Plan 9 but even though I've been digging I can't find out how to get the name of the SD card attached to the pi on which I want to clone my setup on. So, easily put, what command do I use to get to know that? So I wonder how to get the device name of the clean SD in the USB card adapter. In your post first mentioning the script you wrote: If the device is recognized as sdUXX, call piclone sdUXX. Well that is what I want to find out. If I get that I'm ready to rock and roll. Kind Greetings, Mats 2014-11-18 23:09 GMT+01:00, dante subscripti...@posteo.eu: Hi Mats, I posted it before; unfortunately the archive doesn't save the attached files. Here is the original post: http://9fans.net/archive/2014/08/78. Please see the attachment for the script. Cheers, Dante On 18.11.2014 22:28, Mats Olsson wrote: Hi dante! I would appreciate it a lot if you could send the clone script that you used to clone the 9pi imate to a larger SD card. Thanks beforehand! Kind Regards, Mats 2014-11-18 21:29 GMT+01:00, Richard Miller 9f...@hamnavoe.com: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
Cool, first tester :-). Thanks, Mats! -- Dante On 26.11.2014 19:16, Mats Olsson wrote: Hi dante! In answer to my own question: DONE. Thanks a lot! Kind Greetings, Mats 2014-11-26 18:56 GMT+01:00, Mats Olsson plan9@gmail.com: Hi! So piclone sdU0.0 would be right? I have the script in /usr/glenda/home does that matter? Yours Sincerely, Mats 2014-11-26 18:41 GMT+01:00, Dante subscripti...@posteo.eu: Hi Mats, Look in the /dev directory (ls /dev). If you only have the boot device and an additional USB drive (in your case, an USB-to-SD adapter), the boot device shall be /dev/sdM0 and the USB/SD device shall be /dev/sdU0.0 Kind Regards, Dante On 26.11.2014 18:16, Mats Olsson wrote: Hi dante! I copied your piclone script in Plan 9 but even though I've been digging I can't find out how to get the name of the SD card attached to the pi on which I want to clone my setup on. So, easily put, what command do I use to get to know that? So I wonder how to get the device name of the clean SD in the USB card adapter. In your post first mentioning the script you wrote: If the device is recognized as sdUXX, call piclone sdUXX. Well that is what I want to find out. If I get that I'm ready to rock and roll. Kind Greetings, Mats 2014-11-18 23:09 GMT+01:00, dante subscripti...@posteo.eu: Hi Mats, I posted it before; unfortunately the archive doesn't save the attached files. Here is the original post: http://9fans.net/archive/2014/08/78. Please see the attachment for the script. Cheers, Dante On 18.11.2014 22:28, Mats Olsson wrote: Hi dante! I would appreciate it a lot if you could send the clone script that you used to clone the 9pi imate to a larger SD card. Thanks beforehand! Kind Regards, Mats 2014-11-18 21:29 GMT+01:00, Richard Miller 9f...@hamnavoe.com: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
I think it is very realistic. They modified standard bsd stack (I don't know its present state but back when I worked on it, it needed to be simplified quite a bit). i think a no lock tcp stack from 1990 hacked to be even less sophisticated is anything but realistic. it's pure fantasy that one can avoid proper locking today. and at 10gbe packet rates even 400 instructions per packet (* 1.5 for the reply) is not a trivial expense. I haven't looked into why on the RPi plan9's tcp performance is about 30-40% of that on linux (which works near wire speed). For the local case it doesn't matter much in any case. (a) allocb() relies on deathly slow malloc; cf. qallocb in 9atom, which upps performance quite a bit (b) usb is not as fast, (c) send and recieve in plan 9's tcp are not as decoupled as they could be, this leads to latency in sending after the window opens, or latency in opening the window. - erik
Re: [9fans] running plan9 : an ideal setup?
I haven't looked into why on the RPi plan9's tcp performance is about 30-40% of that on linux (which works near wire speed). For the local case it doesn't matter much in any case. (a) allocb() relies on deathly slow malloc; cf. qallocb in 9atom, which upps performance quite a bit (b) usb is not as fast, (c) send and recieve in plan 9's tcp are not as decoupled as they could be, this leads to latency in sending after the window opens, or latency in opening the window. we did get a lot of performance out of a proper NewReno implentation, which happened after the original rpi port. a review of changes in sources from the original work didn't turn up any noteworthy changes, but then again just reviewing the source code isn't all that effective. :-) - erik
Re: [9fans] running plan9 : an ideal setup?
On Nov 25, 2014, at 1:59 , Bakul Shah ba...@bitblocks.com wrote: As long as you run IP, you pay the other costs for any protocol. But there's plenty of cases where you don't need even that. See AOE, or nonet from very early Plan 9. I'd like that back. If you use TCP you benefit from its near universality, dealing with long fat pipes, bandwidth adjustment, selective ack etc. Those are all valid reasons to have a tcp/ip stack. But what I (and I believe Erik) say is that there's cases where that doesn't matter, and it would be nice to have an alternative in those cases. I no that IL makes a noticeable (if tiny) difference on my local network; I bet nonet would be a marginally greater difference.
Re: [9fans] running plan9 : an ideal setup?
On Tue Nov 25 08:52:33 EST 2014, a...@9srv.net wrote: On Nov 25, 2014, at 1:59 , Bakul Shah ba...@bitblocks.com wrote: As long as you run IP, you pay the other costs for any protocol. But there's plenty of cases where you don't need even that. See AOE, or nonet from very early Plan 9. I'd like that back. and in any event, processor cycles are (relatively) not important. synchronization latency and memory latency dominate. there's more of that for tcp, and it's not accounted for. - erik
Re: [9fans] running plan9 : an ideal setup?
On Sat, 22 Nov 2014 13:06:15 EST erik quanstrom quans...@quanstro.net wrote: On Fri Nov 21 12:31:13 EST 2014, ba...@bitblocks.com wrote: This paper is well worth reading: http://groups.csail.mit.edu/ana/Publications/PubPDFs/1988Analysis%20TCP%20P rocessing%20Overhead.pdf While the traditional BSD implementation uses mbufs that complicate things, actual tcp processing can be done quite cheaply. - ignores tcp checksum -- it alone will take a couple cycles per byte. They factored out path common to all IP, to measure TCP's overhead. tcp checksum is basically IP checksum. - ignores locking and i believe they've used the BKL to avoid locking any data structures , otherwise how could they process ip in 61 instructions? actually there's proof o f this in the timer instruction count -- 17. that's not enough to acquire a lock. Again, matching an incoming packet to find its PCB is common to all so they didn't put this in tcp overhead computation. As long as you run IP, you pay the other costs for any protocol. - asserts that 300 instructions of x86 code - 400 instructions of risc code, conservatively absolutely not if one of them is rep; movb (which they appear to use) Can't speak to this. in short, i see signs that this paper is not realistic. I think it is very realistic. They modified standard bsd stack (I don't know its present state but back when I worked on it, it needed to be simplified quite a bit). furthermore, this sunny picture assumes an environment where tcp isn't giving any benefit. if you're not retransmitting a bit, you're not getting anything out of tcp. If you use TCP you benefit from its near universality, dealing with long fat pipes, bandwidth adjustment, selective ack etc. My point was that even with all its complexity, tcp's processing overhead can be fairly low for the common case. I haven't looked into why on the RPi plan9's tcp performance is about 30-40% of that on linux (which works near wire speed). For the local case it doesn't matter much in any case.
Re: [9fans] running plan9 : an ideal setup?
On Fri Nov 21 12:31:13 EST 2014, ba...@bitblocks.com wrote: This paper is well worth reading: http://groups.csail.mit.edu/ana/Publications/PubPDFs/1988Analysis%20TCP%20Processing%20Overhead.pdf While the traditional BSD implementation uses mbufs that complicate things, actual tcp processing can be done quite cheaply. - ignores tcp checksum -- it alone will take a couple cycles per byte. - ignores locking and i believe they've used the BKL to avoid locking any data structures, otherwise how could they process ip in 61 instructions? actually there's proof of this in the timer instruction count -- 17. that's not enough to acquire a lock. - asserts that 300 instructions of x86 code - 400 instructions of risc code, conservatively absolutely not if one of them is rep; movb (which they appear to use) in short, i see signs that this paper is not realistic. furthermore, this sunny picture assumes an environment where tcp isn't giving any benefit. if you're not retransmitting a bit, you're not getting anything out of tcp. i think this was the original point. - erik
Re: [9fans] running plan9 : an ideal setup?
On Thu Nov 20 13:44:04 EST 2014, a...@9srv.net wrote: Both. I agree with what you're saying about the computers, but I was thinking of the fact that the wire speed is fast enough in most cases that the tcp/ip overhead doesn't impact things noticeably for most uses. There are outliers in both cases, of course. this is not correct. tcp doesn't help at all when the wire is fast (short, fat). it's the classic tradeoff of cpu for (networking) performance. the wire being fast enough is an argument against using tcp, not for it. so really, it's the gobs of cpu we currently have that make tcp not an issue, not the gobs of bandwidth. - erik
Re: [9fans] running plan9 : an ideal setup?
On Nov 21, 2014, at 9:34 , erik quanstrom quans...@quanstro.net wrote: this is not correct. tcp doesn't help at all when the wire is fast (short, fat). it's the classic tradeoff of cpu for (networking) performance. the wire being fast enough is an argument against using tcp, not for it. I don't think what we're saying is incompatible. I'm not saying that tcp helps, or doesn't have overhead, with fast pipes. I'm saying that the pipes are fast enough that in most use cases, at least for me, the pipe is fast enough that ((wire speed) - (tcp/ip overhead)) is still plenty fast.
Re: [9fans] running plan9 : an ideal setup?
This paper is well worth reading: http://groups.csail.mit.edu/ana/Publications/PubPDFs/1988Analysis%20TCP%20Processing%20Overhead.pdf While the traditional BSD implementation uses mbufs that complicate things, actual tcp processing can be done quite cheaply. On Nov 21, 2014, at 6:34 AM, erik quanstrom quans...@quanstro.net wrote: On Thu Nov 20 13:44:04 EST 2014, a...@9srv.net wrote: Both. I agree with what you're saying about the computers, but I was thinking of the fact that the wire speed is fast enough in most cases that the tcp/ip overhead doesn't impact things noticeably for most uses. There are outliers in both cases, of course. this is not correct. tcp doesn't help at all when the wire is fast (short, fat). it's the classic tradeoff of cpu for (networking) performance. the wire being fast enough is an argument against using tcp, not for it. so really, it's the gobs of cpu we currently have that make tcp not an issue, not the gobs of bandwidth. - erik
Re: [9fans] running plan9 : an ideal setup?
On Thu Nov 20 01:02:53 EST 2014, a...@9srv.net wrote: I can't speak for Erik's cec-as-nonet setup specifically, but I've wanted nonet (or an equivalent) many, many times. Networks are fast enough that tcp/ip overhead isn't really something that hurts in most cases, but it does exist. anthony, i'm sure your fingers just got crossed up, but i think you ment computers are fast enough that the overhead doesn't matter. - erik
Re: [9fans] running plan9 : an ideal setup?
Both. I agree with what you're saying about the computers, but I was thinking of the fact that the wire speed is fast enough in most cases that the tcp/ip overhead doesn't impact things noticeably for most uses. There are outliers in both cases, of course. On Nov 20, 2014, at 9:37 , erik quanstrom quans...@quanstro.net wrote: On Thu Nov 20 01:02:53 EST 2014, a...@9srv.net wrote: I can't speak for Erik's cec-as-nonet setup specifically, but I've wanted nonet (or an equivalent) many, many times. Networks are fast enough that tcp/ip overhead isn't really something that hurts in most cases, but it does exist. anthony, i'm sure your fingers just got crossed up, but i think you ment computers are fast enough that the overhead doesn't matter. - erik
Re: [9fans] running plan9 : an ideal setup?
On 19 Nov 2014 23:54, Tom Ivar Helbekkmo t...@hamartun.priv.no wrote: Richard Miller 9f...@hamnavoe.com writes: After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. Could have been just the normal SD card used up situation. They don't last forever, and to get a reasonable life time you have to a) not buy too cheap, and b) not write to it more than you have to. Under Unix, point b means mounting with noatime and nodiratime options. Some specifics here: http://en.wikipedia.org/wiki/Wear_leveling Raspi in particular also seems to be very sensitive to power quality. Often the symptom of overloaded power supply is a crash and an unbootable SD card. Frequent backups of the card are probably a good idea in any case.
Re: [9fans] running plan9 : an ideal setup?
Hi dante! Thanks a lot! Now I have saved the script. Kind regards, Mats 2014-11-18 23:09 GMT+01:00, dante subscripti...@posteo.eu: Hi Mats, I posted it before; unfortunately the archive doesn't save the attached files. Here is the original post: http://9fans.net/archive/2014/08/78. Please see the attachment for the script. Cheers, Dante On 18.11.2014 22:28, Mats Olsson wrote: Hi dante! I would appreciate it a lot if you could send the clone script that you used to clone the 9pi imate to a larger SD card. Thanks beforehand! Kind Regards, Mats 2014-11-18 21:29 GMT+01:00, Richard Miller 9f...@hamnavoe.com: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
- Plan9: don't enable periodic snapshots in Fossil to avoid it getting corrupt This is no longer true, this long standing bug was fixed about a year ago. Can you remember where you saw the documentation saying snapshots where still broken? -Steve
Re: [9fans] running plan9 : an ideal setup?
Dear Steve, I never knew that there was a known bug there: got my frist Plan9 this summer. I enabled snapshots on my Pi this summer and got a corrupt file system within hours. As I promised Richard, I'll try to reproduce the issue and post a bug report to this list. This looks to me as a regression (or some other problem with my system). Kind Regards, Dante On 19.11.2014 10:40, Steve Simon wrote: - Plan9: don't enable periodic snapshots in Fossil to avoid it getting corrupt This is no longer true, this long standing bug was fixed about a year ago. Can you remember where you saw the documentation saying snapshots where still broken? -Steve
Re: [9fans] running plan9 : an ideal setup?
I never knew that there was a known bug there: got my frist Plan9 this summer. I enabled snapshots on my Pi this summer and got a corrupt file system within hours. Ah, Thanks for the info. I wonder if this is more to do with flash card reliability and the pi than fossil and snapshots. I have been running fossil with snapshots for a year or so now and not had a single crash. I only use my Pi as a terminal so its flash is pretty much readonly. -Steve
Re: [9fans] running plan9 : an ideal setup?
Hi Steve, how often do you snapshot? How large is the SD? I used a 32G SD with hourly snapshots, terminal server. I would sort of rule out the SD reliability. After reinstalling on the corrupt SD with snapshots off, no crashes for months of always-on. Thanks! Dante On 19.11.2014 11:18, Steve Simon wrote: I never knew that there was a known bug there: got my frist Plan9 this summer. I enabled snapshots on my Pi this summer and got a corrupt file system within hours. Ah, Thanks for the info. I wonder if this is more to do with flash card reliability and the pi than fossil and snapshots. I have been running fossil with snapshots for a year or so now and not had a single crash. I only use my Pi as a terminal so its flash is pretty much readonly. -Steve
Re: [9fans] running plan9 : an ideal setup?
I have been running fossil with snapshots for a year or so now and not had a single crash. Is there an easy way to determine when a Fossil/Venti service was first deployed? I have a feeling my specific installation is a good few years old and I'm pretty sure any problem that may have arisen could not have been hard to fix. Just as a guideline: ripple# hget 'http://127.1:8000/storage' index=main total arenas=25 active=14 total space=13,224,894,464 used=7,374,207,851 clumps=2,660,366 compressed clumps=2,197,678 data=15,481,985,505 compressed data=7,206,604,793 I don't keep media stuff, so a lot of this reflects changes over time rather than quantity of data. I do have many versions of Go development in place. Lucio. PS: It would seem I rebuilt the system (hoping to add disk capacity) little over a year ago: d-r-xr-xr-x S 0 proxima proxima 0 Jul 22 2013 /dev/sd00 This is a VMware ESX server permanently on.
Re: [9fans] running plan9 : an ideal setup?
On Wed Nov 19 00:36:36 EST 2014, skip.tavakkol...@gmail.com wrote: i'm a bit paranoid about ether frames jumping the switch somehow, but i guess that's as likely as local snooping while tftping the boot image that has the nvram with creds. your switch is really broken if it forwards ethernet frames (no tcp, no ip). off the local segment. it's already a security concern. i've never seen this happen. - erik
Re: [9fans] running plan9 : an ideal setup?
On Wed Nov 19 01:07:43 EST 2014, lu...@proxima.alt.za wrote: i'm a bit paranoid about ether frames jumping the switch somehow, but i guess that's as likely as local snooping while tftping the boot image that has the nvram with creds. Well, if you're paranoid, then being able to write arbitrary data to the console is more serious than intercepting a password, at least on the surface. i'd encourage folks to at least try cec before assuming things about how it works. by the way, at one point i had a hacked up kernel which allowed me to mount a file server over the cec protocol. quite a bit like nonet. - erik
Re: [9fans] running plan9 : an ideal setup?
On Wed, Nov 19, 2014 at 3:36 PM, erik quanstrom quans...@quanstro.net wrote: by the way, at one point i had a hacked up kernel which allowed me to mount a file server over the cec protocol. In what situation would this be useful? -- Aram Hăvărneanu
Re: [9fans] running plan9 : an ideal setup?
I have 500gb hard disks, mirrored, for fossil and venti. I take ephemeral snapshots every 15 mins, kept for 7 days, and nightly archival snapshots kept forever. this has been running for just over 10 years. though not continuously I have the same setup at wok and at home Steve On 19 Nov 2014, at 10:27, dante subscripti...@posteo.eu wrote: Hi Steve, how often do you snapshot? How large is the SD? I used a 32G SD with hourly snapshots, terminal server. I would sort of rule out the SD reliability. After reinstalling on the corrupt SD with snapshots off, no crashes for months of always-on. Thanks! Dante On 19.11.2014 11:18, Steve Simon wrote: I never knew that there was a known bug there: got my frist Plan9 this summer. I enabled snapshots on my Pi this summer and got a corrupt file system within hours. Ah, Thanks for the info. I wonder if this is more to do with flash card reliability and the pi than fossil and snapshots. I have been running fossil with snapshots for a year or so now and not had a single crash. I only use my Pi as a terminal so its flash is pretty much readonly. -Steve
Re: [9fans] running plan9 : an ideal setup?
On Tue, 18 Nov 2014 20:29:30 GMT Richard Miller 9f...@hamnavoe.com wrote: I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? One possibility: Many SD cards don't implement wear leveling. Without it, if the system is hitting some speicific blocks over and over again, the card will become unusable fast. I was using a $10 USB thumb drive as a boot disk for my FreeBSD based fileserver and forgot to mount it readonly (and unix syncs every 30 seconds to all r/w fs). It was toast within a year. On the raspi I've had good experience with the better quality SanDisk SD cards. I even have venti running on one for the past 6 months -- as an experiment, so I don't care if the card dies!
Re: [9fans] running plan9 : an ideal setup?
Richard Miller 9f...@hamnavoe.com writes: After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. Could have been just the normal SD card used up situation. They don't last forever, and to get a reasonable life time you have to a) not buy too cheap, and b) not write to it more than you have to. Under Unix, point b means mounting with noatime and nodiratime options. Some specifics here: http://en.wikipedia.org/wiki/Wear_leveling -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman
Re: [9fans] running plan9 : an ideal setup?
I can't speak for Erik's cec-as-nonet setup specifically, but I've wanted nonet (or an equivalent) many, many times. Networks are fast enough that tcp/ip overhead isn't really something that hurts in most cases, but it does exist. Also, I really want to exercise the cross-network parts of Plan 9. On Nov 19, 2014, at 10:34 , Aram Hăvărneanu ara...@mgk.ro wrote: On Wed, Nov 19, 2014 at 3:36 PM, erik quanstrom quans...@quanstro.net wrote: by the way, at one point i had a hacked up kernel which allowed me to mount a file server over the cec protocol. In what situation would this be useful? -- Aram Hăvărneanu
Re: [9fans] running plan9 : an ideal setup?
On Nov 19, 2014, at 5:36 , lu...@proxima.alt.za wrote: Is there an easy way to determine when a Fossil/Venti service was first deployed? I have a feeling my specific installation is a good few years old and I'm pretty sure any problem that may have arisen could not have been hard to fix. Just as a guideline: ripple# hget 'http://127.1:8000/storage' Ask for /index instead of /storage. Each arena line will give you a created=xxx tag, where xxx is a timestamp. You could do an awk script to give you growth over time, if you like.
Re: [9fans] running plan9 : an ideal setup?
Ask for /index instead of /storage. Each arena line will give you a created=xxx tag, where xxx is a timestamp. You could do an awk script to give you growth over time, if you like. I looked for that, but I must have managed to overlook these fields. Here is the first: Sat Jul 31 14:14:12 SAT 2010 Of course, the question was about Fossil's reliability and I'm sure some will expect a level that is much better attained by backing Fossil with Venti, no matter how robust Fossil may be. Lucio. - This email has been scanned by the MxScan Email Security System. -
[9fans] running plan9 : an ideal setup?
i have been trying to get plan9 running on my latest and greatest hp-aio. failed, even while trying out 9front. would there be some way to determine an ideal configuration for a machine to used solely for plan9 experimentation? also, based on what ever i have read, plan9 seems most at home with a set of machines in some kind of client-server mode. if this is true, may i know an ideal setup? thanks.
Re: [9fans] running plan9 : an ideal setup?
Raspberry Pi with an Ethernet cable (unfortunately there's no wireless yet AFAIK). Both the Plan9 and the 9Front file systems have their issues, though, so back up periodically: - Plan9: don't enable periodic snapshots in Fossil to avoid it getting corrupt - 9Front: comes with the experimental hjfs by default, which got corrupt sooner or later on my setup Both distributions come as a small (2GB) runnable image. There is no installer yet, so it is hard to change the file system. What I did: Boot Richard Miller's Plan9 SD card (2GB image) on a Raspberry Pi. Used an USB-to-SD adapter and the clone script from an earlier post of mine to install the system on a *larger* SD card. Boot the large SD card, happy. The said images are terminal servers. If you manage to convert the terminal server into a CPU server (easy, see Wiki), you'll be able to connect from Unix using drawterm. Cheers, Dante On 18.11.2014 14:29, mayur...@devio.us wrote: i have been trying to get plan9 running on my latest and greatest hp-aio. failed, even while trying out 9front. would there be some way to determine an ideal configuration for a machine to used solely for plan9 experimentation? also, based on what ever i have read, plan9 seems most at home with a set of machines in some kind of client-server mode. if this is true, may i know an ideal setup? thanks.
Re: [9fans] running plan9 : an ideal setup?
I'll test again and report if the issue is still there. On 18.11.2014 15:11, Richard Miller wrote: - Plan9: don't enable periodic snapshots in Fossil to avoid it getting corrupt I think that advice refers to a bug which was fixed in March 2012.
Re: [9fans] running plan9 : an ideal setup?
Quoting dante subscripti...@posteo.eu: - 9Front: comes with the experimental hjfs by default, which got corrupt sooner or later on my setup 9front defaults to cwfs64x, not hjfs. khm
Re: [9fans] running plan9 : an ideal setup?
I don't think this applies to the Raspberry Pi. There is no installer, so the installer defaults are here irrelevant. For the Pi, a ready-to-boot SD image is provided. On 18.11.2014 16:42, Kurt H Maier wrote: Quoting dante subscripti...@posteo.eu: - 9Front: comes with the experimental hjfs by default, which got corrupt sooner or later on my setup 9front defaults to cwfs64x, not hjfs. khm
Re: [9fans] running plan9 : an ideal setup?
If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. -- Aram Hăvărneanu
Re: [9fans] running plan9 : an ideal setup?
If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
Hi dante! I would appreciate it a lot if you could send the clone script that you used to clone the 9pi imate to a larger SD card. Thanks beforehand! Kind Regards, Mats 2014-11-18 21:29 GMT+01:00, Richard Miller 9f...@hamnavoe.com: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
Hi Mats,
I posted it before; unfortunately the archive doesn't save the attached
files.
Here is the original post: http://9fans.net/archive/2014/08/78.
Please see the attachment for the script.
Cheers,
Dante
On 18.11.2014 22:28, Mats Olsson wrote:
Hi dante!
I would appreciate it a lot if you could send the clone script that
you used to clone the 9pi imate to a larger SD card. Thanks
beforehand!
Kind Regards,
Mats
2014-11-18 21:29 GMT+01:00, Richard Miller 9f...@hamnavoe.com:
If you must use a rpi, you should strive to use it as a terminal, and
like every other Plan 9 terminal it should use the central file
server
without local storage.
That would be my advice too. As an experiment, I set up a 9picpu
using
the SD card as local storage, working mostly as a secondary smtp and
imap
server. After a bit less than a year, the SD card suffered a
catastrophic
failure. When I say catastrophic, I mean I can't find any meaningful
data
anywhere in the first 120MB or so of /dev/sdM0/data ... just
not-quite-random
looking garbage.
I can't think of any software fault that could wipe out so much of a
disk, with no respect for partition boundaries (the dos partition in
the first 64MB had not been mounted). But I also know too little
about
the internals of SD cards to understand how they fail. Maybe some
internal logical-to-physical block mapping table went bad?
Anyway, it's just one anecdotal data point, but I wouldn't be happy
running any plan 9 machine with an SD card as the main filesystem.
#!/bin/rc
#
# This program clones a Raspberry Pi Plan9 installation onto another storage
device.
# Use a USB adapter for SD cards in order to write another SD card.
# The storage device will be used at its full capacity, in contrast to the
downloadable image.
# Moreover, no additional computer is required for the installation.
#
# This program makes some assumptions that are specific to the Raspberry Pi
device.
# The only parameter is the name of the destination drive.
# The program will not ask for further input.
#
# NOTES
#
# You can of course use the USB adapter for SD cards to write the downloadable
image.
# The bootstrap cannot access a DOS partition embedded into a Plan9 partition
(9fat).
# The sd(3) driver cannot serve volumes from a partition table: we use
partfs(8) instead.
# Con(1) needs a certain number of empty lines in the input in order to read
all server answers.
#
fn check {
if( ! ~ $1 '' ) {
echo We encountered an error and must stop here.
echo Status: $1.
exit 13
}
}
if(! test $#* -eq 1) {
echo Usage: '''piclone sdUY.Z''' creates a Raspberry9 system on sdUY.Z.
exit
}
disk=$1
if(! test -d /dev/$disk) {
echo No such device: $disk.
exit
}
# Make shure there is no disk configuration left.
echo Null the disk configuration.
dd -if /dev/zero -of /dev/$disk/data -count 1024 [1=] [2=]
check $status
# the default MBR without boot code suffices for the Pi.
echo Install MBR.
disk/mbr /dev/$disk/data [1=] [2=]
check $status
# We need a real DOS partition.
# The Raspberry Pi boot mechanism cannot cope with the 9FAT partition embedded
in the plan9 one.
echo Create DOS partition for booting.
disk/fdisk -b /dev/$disk/data [1=] [2=] EOF
a p0 0 16
t p0 FAT32
A p0
w
q
EOF
check $status
echo Create a Plan9 partition with default parameters.
disk/fdisk -wa /dev/$disk/data [1=] [2=]
check $status
# sd(3) does not serve disk partitions: use partfs(8).
if( ! test -e /dev/$disk/dos ) {
echo Start partfs to serve partitions.
disk/partfs -d $disk /dev/$disk/data [1=] [2=]
check $status
}
echo Reconfigure device.
disk/fdisk -p /dev/$disk/data /dev/$disk/ctl [2=]
check $status
echo Plan9 partition: install MBR.
disk/mbr /dev/$disk/plan9 [1=] [2=]
check $status
echo Plan9 partition: subdivide.
disk/prep -wb -a nvram -a fossil /dev/$disk/plan9 [1=] [2=]
check $status
echo Plan9 partition: reconfigure device.
disk/prep -p /dev/$disk/plan9 /dev/$disk/ctl [2=]
check $status
echo Partitions on $disk:
cat /dev/$disk/ctl
echo Format DOS partition.
disk/format -d -r2 /dev/$disk/dos [1=] [2=]
check $status
echo Format Fossil partition.
fossil/flfmt -y /dev/$disk/fossil [1=] [2=]
check $status
if( ! test -e /srv/dos ){
echo Start DOS server.
dossrv [1=] [2=]
check $status
}
echo Start server for old Fossil partition.
cat /env/flproto EOF
srv -p fscons.old
srv fossil.old
fsys main config /dev/sdM0/fossil
fsys main open -aAVP
fsys main
EOF
fossil/fossil -c '. /env/flproto' [1=] [2=]
check $status
echo Start server for new Fossil partition.
cat /env/flproto EOF
srv -p fscons.new
srv fossil.new
fsys main config /dev/$disk/fossil
fsys main open -aAVWP
fsys main
EOF
fossil/fossil -c '. /env/flproto' #[1=] [2=]
check $status
echo
Re: [9fans] running plan9 : an ideal setup?
i have two 9picpu's. they tftp-boot from the auth+fs. the SD is used for boot loading and the nvram partition. setting up the nvram without a console is tricky; i thought i'd mention it here in case others run into it. 1. using the existing 9pi SD image, edit config.txt and set 'kernel' to 'uboot.img'. 2. on the auth+fs, build a bcm kernel with nvram partition in the kernel (i.e. /boot/nvram) 3. create the /cfg/pxe/MAC for the box and initially set the nvram parameter to /boot/nvram. 4. after the first boot, cpu into the rpi and do the auth/wrkey dance with '#S/sdM0/nvram' 5. reset the the nvram in /cfg/pxe/MAC to #S/sdM0/nvram 6. rebuild the bcm kernel without the nvram 7. reboot the rpi i've been contemplating making my auth server a 9picpu booting from local, but SD reliability is the drawback. On Tue, Nov 18, 2014 at 12:29 PM, Richard Miller 9f...@hamnavoe.com wrote: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. That would be my advice too. As an experiment, I set up a 9picpu using the SD card as local storage, working mostly as a secondary smtp and imap server. After a bit less than a year, the SD card suffered a catastrophic failure. When I say catastrophic, I mean I can't find any meaningful data anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random looking garbage. I can't think of any software fault that could wipe out so much of a disk, with no respect for partition boundaries (the dos partition in the first 64MB had not been mounted). But I also know too little about the internals of SD cards to understand how they fail. Maybe some internal logical-to-physical block mapping table went bad? Anyway, it's just one anecdotal data point, but I wouldn't be happy running any plan 9 machine with an SD card as the main filesystem.
Re: [9fans] running plan9 : an ideal setup?
i've been contemplating making my auth server a 9picpu booting from local, but SD reliability is the drawback. I believe the pi will run with an external flash or hard drive, abet slowly and using a powered USB hub. you could boot the kernel from the sd card but mount the external device everywhere you need to write things, like /sys/log and /adm/keys This would give you the speed of flash but the reliability of a magnetic disk or flash drive. You could even use multiple external flash drives with fs(3). Just some random ideas. -Steve
Re: [9fans] running plan9 : an ideal setup?
On Tue Nov 18 17:10:59 EST 2014, skip.tavakkol...@gmail.com wrote: i have two 9picpu's. they tftp-boot from the auth+fs. the SD is used for boot loading and the nvram partition. setting up the nvram without a console is tricky; i thought i'd mention it here in case others run into it. why not use cec(1) from 9atom? this completely solves the console issue without requiring any expensive or uncommon hardware. - erik
Re: [9fans] running plan9 : an ideal setup?
On Tue Nov 18 12:03:04 EST 2014, ara...@mgk.ro wrote: If you must use a rpi, you should strive to use it as a terminal, and like every other Plan 9 terminal it should use the central file server without local storage. +1. if i understand correctly, the labs used physical security for the authentication server, and it booted off a local fs. while this is a very tidy idea, i think reality booges things up, and it doesn't really work out. - erik
Re: [9fans] running plan9 : an ideal setup?
i think reality booges things up, and it doesn't really work out. More specifically, an auth server can provide very tight security, but where such is not needed, it is too tempting to run services on it as it is the most convenient place to do it from. Once you have enough power behind the auth server to run one service, you no longer have the security benefits. Discipline is demanded and the price is a bit steep. I know because for a long time I ran an auth server on what would be considered a toy even back then, but once it failed, it was never re-deployed. Reading some of the scary stuff the NSA seems to be getting up to, though, it is nice to know that your border equipment (not your private auth server) is unlikely ever to be owned by NSA spooks. Lucio. PS: I do have a dedicated auth server, but electricity supply constraints cause it to stay off most of the time, leading to bit rot. The unreliabilty of the Internet link means it cannot act as auth server for my public equipment, so that problem needs to be solved first. Running it off a photovoltaic/battery source is definitely the next plan. - This email has been scanned by the MxScan Email Security System. -
Re: [9fans] running plan9 : an ideal setup?
i'm a bit paranoid about ether frames jumping the switch somehow, but i guess that's as likely as local snooping while tftping the boot image that has the nvram with creds. On Tue, Nov 18, 2014 at 5:57 PM, erik quanstrom quans...@quanstro.net wrote: On Tue Nov 18 17:10:59 EST 2014, skip.tavakkol...@gmail.com wrote: i have two 9picpu's. they tftp-boot from the auth+fs. the SD is used for boot loading and the nvram partition. setting up the nvram without a console is tricky; i thought i'd mention it here in case others run into it. why not use cec(1) from 9atom? this completely solves the console issue without requiring any expensive or uncommon hardware. - erik
Re: [9fans] running plan9 : an ideal setup?
i'm a bit paranoid about ether frames jumping the switch somehow, but i guess that's as likely as local snooping while tftping the boot image that has the nvram with creds. Well, if you're paranoid, then being able to write arbitrary data to the console is more serious than intercepting a password, at least on the surface. Lucio.
