Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I just ran the mfg. sw in the vb win2k guest. I then checked the serial parameters in the host. I then ran sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 in the host after shutting down the guest. Same no-response result. This would seem to rule out the possibility that the serial parameters are wrong. -Denis On Fri, Dec 29, 2017 at 2:44 PM, Denis Heidtmann wrote: > I made the measurements with my 'scope. The voltages and waveforms are > identical comparing DTR, RTS (also RXD), although I am surprised a little > that the pulses on DTR are as large as they are: 2.4V swing. Must be some > resistance in the supply to the drain. But the level is up at 11.6V, so > those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to > +8.2V for both the mfg. sw and sigrok. > > So no explanation yet, and hence no solution. Is there a way to examine > the serial parameters the mfg. sw uses? Perhaps the docs on the protocol > are in error. > > On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < > denis.heidtm...@gmail.com> wrote: > >> I will make those measurements, but I am doubtful it will show anything. >> The schematic I have shows DTR to be the collector and RTS to be the low >> end of the emitter resistor of the output NPN. I did see solid pulses on >> the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when they >> should not be. It is too bad my 'scope has limited record length and no >> way to store the data off the 'scope. >> >> On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < >> russ...@personaltelco.net> wrote: >> >>> Have you measured the voltages on DTR and RTS during the runs? >>> >>> Try it with sigrok and with the vendor software and see if there is a >>> difference in those values. >>> >>> On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann >>> wrote: >>> > This saga continues. >>> > >>> > On the laptop with a usb-serial adapter I got to the point where the >>> > commands: >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 >>> > >>> > behave as expected except the last one returns no data. I was advised >>> to >>> > try using these same commands on the desktop which has an RS232 port, >>> thus >>> > removing the usb-serial adapter from the picture. Good idea. >>> > >>> > After just guessing what serial port to use, I run the following >>> command: >>> > >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan >>> > The following devices were found: >>> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 >>> > >>> > This is the same response I got on the laptop. >>> > >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show >>> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 >>> > Supported driver options: >>> > conn >>> > serialcomm >>> > Supported configuration options: >>> > >>> > This is the same response I got on the laptop. >>> > >>> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 >>> > >>> > [no response except the usual ~10 second delay] >>> > >>> > This is the same response I got on the laptop. RATS! >>> > >>> > This eliminates the usb-serial device from the picture. >>> > >>> > Recall that when running --samples 10 command on the laptop I was able >>> to >>> > detect pulses on the serial line consistent (in a general sense) with a >>> > response from the dmm. Also recall that running the mfg. sw under >>> windows >>> > on the desktop showed flawless communication. >>> > >>> > finally, I report: >>> > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; >>> > intr = ; quit = ; erase = ; kill = ; eof = >>> > ; >>> > eol = ; eol2 = ; swtch = ; start = ; stop = >>> > ; >>> > susp = ; rprnt = ; werase = ; lnext = ; >>> > discard = ; min = 0; time = 0; >>> > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts >>> > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl >>> -ixon >>> > -ixoff >>> > -iuclc -ixany -imaxbel -iutf8 >>> > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 >>> bs0 >>> > vt0 ff0 >>> > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase >>> -tostop >>> > -echoprt >>> > -echoctl -echoke -flusho -extproc >>> > >>> > And the protocol is reported to be: >>> > >>> > data format: 7n2 at 600 baud (7 bits, no parity, 2 stop bits). >>> > Control lines: >>> >DTR and RTS lines are used to power the TX line: RTS is clear >>> >for -12 supply; DTR is set for +12 supply. Data transmission is >>> >solicited sending whatever character to the RX line. >>> > >>> > Any suggestions as to where to go from here? >>> > >>> > Thanks, >>> > -Denis >>> > ___ >>> > PLUG mailing list >>> > PLUG@pdxlinux.org >>> > http://lists.pdxlinux.org/mailman/listinfo/plug >>> ___ >>> PLUG maili
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
Tomas, Thanks so much for the offer. I will look at the Bitscope website to see if it would help. -Denis On Fri, Dec 29, 2017 at 3:36 PM, Tomas Kuchta wrote: > I have one of those simple Bitscope scopes/analysers for slow RPi type > interface hacking it might be the right tool for the job and it runs on > Linux. > > Would that help? Do you want to borrow it? > > Check the Bitscope website for details, but it is good enough for serial > ports. Perhaps even decoding it. > > Tomas > > On Dec 29, 2017 2:44 PM, "Denis Heidtmann" > wrote: > > > I made the measurements with my 'scope. The voltages and waveforms are > > identical comparing DTR, RTS (also RXD), although I am surprised a > little > > that the pulses on DTR are as large as they are: 2.4V swing. Must be > some > > resistance in the supply to the drain. But the level is up at 11.6V, so > > those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to > > +8.2V for both the mfg. sw and sigrok. > > > > So no explanation yet, and hence no solution. Is there a way to examine > > the serial parameters the mfg. sw uses? Perhaps the docs on the protocol > > are in error. > > > > On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < > > denis.heidtm...@gmail.com> > > wrote: > > > > > I will make those measurements, but I am doubtful it will show > anything. > > > The schematic I have shows DTR to be the collector and RTS to be the > low > > > end of the emitter resistor of the output NPN. I did see solid pulses > on > > > the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when > they > > > should not be. It is too bad my 'scope has limited record length and > no > > > way to store the data off the 'scope. > > > > > > On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < > > > russ...@personaltelco.net> wrote: > > > > > >> Have you measured the voltages on DTR and RTS during the runs? > > >> > > >> Try it with sigrok and with the vendor software and see if there is a > > >> difference in those values. > > >> > > >> On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann > > >> wrote: > > >> > This saga continues. > > >> > > > >> > On the laptop with a usb-serial adapter I got to the point where the > > >> > commands: > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 > > >> > > > >> > behave as expected except the last one returns no data. I was > advised > > >> to > > >> > try using these same commands on the desktop which has an RS232 > port, > > >> thus > > >> > removing the usb-serial adapter from the picture. Good idea. > > >> > > > >> > After just guessing what serial port to use, I run the following > > >> command: > > >> > > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > > >> > The following devices were found: > > >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > >> > > > >> > This is the same response I got on the laptop. > > >> > > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > > >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > >> > Supported driver options: > > >> > conn > > >> > serialcomm > > >> > Supported configuration options: > > >> > > > >> > This is the same response I got on the laptop. > > >> > > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 > > >> > > > >> > [no response except the usual ~10 second delay] > > >> > > > >> > This is the same response I got on the laptop. RATS! > > >> > > > >> > This eliminates the usb-serial device from the picture. > > >> > > > >> > Recall that when running --samples 10 command on the laptop I was > able > > >> to > > >> > detect pulses on the serial line consistent (in a general sense) > with > > a > > >> > response from the dmm. Also recall that running the mfg. sw under > > >> windows > > >> > on the desktop showed flawless communication. > > >> > > > >> > finally, I report: > > >> > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; > > >> > intr = ; quit = ; erase = ; kill = ; > eof = > > >> > ; > > >> > eol = ; eol2 = ; swtch = ; start = ; > stop > > = > > >> > ; > > >> > susp = ; rprnt = ; werase = ; lnext = ; > > >> > discard = ; min = 0; time = 0; > > >> > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts > > >> > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > > -ixon > > >> > -ixoff > > >> > -iuclc -ixany -imaxbel -iutf8 > > >> > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 > tab0 > > >> bs0 > > >> > vt0 ff0 > > >> > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase > > -tostop > > >> > -echoprt > > >> > -echoctl -echoke -flusho -extproc > > >> > > > >> > And the protocol is reported to be: > > >> > > > >> > data format: 7n2 at 600 baud (7 bits, no parity, 2 stop bits). > > >> > Control lines: > > >> >DTR and RTS lines are
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I have one of those simple Bitscope scopes/analysers for slow RPi type interface hacking it might be the right tool for the job and it runs on Linux. Would that help? Do you want to borrow it? Check the Bitscope website for details, but it is good enough for serial ports. Perhaps even decoding it. Tomas On Dec 29, 2017 2:44 PM, "Denis Heidtmann" wrote: > I made the measurements with my 'scope. The voltages and waveforms are > identical comparing DTR, RTS (also RXD), although I am surprised a little > that the pulses on DTR are as large as they are: 2.4V swing. Must be some > resistance in the supply to the drain. But the level is up at 11.6V, so > those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to > +8.2V for both the mfg. sw and sigrok. > > So no explanation yet, and hence no solution. Is there a way to examine > the serial parameters the mfg. sw uses? Perhaps the docs on the protocol > are in error. > > On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann < > denis.heidtm...@gmail.com> > wrote: > > > I will make those measurements, but I am doubtful it will show anything. > > The schematic I have shows DTR to be the collector and RTS to be the low > > end of the emitter resistor of the output NPN. I did see solid pulses on > > the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when they > > should not be. It is too bad my 'scope has limited record length and no > > way to store the data off the 'scope. > > > > On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < > > russ...@personaltelco.net> wrote: > > > >> Have you measured the voltages on DTR and RTS during the runs? > >> > >> Try it with sigrok and with the vendor software and see if there is a > >> difference in those values. > >> > >> On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann > >> wrote: > >> > This saga continues. > >> > > >> > On the laptop with a usb-serial adapter I got to the point where the > >> > commands: > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 > >> > > >> > behave as expected except the last one returns no data. I was advised > >> to > >> > try using these same commands on the desktop which has an RS232 port, > >> thus > >> > removing the usb-serial adapter from the picture. Good idea. > >> > > >> > After just guessing what serial port to use, I run the following > >> command: > >> > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > >> > The following devices were found: > >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > >> > > >> > This is the same response I got on the laptop. > >> > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > >> > Supported driver options: > >> > conn > >> > serialcomm > >> > Supported configuration options: > >> > > >> > This is the same response I got on the laptop. > >> > > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 > >> > > >> > [no response except the usual ~10 second delay] > >> > > >> > This is the same response I got on the laptop. RATS! > >> > > >> > This eliminates the usb-serial device from the picture. > >> > > >> > Recall that when running --samples 10 command on the laptop I was able > >> to > >> > detect pulses on the serial line consistent (in a general sense) with > a > >> > response from the dmm. Also recall that running the mfg. sw under > >> windows > >> > on the desktop showed flawless communication. > >> > > >> > finally, I report: > >> > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; > >> > intr = ; quit = ; erase = ; kill = ; eof = > >> > ; > >> > eol = ; eol2 = ; swtch = ; start = ; stop > = > >> > ; > >> > susp = ; rprnt = ; werase = ; lnext = ; > >> > discard = ; min = 0; time = 0; > >> > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts > >> > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > -ixon > >> > -ixoff > >> > -iuclc -ixany -imaxbel -iutf8 > >> > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 > >> bs0 > >> > vt0 ff0 > >> > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase > -tostop > >> > -echoprt > >> > -echoctl -echoke -flusho -extproc > >> > > >> > And the protocol is reported to be: > >> > > >> > data format: 7n2 at 600 baud (7 bits, no parity, 2 stop bits). > >> > Control lines: > >> >DTR and RTS lines are used to power the TX line: RTS is clear > >> >for -12 supply; DTR is set for +12 supply. Data transmission is > >> >solicited sending whatever character to the RX line. > >> > > >> > Any suggestions as to where to go from here? > >> > > >> > Thanks, > >> > -Denis > >> > ___ > >> > PLUG mailing list > >> > PLUG@pdxlinux.org > >> > http://lists.pdxlinux.org/mailman/listinfo/plu
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I made the measurements with my 'scope. The voltages and waveforms are identical comparing DTR, RTS (also RXD), although I am surprised a little that the pulses on DTR are as large as they are: 2.4V swing. Must be some resistance in the supply to the drain. But the level is up at 11.6V, so those 2.4V drops cannot matter. The signals on the RXD pin are -3.6 to +8.2V for both the mfg. sw and sigrok. So no explanation yet, and hence no solution. Is there a way to examine the serial parameters the mfg. sw uses? Perhaps the docs on the protocol are in error. On Fri, Dec 29, 2017 at 9:17 AM, Denis Heidtmann wrote: > I will make those measurements, but I am doubtful it will show anything. > The schematic I have shows DTR to be the collector and RTS to be the low > end of the emitter resistor of the output NPN. I did see solid pulses on > the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when they > should not be. It is too bad my 'scope has limited record length and no > way to store the data off the 'scope. > > On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior < > russ...@personaltelco.net> wrote: > >> Have you measured the voltages on DTR and RTS during the runs? >> >> Try it with sigrok and with the vendor software and see if there is a >> difference in those values. >> >> On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann >> wrote: >> > This saga continues. >> > >> > On the laptop with a usb-serial adapter I got to the point where the >> > commands: >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 >> > >> > behave as expected except the last one returns no data. I was advised >> to >> > try using these same commands on the desktop which has an RS232 port, >> thus >> > removing the usb-serial adapter from the picture. Good idea. >> > >> > After just guessing what serial port to use, I run the following >> command: >> > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan >> > The following devices were found: >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 >> > >> > This is the same response I got on the laptop. >> > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show >> > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 >> > Supported driver options: >> > conn >> > serialcomm >> > Supported configuration options: >> > >> > This is the same response I got on the laptop. >> > >> > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 >> > >> > [no response except the usual ~10 second delay] >> > >> > This is the same response I got on the laptop. RATS! >> > >> > This eliminates the usb-serial device from the picture. >> > >> > Recall that when running --samples 10 command on the laptop I was able >> to >> > detect pulses on the serial line consistent (in a general sense) with a >> > response from the dmm. Also recall that running the mfg. sw under >> windows >> > on the desktop showed flawless communication. >> > >> > finally, I report: >> > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; >> > intr = ; quit = ; erase = ; kill = ; eof = >> > ; >> > eol = ; eol2 = ; swtch = ; start = ; stop = >> > ; >> > susp = ; rprnt = ; werase = ; lnext = ; >> > discard = ; min = 0; time = 0; >> > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts >> > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon >> > -ixoff >> > -iuclc -ixany -imaxbel -iutf8 >> > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 >> bs0 >> > vt0 ff0 >> > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop >> > -echoprt >> > -echoctl -echoke -flusho -extproc >> > >> > And the protocol is reported to be: >> > >> > data format: 7n2 at 600 baud (7 bits, no parity, 2 stop bits). >> > Control lines: >> >DTR and RTS lines are used to power the TX line: RTS is clear >> >for -12 supply; DTR is set for +12 supply. Data transmission is >> >solicited sending whatever character to the RX line. >> > >> > Any suggestions as to where to go from here? >> > >> > Thanks, >> > -Denis >> > ___ >> > PLUG mailing list >> > PLUG@pdxlinux.org >> > http://lists.pdxlinux.org/mailman/listinfo/plug >> ___ >> PLUG mailing list >> PLUG@pdxlinux.org >> http://lists.pdxlinux.org/mailman/listinfo/plug >> > > ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] serial communication with dmm (was com port in guest to usb in host (virtual box))
I will make those measurements, but I am doubtful it will show anything. The schematic I have shows DTR to be the collector and RTS to be the low end of the emitter resistor of the output NPN. I did see solid pulses on the emitter with sigrok. But perhaps DTR and/or RTS are pulsed when they should not be. It is too bad my 'scope has limited record length and no way to store the data off the 'scope. On Thu, Dec 28, 2017 at 11:42 PM, Russell Senior wrote: > Have you measured the voltages on DTR and RTS during the runs? > > Try it with sigrok and with the vendor software and see if there is a > difference in those values. > > On Thu, Dec 28, 2017 at 9:51 PM, Denis Heidtmann > wrote: > > This saga continues. > > > > On the laptop with a usb-serial adapter I got to the point where the > > commands: > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --show > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --scan > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyUSB0 --samples 10 > > > > behave as expected except the last one returns no data. I was advised to > > try using these same commands on the desktop which has an RS232 port, > thus > > removing the usb-serial adapter from the picture. Good idea. > > > > After just guessing what serial port to use, I run the following command: > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --scan > > The following devices were found: > > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > > > This is the same response I got on the laptop. > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --show > > mastech-mas345 - MASTECH MAS345 with 1 channel: P1 > > Supported driver options: > > conn > > serialcomm > > Supported configuration options: > > > > This is the same response I got on the laptop. > > > > sigrok-cli --driver mastech-mas345:conn=/dev/ttyS0 --samples 10 > > > > [no response except the usual ~10 second delay] > > > > This is the same response I got on the laptop. RATS! > > > > This eliminates the usb-serial device from the picture. > > > > Recall that when running --samples 10 command on the laptop I was able to > > detect pulses on the serial line consistent (in a general sense) with a > > response from the dmm. Also recall that running the mfg. sw under > windows > > on the desktop showed flawless communication. > > > > finally, I report: > > stty -F /dev/ttyS0 -a speed 600 baud; rows 0; columns 0; line = 0; > > intr = ; quit = ; erase = ; kill = ; eof = > > ; > > eol = ; eol2 = ; swtch = ; start = ; stop = > > ; > > susp = ; rprnt = ; werase = ; lnext = ; > > discard = ; min = 0; time = 0; > > -parenb -parodd -cmspar cs7 hupcl cstopb cread clocal -crtscts > > -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon > > -ixoff > > -iuclc -ixany -imaxbel -iutf8 > > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 > > vt0 ff0 > > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > > -echoprt > > -echoctl -echoke -flusho -extproc > > > > And the protocol is reported to be: > > > > data format: 7n2 at 600 baud (7 bits, no parity, 2 stop bits). > > Control lines: > >DTR and RTS lines are used to power the TX line: RTS is clear > >for -12 supply; DTR is set for +12 supply. Data transmission is > >solicited sending whatever character to the RX line. > > > > Any suggestions as to where to go from here? > > > > Thanks, > > -Denis > > ___ > > PLUG mailing list > > PLUG@pdxlinux.org > > http://lists.pdxlinux.org/mailman/listinfo/plug > ___ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Am I asking the "right question"
I suspect the answer to " Am I asking the "right question?" is NO. I'll try for a better question in the New Year. I suspect that I just don't have some background assumed by everybody trying to answer this question (and what I see as related questions). Thanks everyone for your efforts. ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Am I asking the "right question"
On Fri, Dec 29, 2017 at 8:26 AM, Richard Owlett wrote: > On 12/29/2017 03:28 AM, Carl Karsten wrote: > >> in 2009 I messed with debootstrap to set up a ide drive in a usb caddy > >> - When I was done, put the drive in a headless box, power it up and >> it would boot into a new debian box. I forget where installing grub >> fit into this process. for sure it was a building a "normal" debian >> install on a blank drive. >> >> > That's a reasonable description of my goal. GRUB would not enter it as the > end product would be a bootable flash drive to be mailed to someone else. if someone else is going to boot something, there needs to be a boot loader. But I think we can ignore this topic because it doesn't sound like you need what debootstrap does given it does sound like this does do what you want and is much easier: (copied from above, removed the SHA256SUM file to make it easier to read. + wget http://ftp.debian.org/debian/dists/stretch/main/installer- amd64/current/images/hd-media/boot.img.gz + wget https://cdimage.debian.org/debian-cd/current/amd64/iso- cd/debian-9.3.0-amd64-netinst.iso + zcat boot.img.gz | sudo dcfldd of=/dev/sdc + pmount /dev/sdc sdc + cp debian-9.3.0-amd64-netinst.iso /media/sdc > The Debian installer can manufacture that result (with use of custom > preseeds) but it asks the wrong set of questions. Basically it does a good > job of doing everything for everyone and every environment. > What are the right questions? If the goal is "no questions" then you probably want this: https://github.com/CarlFK/video-stack-deploy/blob/nbpy/roles/tftp-server/files/d-i/stretch/preseed.cfg which ends with : d-i preseed/include string ../preseed_local_debian.cfg That is where we put the things that change d-i mirror/http/hostname string ftp.debian.org d-i passwd/username string username d-i passwd/user-password-crypted password $6$fSX3p3K6OXe$NwfRPWm8hTTt0cm40gD69R4ltdJbAoVcMqkVLSnIQSiFP0J3vs46S63PY/hLnWPoITZzrdh3KSYHEqLv/LHQg0 d-i time/zone string US/Pacific You can put those lines into preseed.cfg You can also take out all the # comment lines - which I find easier to deal with given how much of that file is # comments. > Power users would likely consider my goal to be a crippled installer. But > it would intrinsically meet *MY* goals by doing things *MY* way. Those > flash drives might be considered a prototype OS to be mailed to a friend in > another state. > > Thank you. > > > > ___ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > -- Carl K ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Am I asking the "right question"
On 12/28/2017 02:34 PM, Larry Brigman wrote: 'chroot' is an isolation/security mechanism. I understood that. It doesn't allow programs running within it to access anything except the kernel and the programs/libraries within the chroot. I'm with you so far. For what you are doing, think of it as a file system tree that you can test most of your boot environment (short of booting) prior to needing to actually boot it. That "test" capability does not accomplish anything that has not been already by having made multiple installs using the standard Debian installer. Perhaps a description of my goal is to hardcode options that preseeding would typically accomplish. And because it is just a command away, it is fast to change and experiment. ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Am I asking the "right question"
On 12/29/2017 03:28 AM, Carl Karsten wrote: in 2009 I messed with debootstrap to set up a ide drive in a usb caddy > - When I was done, put the drive in a headless box, power it up and it would boot into a new debian box. I forget where installing grub fit into this process. for sure it was a building a "normal" debian install on a blank drive. That's a reasonable description of my goal. GRUB would not enter it as the end product would be a bootable flash drive to be mailed to someone else. The Debian installer can manufacture that result (with use of custom preseeds) but it asks the wrong set of questions. Basically it does a good job of doing everything for everyone and every environment. Power users would likely consider my goal to be a crippled installer. But it would intrinsically meet *MY* goals by doing things *MY* way. Those flash drives might be considered a prototype OS to be mailed to a friend in another state. Thank you. ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Am I asking the "right question"
in 2009 I messed with debootstrap to set up a ide drive in a usb caddy - When I was done, put the drive in a headless box, power it up and it would boot into a new debian box. I forget where installing grub fit into this process. for sure it was a building a "normal" debian install on a blank drive. On Thu, Dec 28, 2017 at 2:34 PM, Larry Brigman wrote: > 'chroot' is an isolation/security mechanism. It doesn't allow programs > running within it to access anything except the kernel and the > programs/libraries within the chroot. > For what you are doing, think of it as a file system tree that you can test > most of your boot environment (short of booting) prior to needing to > actually boot it. > And because it is just a command away, it is fast to change and > experiment. > > On Thu, Dec 28, 2017 at 8:13 AM, Richard Owlett > wrote: > > > Those are among the pages that confused me long ago. > > > > They, without adequate background, say to use "chroot". > > My visualization of using debootstrap is to place Debian on a write only > > medium. > > The descriptions of "chroot" I've seen imply it's a crude VM like thingy. > > > > > > > > On 12/28/2017 09:30 AM, David Bridges wrote: > > > >> Search for debootstrap, the link provided earlier was for an extremely > >> old version of Debian although a search for dbootstrap debian | debian > >> dbootstrap in search engines finds current documentation > >> > >> debootstrap wiki page > >> https://wiki.debian.org/Debootstrap > >> > >> Current Debian install guide > >> https://www.debian.org/releases/stable/amd64/index.html.en > >> > >> debootstrap section in current install guide > >> https://www.debian.org/releases/stable/amd64/apds03.html.en#idm46300556 > >> 432288 > >> > >> To me this doesn't really sound like what you are looking for but only > >> you can know for sure. > >> > >> -- > >> David > >> > >> > > > > > > ___ > > PLUG mailing list > > PLUG@pdxlinux.org > > http://lists.pdxlinux.org/mailman/listinfo/plug > > > ___ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > -- Carl K ___ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
