Re: mdadm usage
Thomas A. Anderson composed on 2020-12-29 07:58 (UTC+0100): > I have been "using" mdadm to run software raid1 (stripping) on a file > server i have been running. RAID 1 is two devices that are mirrors of each other, redundancy, with some loss in speed. Loose one device, and you still have all your data. RAID 0 is striping. One device failing means all data lost from two devices, but twice as much space as RAID 1, and some extra speed. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: mdadm usage
Hi. On Tue, Dec 29, 2020 at 07:58:50AM +0100, Thomas A. Anderson wrote: > I have been "using" mdadm to run software raid1 (stripping) on a file > server i have been running. RAID1 is mirroring. Stripping is RAID0. RAID1 provides redundancy. RAID0 does not. > It is only now that I wonder if I am even using RAID1 properly? In > other words, now that I try to access data on these two original > drives on another system, I am unable to. I assume it's possible > (albeit doesn't seem intuitively simple -- at least for me), makes me > wonder if it's enen supposed to be used like this. It's possible for RAID1, it's impossible for RAID0. Which brings me to the question - cat /proc/mdstat . What does it show for you? > So, I ask a more precise question: Is mdadm designed to be used on other > system, and simply access data? As long as you have all the drives, any mdadm array should be able to assemble and provide you the access to its contents on that other system. If you do not have all the drives but have RAID that provides redundancy it's usually possible to convince mdadm to assemble a degraded array and therefore access its contents. > Maybe I just need two drives, and just do a cron job to rysnc to backup > once a week or something. RAID is not a substitute for a backup. Backup is not a substitute for mirroring. One does not exclude another, so use both. Reco
mdadm usage
Hello, I have been "using" mdadm to run software raid1 (stripping) on a file server i have been running. None of the drives have failed, and I have even setup subsequent drives in the same scenario. It is only now that I wonder if I am even using RAID1 properly? In other words, now that I try to access data on these two original drives on another system, I am unable to. I assume it's possible (albeit doesn't seem intuitively simple -- at least for me), makes me wonder if it's enen supposed to be used like this. I had assumed I could swap the drive out, and access the data (like a normal drive), but that doesn't seem to be the case. So, I ask a more precise question: Is mdadm designed to be used on other system, and simply access data? Maybe I just need two drives, and just do a cron job to rysnc to backup once a week or something.
Entregas 24 a 48 Horas: Pruebas Nasofaringeas
Buen día, Le mandamos un cordial saludo, esperando que todo esté muy bien. Nos comunicamos por este medio para comentarle que efectivamente como lo anunció la OMS las pruebas de antígeno están cambiando la forma de detectar posibles contagios de COVID-19 y salvando vidas al detectarse de manera temprana. Actualmente se están utilizando en Gobiernos y en Instituciones Privadas, sin embargo, la alta demanda ha hecho que cada vez sea más difícil de conseguir la prueba ABBOTT PANBIO™ COVID-19 Ag Rapid Test Device y que más personas puedan ser testeadas a tiempo dentro de las Empresas. Le enviamos este correo electrónico para ponernos a sus órdenes y asimismo comentarle que tenemos pruebas en existencias con entregas a toda la república de 24 a 48 horas. A continuación le dejamos el folleto completo del producto donde encontrará información general, ficha técnica, costos y tiempos de entrega: DESCARGAR INFORMACIÓN ABBOTT PANBIO™ COVID-19 Esperamos que esta información le pueda ser útil a usted y a su Empresa. Sin más por el momento nos reiteramos a sus órdenes. Saludos, Lic. Ernesto Corona Magdaleno Abastecimiento y Regulaciones. +52 (81) 2974 7731 T.S. MÉXICO Este boletín informativo tiene como objetivo crear valor en usted y en su Organización. Si usted desea dejar de recibir este tipo de información conteste con la palabra BAJAANTIGENO209. O en su defecto haga click en el siguiente enlace: unsubscribe from this list
Re: No GRUB with brand-new GPU
The Wanderer writes: On 2020-12-28 at 16:59, Felix Miata wrote: [...] > 7-RMA the 5700. I'd be extremely hesitant to do that unless I know it's the problem. Also, although I just unboxed this within the past week, I ordered it more than a month ago; it's entirely possible they might not accept it back now. [...] This option 7 would have been my suggestion, too :) I think it is quite likely that the new GPU ist just being incompatible to the existent system. It may be possible to explain this situation to the vendor to get a refund. Here in Germany, many hardware parts (especially CPUs and GPUs) are available in very limited quantities only at the moment. I am not sure if that makes a difference or applies to your location at all... Apart from that, option 3 "upgrade more hardware" seems to be the next thing to consider from my point of view. I'd advise against getting anything compatible with the old CPU and rather go with a more recent platform. (My personal approach to keep the old CPU from going to waste would be to add a HDD, PSU and chassis to keep the old motherboard and CPU alive) > Does your PS or motherboard have any swollen or leaky electrolytics? Not that I've been able to detect. I obviously can't inspect the inside of the PSU without in-depth surgery, but I did give the capacitors etc. on the motherboard a once-over during the last swap-out, and didn't notice anything apparently out of order. [...] I have seen multiple modes of failure in my comparatively short experience with IT hardware: - PSU capacitor blows up, white smoke. This PSU was at least 20 years old! - PSU fails, system will not even turn on. This PSU was more than 10 years old. All inside electronics look OK (none of the capacitors blown, some dust as expected) - Motherboard caps fail (visibly bulging). System runs incredibly unstable (freezes at random moments). This motherboard was _cheap_ and 8 years old. - Server PSU (or the power switching unit?) on redundant-PSU server fails, server reboots at random time intervals due to this. Causes loud fan whine and clicking sounds in the switching unit, hard to miss. The PSU is 14 years old and the issue itself occurs only occasionally but then in short sequence. What I take from this: - In my cases, components either fail prematurely or issues occur at seemingly random intervals. - If it was a power issue at hand, I'd expect it to fail when starting something that needs 3D accelleration, at random points or upon power on (possibly high initial current draw). That it would always fail at the switch from BIOS to OS makes me believe it is not a power-related issue. My idea would be that at that point, initial power is already there (otherwise the screen would be black from the beginning) while at the same time, the GRUB screen should not increase power draw on the GPU by such large a value, that it would exceed the power draw from the previous GPU under load. One further question: When the live environments fail, where do they fail exactly? Whenever I run a live disk, it starts by printing something like "ISOLINUX Copyright... H. Peter Aanvin...", afterwards it will print/draw a menu. Does it do these things successfully and only fail to boot afterwards or is it black screen before anything from the live medium appears? (I do not have any answer in case of an immediate black screen.) HTH and YMMV Linux-Fan öö pgp4ysEMBRLqG.pgp Description: PGP signature
Re: No GRUB with brand-new GPU
The Wanderer composed on 2020-12-28 18:31 (UTC-0500): > Felix Miata wrote: >> IME, the problem with electrolytics was solved a decade or more ago >> by switching motherboards to polys. The PS makers didn't and still >> haven't done that AFAICT. GPU needing both 6 wire and 8 wire >> dedicated power connectors smells like power hunger that an old PS >> with tired caps couldn't handle, notwithstanding its ostensible >> overprovisioning-rated output. > Given that I've already observed different behavior from the system when > the GPU isn't plugged in to power at all, would it still be worth > pursuing this as an angle? I consider the process preventive maintenance once the warranty has expired. After 8 years it might be overdue for cleaning anyway. If all the bases aren't covered, the problem may never be discovered. >> Most PSes only require 4 screws removed to get the cover off far >> enough to inspect the usual cluster of candidate caps adjacent to >> where most wires feeding out connect to the board. > I'd probably have to disconnect and unmount the PSU to get it far enough > out to remove any such thing, which would be doable but still a pain. Absolutely removal from case would be necessary, but > It's also a modular unit, so rather than "wires feeding out" of the PSU > itself there are connector ports, but I imagine that wouldn't make much > difference once it was open. Modular should make removal from case easier than with conventional PSes. However, it could make it harder to visibly inspect the PS interior, maybe even harder just to get the cover off. I never buy modulars. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: No GRUB with brand-new GPU
On 2020-12-28 at 18:26, Felix Miata wrote: > The Wanderer composed on 2020-12-28 17:26 (UTC-0500): > >> Not that I've been able to detect. I obviously can't inspect the >> inside of the PSU without in-depth surgery, but I did give the >> capacitors etc. on the motherboard a once-over during the last >> swap-out, and didn't notice anything apparently out of order. > > IME, the problem with electrolytics was solved a decade or more ago > by switching motherboards to polys. The PS makers didn't and still > haven't done that AFAICT. GPU needing both 6 wire and 8 wire > dedicated power connectors smells like power hunger that an old PS > with tired caps couldn't handle, notwithstanding its ostensible > overprovisioning-rated output. Given that I've already observed different behavior from the system when the GPU isn't plugged in to power at all, would it still be worth pursuing this as an angle? > Most PSes only require 4 screws removed to get the cover off far > enough to inspect the usual cluster of candidate caps adjacent to > where most wires feeding out connect to the board. I'd probably have to disconnect and unmount the PSU to get it far enough out to remove any such thing, which would be doable but still a pain. It's also a modular unit, so rather than "wires feeding out" of the PSU itself there are connector ports, but I imagine that wouldn't make much difference once it was open. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No GRUB with brand-new GPU
The Wanderer composed on 2020-12-28 17:26 (UTC-0500): > Not that I've been able to detect. I obviously can't inspect the inside > of the PSU without in-depth surgery, but I did give the capacitors etc. > on the motherboard a once-over during the last swap-out, and didn't > notice anything apparently out of order. IME, the problem with electrolytics was solved a decade or more ago by switching motherboards to polys. The PS makers didn't and still haven't done that AFAICT. GPU needing both 6 wire and 8 wire dedicated power connectors smells like power hunger that an old PS with tired caps couldn't handle, notwithstanding its ostensible overprovisioning-rated output. Most PSes only require 4 screws removed to get the cover off far enough to inspect the usual cluster of candidate caps adjacent to where most wires feeding out connect to the board. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: No GRUB with brand-new GPU
On 2020-12-28 at 16:59, Felix Miata wrote: > 4-subscribe to one or both Grub mailing lists to ask for help. The problem occurs with the live-boot environment, which AFAICT is using something other than GRUB to boot. Unless I'm mistaken about that boot method, I'm now reasonably certain that this isn't GRUB-specific after all. > 5-Turn on UEFI if it's off, turn off if it's on, if you have a spare > disk for making the switch, or your live media supports both. Grub's > job is considerably different between the two. As I indicated in the original post, this motherboard predates UEFI. (Or at least predates the universality thereof.) It has an actual BIOS. > 6-Use Knoppix as your live media. It boots with Syslinux instead of > Grub. I'm fairly sure the live environment I used (the amd64 image from https://www.debian.org/CD/live/) does likewise. I do have some other bootable media (of extremely primitive nature, graphics-wise) which I know for a fact uses ISOLINUX or similar, and I could try one of those if it might be fruitful... > 7-RMA the 5700. I'd be extremely hesitant to do that unless I know it's the problem. Also, although I just unboxed this within the past week, I ordered it more than a month ago; it's entirely possible they might not accept it back now. > Have you tried slowing down the CPU, disabling hyper-threading, or > slowing down RAM? No. All are possible options, but I'm nearly as hesitant to underclock the system as I'd be to overclock it (I did run this overclocked at one point, but that was within the first month or two I had the machine and I decided the added performance wasn't worth the increased cooler noise). I'm not sure I grasp why doing those things might help get things working with a newer GPU, when the existing one works just fine with the current settings. > Have you run memtest86 lately, No. > or swapped RAM stick positions? All 6 DIMM slots on this motherboard are occupied.The DIMMs come from a pair of three-DIMM kits, such that the DIMMs in each kit were tested pre-purchase with one another and confirmed to work; to the best of my recollection, the DIMMs are in the slots such that the three from a given kit are in the same memory channel. I'd be hesitant to go messing with that without solid reason. > Does your PS or motherboard have any swollen or leaky electrolytics? Not that I've been able to detect. I obviously can't inspect the inside of the PSU without in-depth surgery, but I did give the capacitors etc. on the motherboard a once-over during the last swap-out, and didn't notice anything apparently out of order. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No GRUB with brand-new GPU
The Wanderer composed on 2020-12-28 16:13 (UTC-0500): ... 4-subscribe to one or both Grub mailing lists to ask for help. 5-Turn on UEFI if it's off, turn off if it's on, if you have a spare disk for making the switch, or your live media supports both. Grub's job is considerably different between the two. 6-Use Knoppix as your live media. It boots with Syslinux instead of Grub. 7-RMA the 5700. Have you tried slowing down the CPU, disabling hyper-threading, or slowing down RAM? Have you run memtest86 lately, or swapped RAM stick positions? Does your PS or motherboard have any swollen or leaky electrolytics? -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Instalar Kodi Leia 18.6
Estimados, buenas tardes. Detecte que no era problema ni de debian ni de Kodi. La falla estaba el la building de kodi latino lku. Gracias. Slds. El dom., 27 de dic. de 2020 04:59, Camaleón escribió: > El 2020-12-26 a las 19:22 -0300, Pablo Fernandez escribió: > > > Estimados, buenas tardes. > > > > Estoy usando Debian 10 y tengo problemas con la instalación de Kodi > 18.9 > > (5:18.9-dmo0+deb10u1). > > > > Me esta arrojando el siguiente error al iniciar. > > > > " gdb not installed, can't get stack trace" . > > > > Aclaro que para instalarlo tuve que agregar el source list "deb > > http://www.deb-multimedia.org buster main non-free " , ya que si > instalaba > > por apt la ultima versión era Kodi 17.6 . > > ¿Y necesitas esa versión concreta por algún motivo? Quizá en la lista > de debian multimedia te puedan echar una mano: > > http://www.deb-multimedia.org/lurker/list/dmo-discussion.en.html > > > Desde ya agradezco sus valiosos aportes. > > ¿Y cuál es el problema, exactamente? Si puedes enviar a la lista el > error que te aparece, mejor, porque ese mensaje lo que me da entender > es que la aplicación se ha cerrado o que tiene algún problema que ha > generado una traza de depuración pero que no podrás analizar la > depuración de errores si no instalas el paquete correspondiente (gdb), > normalmente lo usan los desarrolladores. > > Saludos, > > -- > Camaleón > >
Re: No GRUB with brand-new GPU
On 2020-12-28 at 07:55, The Wanderer wrote: > On 2020-12-28 at 07:47, Anssi Saari wrote: > >> One thing came to my mind, do you have the appropriate aux power >> connectors available and connected? Looks like the RX 5700 XT is >> quite power hungry at 225 W max vs. 151 W with your old card. >> Different connectors too (6 pin + 8 pin instead of 2x 6 pin). And >> these cards can be quite picky about having appropriate power >> connected. > > Yes - I noted the different power-connector requirements when I > first installed the card, and I've had them in place on every swap-in > since. > > If the card weren't getting its proper power, I'd expect anything > from no video output at all to a warning light to a motherboard beep, > none of which is happening. > > My PSU is overpowered for the system it's in, so I'm reasonably sure > it's capable of handling the added load for the upgraded GPU without > issues. I can now basically confirm that this isn't the issue. In my latest swap-out, to test the live-environment boot, I initially forgot to connect the power cables to the graphics card. I got no vide output at all, not even the POST screen, and from what reactions I was getting I suspect it may not have been booting even invisibly. The live-environment boot went nowhere; I got exactly the same hang booting that way. I tested on the old GPU too for comparison, and it worked there, although it brought up the GPU only in a low-resolution basic mode because the necessary firmware for hardware acceleration with that model isn't included in the Debian live images. I could probably dig up a non-Linux-based bootable medium (if nothing else, I have boot DVDs for Windows 10 install at my workplace, though I certainly wouldn't go through with the installation!), but I'm not at all sure I'd get any different result. At this point, I think my remaining options are as follows: [1] Get in touch with the people who made the motherboard, and ask them for a BIOS update to potentially get this working. Long odds of any success there, given that the last update for this motherboard model was eight-plus years ago, and if I'm not mistaken CPUs for the CPU socket on this motherboard are no longer even being manufactured. [2] Get in touch with the people who make the GPU (either AMD or MSI, the latter being the ones who did this particular card with the underlying processor) and ask them for advice. [3] Give up on getting this working with my current system, and start looking for parts to build a newer one that would be more likely to be compatible with this. Option 3 would be the most certain to work, but also the most expensive and unwieldy, particularly given that the hardware site I relied on for parts reviews when building past systems has died under financial pressure and been sold to faceless investors who run clickbait articles and don't engage with the community. It's made worse by the fact that I'd rather not invest in more storage devices so soon after building the current high-capacity RAID-6 array which holds such things as /home, and I don't want to reinstall onto the current pair of arrays and have to set back up my various installed programs et cetera, but I also don't trust things to work right if I move the existing hard drives en masse to a new hardware environment - and even if that *would* work, my potential motherboard selection would be limited by the need for a minimum of seven SATA ports. (And of course I'd rather not discard my $1000-plus CPU just because the motherboard doesn't want to work with newer GPUs, even if it's less performant and more power-hungry than CPUs which can be bought today for less.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Format de data incorrecte de «ls -l»
On Sun, Dec 27, 2020 at 4:25 PM Joan Montané wrote: > > No deixava veure els mesos? Això no hauria de passar mai. «ls -l» no > talla els noms dels mesos. Els noms dels mesos sempre els hauries de > veure. Passa que, a sid, Fa anys passava, ara ho he tornat a provar i ja ho fa bé, per tant en el meu script he eliminat aquesta part de la modificació i només queda: sed -i.bak -e '/\bfebr[.]/s//feb./' \ -e '/\bag[.]/s//ago./' \ "/usr/share/i18n/locales/ca_ES" Salut, Jordi Pujol
Re: May I please have a block cursor in nano?
On Sat 26 Dec 2020 at 03:03, Bob Bernstein wrote: > On Fri, 25 Dec 2020, to...@tuxteam.de wrote: > > > Perhaps what you have to do is to change the shape of your > > terminal's cursor, and nano inherits it. > > Firstly, thanks to ALL of you who took time out on this holiday > to answer my (pretty dumb) question! > > I'm certain this is one of those things I knew clearly, say, as > few years ago as ten, but getting old sucks. > > OF COURSE the app looks to the terminal for its cursor policy, > and OF COURSE my terminal (mintty running in cygwin -- LONG > story) also lacked a block cursor. > Try to look in: https://github.com/mintty/mintty/wiki/CtrlSeqs ESC[1 q or ESC[2 q might solve your problem (there is a space before q). Hope this helps, Loïc > Thank you all. You people are just great, but maybe I'm feeling > that on account of all the time I've had to spend with my wife's > family over the holidays. > > Bob B. > -- > These are not the droids you are looking for. > >
Re: restarting pppd automatically
On Sun, 27 Dec 2020 23:56:21 + Graham Seaman wrote: > I'm having problems with pppd and an intermittent phone line > connection. My external line occasionally drops out, usually > briefly ... . There is or used to be a daemon that would re-establish a modem connection if it saw an outgoing packet. Other than the initial delay it was completely transparent. It emulated a permanent connection quite nicely. Unfortunately I don't recall its name. Anyone? -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Some recent update to unstable seems to have broken Xfce4 for me
On Sun, 27 Dec 2020 22:24:58 +0100 Sven Hartge wrote: > Celejar wrote: > > > Some recent update to unstable seems to have broken Xfce4 for me: > > The Xfce team is uploading Xfce 4.16 at the moment. Because not all > components can be uploaded in one go, this may cause some temporary > problems or instability. > > I'd advise you to wait some days until all uploads have finished and > then check back if the problem persists and file bugs if needed. Thanks. I'll plan to do that. Celejar
Re: No GRUB with brand-new GPU
On 2020-12-28 at 07:47, Anssi Saari wrote: > One thing came to my mind, do you have the appropriate aux power > connectors available and connected? Looks like the RX 5700 XT is > quite power hungry at 225 W max vs. 151 W with your old card. > Different connectors too (6 pin + 8 pin instead of 2x 6 pin). And > these cards can be quite picky about having appropriate power > connected. Yes - I noted the different power-connector requirements when I first installed the card, and I've had them in place on every swap-in since. If the card weren't getting its proper power, I'd expect anything from no video output at all to a warning light to a motherboard beep, none of which is happening. My PSU is overpowered for the system it's in, so I'm reasonably sure it's capable of handling the added load for the upgraded GPU without issues. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No GRUB with brand-new GPU
The Wanderer writes: > On 2020-12-27 at 16:36, Anssi Saari wrote: > >> The Wanderer writes: >> >>> I need to get that live-boot medium ready and do those tests. >> >> That seems like a good thing to do. > > I have it ready now, but haven't shut down for another swap, in part > because I've been napping. I may do it tonight, or more likely, tomorrow. > >> Another thing you could do is post your grub.cfg. It seems a little >> odd you haven't. > > It mainly just hadn't occurred to me, in part (though only in part) > because I thought I recalled that the boot-configuration files for GRUB2 > weren't the same as from legacy GRUB (and might even be stored in > multiple files) and had a mental association of that file with legacy > GRUB, so didn't trust it to necessarily be the correct / full config. Well, as I recall from the past, old Grub used /boot/grub/menu.lst. I still have one of those around dated Aug 14 2016. Not sure that's an accurate date but I can't remember my bootloader history, other than I stuck with LILO for a very long time. Anyways, I don't see much anything in the grub.cfg. Maybe the video options but it seems to be pretty much the default and that doesn't seem to cause issues very often, at least I couldn't find any Grub crashes with specifically AMD cards or any hardware. One thing came to my mind, do you have the appropriate aux power connectors available and connected? Looks like the RX 5700 XT is quite power hungry at 225 W max vs. 151 W with your old card. Different connectors too (6 pin + 8 pin instead of 2x 6 pin). And these cards can be quite picky about having appropriate power connected. > I have the impression that things have by now developed to the point > where a physical serial-port cable (of the classic type of serial port > and cable, whose connectors can be visually confused with a VGA port in > some cases) is no longer necessary, which is good, since if we ever had > such a thing it was at least back in the days of PS/2 keyboards and mice > and might have been back in the days before our home computers had > internal hard drives. Not quite that long ago. > I imagine USB would be the replacement (just based on the name), and I'm > also aware of the existence (kernel-side) of netconsole, but how to use > either for this I don't know. I've never tried it but as I understand it, Grub has some support for USB-serial adapters. After all, Grub has to support USB keyboards which means the basic building blocks of USB support have to be there. Adding support for USB-serial isn't that hard after that. But yes, this was a long shot anyways.
Re: restarting pppd automatically
On 28/12/2020 09:34, Tixy wrote: > On Sun, 2020-12-27 at 23:56 +, Graham Seaman wrote: >> I'm having problems with pppd and an intermittent phone line connection. >> My external line occasionally drops out, usually briefly (I'm trying to >> get this fixed but need a workaround in the meantime). > I know this is not what you asked for, and may not work for your use > case, but how about just preventing pppd stopping in the first place? > For my system that I set up 10 years ago and is still running, the > notes I wrote at the time say this: > >Edit /etc/ppp/peers/dsl-provider to add a line saying "maxfail 0"; >after the 'persist' entry is a good place. This should stop pppd >from timing out when it can't connect. > > I did that so my internet connection came back up when the modem > reconnected after an outage. > That seems to work fine and is a nice simple solution. At any rate, it works when I just yank the cable out temporarily; now to leave it for a while to see if it works with the real problem too (maybe a week or two before I know). Thank you! Graham
Re: restarting pppd automatically
Hi Tomas
On 28/12/2020 09:28, to...@tuxteam.de wrote:
> On Sun, Dec 27, 2020 at 11:56:21PM +, Graham Seaman wrote:
>> I'm having problems with pppd and an intermittent phone line
>
> Wow. Memories fading :-)
>
> OK, my recollection on inittab is a bit dusty, and I have little
> experience with systemd (trying to keep it that way). But I'll
> try a shot at it.
>
> The idea of inittab was to keep an eye on some processes: when
> they died, they were restarted ("respawn", in inittab parlance).
>
> This was init's job (thus inittab). Its main customers were
> the login processes. At their other end were serial lines
> attached to terminals (ah, vt220...). A user logged in at
> one of those things, the login handed off to a shell or something,
> when the user logged off the shell terminated, the calling
> login terminated and... respawn.
>
> Other things followed, typically daemons and... pppd.
>
> Then came SysV: daemons had to take care of themselves, PID
> files grew like mushrooms all over the place. It was bad
> times. The inittab was still there, mind you, but it was only
> tending to the Linux consoles (tradition perhaps :-) and to
> non-existing serial terminals. My system still has one,
> perhaps yours too.
>
> Now with systemd, we've turned full circle (unfortunately, with
> seventeen layers of complexity stacked in-between). In theory,
> systemd /should/ be able to do exactly what init used to do
> back then.
>
> Searching for "inittab systemd" via our favourite search engine
> (no, not that one with the big G) yields a couple of good
> hits. In [1] there's an example on how to translate an inittab
> entry into a systemd unit file.. In [2] you can see where the
> systemd unit files for your serial console live under Debian,
> perhaps there /is/ already something near that for pppd?
>
> Assuming you are on Buster... the list of files for package
> ppp (where pppd lives) is here [3]. No, no unit for respawn,
> alas. Only one to kick systemd's DNS service on connect and
> disconnect events (/lib/systemd/system/pppd-dns.service).
>
> Seems like you'll have to fashion one after some /lib/systemd/...tty.service.
> Perhaps there's someone around here who has done that to
> help you out. Tip: don't put it in /lib/systemd/... This
> place os for your distro. Put it somewhere in /etc/systemd/...
> that's for you, the admin. I can't provide details -- no
> experience with that.
>
> I'd try to file a bug against ppp: they should be providing
> a systemd unit file.
>
> Cheers
> - t
>
>
> [1]
> https://forums.opensuse.org/showthread.php/475468-In-search-for-a-inittab-entry-replacement-for-systemd#7
> [2] https://wiki.debian.org/systemd#line-288
> [3] https://packages.debian.org/buster/amd64/ppp/filelist
Thanks for the explanation. I'm filing it away and if Tixy's simple
configuration solution has unexpected side-effects I'll have a go at this.
Cheers
Graham
Re: restarting pppd automatically
On 27/12/2020 23:56, Graham Seaman wrote: I'm having problems with pppd and an intermittent phone line connection. My external line occasionally drops out, usually briefly (I'm trying to get this fixed but need a workaround in the meantime). When the line goes down, I get this sequence: Dec 27 01:35:03 snoopy pppd[22798]: No response to 4 echo-requests Dec 27 01:35:03 snoopy pppd[22798]: Serial link appears to be disconnected. Dec 27 01:35:03 snoopy pppd[22798]: Connect time 6266.2 minutes. Dec 27 01:35:03 snoopy pppd[22798]: Sent 3838785941 bytes, received 2059599934 bytes. Dec 27 01:35:03 snoopy pppd[22798]: restoring old default route to enp3s0 [xxx.xxx.xx.xxx] Dec 27 01:35:09 snoopy pppd[22798]: Connection terminated. Dec 27 01:35:09 snoopy pppd[22798]: Sent PADT Dec 27 01:35:09 snoopy pppd[22798]: Modem hangup Dec 27 01:36:14 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:37:19 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:38:24 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:39:29 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:40:34 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:41:39 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:42:44 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:43:49 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:44:54 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:46:00 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:46:00 snoopy pppd[22798]: Exit which I believe is what it is supposed to do, but leaves the connection dead when the phone line comes back a minute later. I want pppd to restart automatically when it goes down like this, maybe with a couple of minutes delay. According to the pppd documentation on https://tldp.org/HOWTO/Leased-Line/pppd.html section 3.2.1 I can do this by editing /etc/inittab. But I've never really relearnt how everything hangs together since the switch to systemd, and in any case want to stay as close as I can to the default debian setup (which is what I have now). Can anyone tell me what the recommended way to achieve this is now? Thanks Graham All I used to do, back in the day when I had a flakey line, was run a crontab script, every minute or two, checking if the ppp interface was up (ip address on it) and run the command 'pon dsl-provider' if it wasn't up. -- Michael Howard
Re: Kde inutilisable
Le 28/12/2020 à 11:00, Francois Mescam a écrit : Je viens de faire la mise à jour d'aujourd'hui et maintenant c'est rentré dans l'ordre pour kde. Francois Mescam Le 27/12/2020 à 21:01, Jérôme a écrit : Le Sun, 27 Dec 2020 11:59:29 +0100, Francois Mescam a écrit : je suis en testing et ce matin j'ai fait la mise à jour de kde sauf 4 paquets que j'ai gelé pour cause de dépendances non satisfaites. Résultat lors du début d'une session mes diverses applis se lancent bien mais le tour des fenres ne s'affiche pas et donc pas possible de changer de fenêtre donc kde est à ce stade inutilisable. je verrai demain s'il y a du nouveau. C'est pour ce genre d'ennui que j'aime bien aptitude, surtout en testing/sid : je fais toujours un safe-upgrade et s'il y a des problème de dépendances soit je diffère, soit j'y vais prudemment paquet par paquet. En plus aptitude fournis quand même pas mal de solutions par lui-même. En tout cas je n'upgrade jamais de force ni ne fige de paquets, ça devient vite ingérable. Pour la même raison je fais aussi du pinning avec Sid en backup, ça permet la plupart du teps de ne pas rester coincé sur un paquet en testing qui peut rester parfois longtemps avant de résoudre un problème: C'est normal, il s'agit d'intégration pour construire une stable et pas d'une version de production... Sid est plus souple et réactive à ce niveau. Merci, j'ai pas osé, car j'ai encore une petite 30aines de paquets qui ne passent pas en safe-upgrade
Re: Kde inutilisable
Je viens de faire la mise à jour d'aujourd'hui et maintenant c'est rentré dans l'ordre pour kde. Francois Mescam Le 27/12/2020 à 21:01, Jérôme a écrit : Le Sun, 27 Dec 2020 11:59:29 +0100, Francois Mescam a écrit : je suis en testing et ce matin j'ai fait la mise à jour de kde sauf 4 paquets que j'ai gelé pour cause de dépendances non satisfaites. Résultat lors du début d'une session mes diverses applis se lancent bien mais le tour des fenres ne s'affiche pas et donc pas possible de changer de fenêtre donc kde est à ce stade inutilisable. je verrai demain s'il y a du nouveau. C'est pour ce genre d'ennui que j'aime bien aptitude, surtout en testing/sid : je fais toujours un safe-upgrade et s'il y a des problème de dépendances soit je diffère, soit j'y vais prudemment paquet par paquet. En plus aptitude fournis quand même pas mal de solutions par lui-même. En tout cas je n'upgrade jamais de force ni ne fige de paquets, ça devient vite ingérable. Pour la même raison je fais aussi du pinning avec Sid en backup, ça permet la plupart du teps de ne pas rester coincé sur un paquet en testing qui peut rester parfois longtemps avant de résoudre un problème: C'est normal, il s'agit d'intégration pour construire une stable et pas d'une version de production... Sid est plus souple et réactive à ce niveau.
Re: restarting pppd automatically
On Sun, 2020-12-27 at 23:56 +, Graham Seaman wrote: > I'm having problems with pppd and an intermittent phone line connection. > My external line occasionally drops out, usually briefly (I'm trying to > get this fixed but need a workaround in the meantime). When the line > goes down, I get this sequence: > > Dec 27 01:35:03 snoopy pppd[22798]: No response to 4 echo-requests > Dec 27 01:35:03 snoopy pppd[22798]: Serial link appears to be disconnected. > Dec 27 01:35:03 snoopy pppd[22798]: Connect time 6266.2 minutes. > Dec 27 01:35:03 snoopy pppd[22798]: Sent 3838785941 bytes, received > 2059599934 bytes. > Dec 27 01:35:03 snoopy pppd[22798]: restoring old default route to > enp3s0 [xxx.xxx.xx.xxx] > Dec 27 01:35:09 snoopy pppd[22798]: Connection terminated. > Dec 27 01:35:09 snoopy pppd[22798]: Sent PADT > Dec 27 01:35:09 snoopy pppd[22798]: Modem hangup > Dec 27 01:36:14 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:37:19 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:38:24 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:39:29 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:40:34 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:41:39 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:42:44 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:43:49 snoopy pppd[22798]: Timeout waiting for PADO packets > > Dec 27 01:44:54 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:46:00 snoopy pppd[22798]: Timeout waiting for PADO packets > Dec 27 01:46:00 snoopy pppd[22798]: Exit > > which I believe is what it is supposed to do, but leaves the connection > dead when the phone line comes back a minute later. I want pppd to > restart automatically when it goes down like this, maybe with a couple > of minutes delay. I know this is not what you asked for, and may not work for your use case, but how about just preventing pppd stopping in the first place? For my system that I set up 10 years ago and is still running, the notes I wrote at the time say this: Edit /etc/ppp/peers/dsl-provider to add a line saying "maxfail 0"; after the 'persist' entry is a good place. This should stop pppd from timing out when it can't connect. I did that so my internet connection came back up when the modem reconnected after an outage. -- Tixy
Re: restarting pppd automatically
On Sun, Dec 27, 2020 at 11:56:21PM +, Graham Seaman wrote:
> I'm having problems with pppd and an intermittent phone line
Wow. Memories fading :-)
OK, my recollection on inittab is a bit dusty, and I have little
experience with systemd (trying to keep it that way). But I'll
try a shot at it.
The idea of inittab was to keep an eye on some processes: when
they died, they were restarted ("respawn", in inittab parlance).
This was init's job (thus inittab). Its main customers were
the login processes. At their other end were serial lines
attached to terminals (ah, vt220...). A user logged in at
one of those things, the login handed off to a shell or something,
when the user logged off the shell terminated, the calling
login terminated and... respawn.
Other things followed, typically daemons and... pppd.
Then came SysV: daemons had to take care of themselves, PID
files grew like mushrooms all over the place. It was bad
times. The inittab was still there, mind you, but it was only
tending to the Linux consoles (tradition perhaps :-) and to
non-existing serial terminals. My system still has one,
perhaps yours too.
Now with systemd, we've turned full circle (unfortunately, with
seventeen layers of complexity stacked in-between). In theory,
systemd /should/ be able to do exactly what init used to do
back then.
Searching for "inittab systemd" via our favourite search engine
(no, not that one with the big G) yields a couple of good
hits. In [1] there's an example on how to translate an inittab
entry into a systemd unit file.. In [2] you can see where the
systemd unit files for your serial console live under Debian,
perhaps there /is/ already something near that for pppd?
Assuming you are on Buster... the list of files for package
ppp (where pppd lives) is here [3]. No, no unit for respawn,
alas. Only one to kick systemd's DNS service on connect and
disconnect events (/lib/systemd/system/pppd-dns.service).
Seems like you'll have to fashion one after some /lib/systemd/...tty.service.
Perhaps there's someone around here who has done that to
help you out. Tip: don't put it in /lib/systemd/... This
place os for your distro. Put it somewhere in /etc/systemd/...
that's for you, the admin. I can't provide details -- no
experience with that.
I'd try to file a bug against ppp: they should be providing
a systemd unit file.
Cheers
- t
[1]
https://forums.opensuse.org/showthread.php/475468-In-search-for-a-inittab-entry-replacement-for-systemd#7
[2] https://wiki.debian.org/systemd#line-288
[3] https://packages.debian.org/buster/amd64/ppp/filelist
signature.asc
Description: Digital signature
Re: No GRUB with brand-new GPU
On Du, 27 dec 20, 07:08:28, The Wanderer wrote: > On 2020-12-27 at 02:31, Andrei POPESCU wrote: > > > On Sb, 26 dec 20, 17:19:32, The Wanderer wrote: > > > >> With the new GPU in place, I get video output during POST and in > >> the BIOS (yes, this machine is old enough that it doesn't have a > >> UEFI) without problems. That demonstrates that the GPU isn't dead > >> on arrival, and that signal is getting through to the monitor on a > >> basic level. > > > > At this apoint you might want to query your monitor for the > > resolution used, might be helpful in case you want to configure grub > > with a known working resolution (as per other suggestions). > > I know my monitor resolution; it's 2560x1600, and supports many > exact-subset lower resolutions. We know for sure that the card works properly in the specific video mode it is in *during POST* (not latter). This is very unlikely to be the native resolution of your monitor (the BIOS doesn't support that), it's more likely something like 640x480. Your monitor should be able to tell you that (poke its menu / settings). > > Maybe changing some BIOS setting could help. > > I already checked, and didn't see any settings that seemed relevant. > IIRC I did change an unrelated setting which I noticed along the way. > This behavior didn't change afterward. BIOS options are sometimes quite cryptic. You might want to (re-)read the user manual for your motherboard. Basically anything that is PCIe related could be relevant, in addition to the obvious settings for anything graphics related. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: No GRUB with brand-new GPU
On Du, 27 dec 20, 17:31:37, The Wanderer wrote: > > I do see various modules listed in the grub.cfg load_video function, and > it's not impossible that the process of trying to use one or more of > those includes some action which triggers this behavior. I haven't found > a place to configure that, though - or I hadn't until now; it's in > /etc/grub.d/00_header, and can be overridden to a single module by > defining GRUB_VIDEO_BACKEND (presumably, in /etc/default/grub). For testing purposes you could just edit grub.cfg, even if your changes will be overridden on the next 'update-grub'. At least you'll know if it's a path worth pursuing. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
