Re: [DNG] kernel instabilities
> There is a 5.4.x version > in buster/Beowulf backports, which is the latest LTS release. That > should be new enough, and easier than recompiling from source. > > Greg Yes that’s what I’m currently running. However the kernel version listed in the original email suggested that the person was running Ascii and not Beowulf which is why they would only have access to 4.19 from ascii-backports repository. If someone on Ascii wants a kernel newer than backports then they will have to compile it themselves or upgrade to Beowulf to access beowulf-backports. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel instabilities
On Thu, May 28, 2020 at 07:35:16PM +1000, wirelessduck--- via Dng wrote: > There’s also a slightly newer version 4.19 available from backports > repository. While not as new as the most recent stable kernel, it might be > quicker and easier to test out than compiling as it’s available through apt. > > https://pkginfo.devuan.org/stage/ascii/ascii-backports/linux-image-amd64_4.19+105+deb10u3~bpo9+1.html There is a 5.4.x version in buster/Beowulf backports, which is the latest LTS release. That should be new enough, and easier than recompiling from source. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel instabilities
On Thu, 2020-05-28 at 16:15 -0400, Hendrik Boom wrote: > > I'm on > 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 > GNU/Linux > from the beowulf repository; but then I'm running beowulf for quite > a > while now. > I can't say I understand the version numbers -- both 4.9.0-6 and > 4.9.88? > > -- hendrik Just found that out today. According to the uname manpage, one's the release and one's the version of the kernel. I'll have to pay more attention to upgrades and see which changes more often as I'm not sure. From uname manpage: -r, --kernel-release print the kernel release -v, --kernel-version print the kernel version ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
On Wed, May 27, 2020 at 08:29:05PM -0400, Steve Litt wrote: > On Tue, 26 May 2020 17:51:20 +0200 > Didier Kryn wrote: > > > Le 26/05/2020 à 10:26, Steve Litt a écrit : > > > On Mon, 25 May 2020 10:08:17 -0700 > > > Ian Zimmerman wrote: > > > > > >> On 2020-05-21 14:09, Steve Litt wrote: > > > > > > Thanks for pointing out Shepherd. > > > > > +1. > > > > Questions and remarks: > > > > How much can one trust a program written in the Guile language and > > running as PID1 as suggested? > > My experimentations with Guile > ( http://troubleshooters.com/codecorn/scheme_guile/index.htm ) produced > no results indicating any kind of intermittent or unexpected behavior > in Guile. > > Guile is pure functional programming: With a few eceptions (like > printing), there is no state and no side effects. Loops are done with > recursion, best done with tail recursion. There is a purity of function > unavailable from OOP bolt-ons like C++, Perl, and to a lesser extent > Python. Anyone understanding recursion, functional programming and > lambdas can handle Guile, at least for reasonably simple code. As long > as the Guile interpreter is available on a mounted drive in early boot, > I see no reason for caution about Guile. Guile is an implementation of Scheme. While the functional style of programming us the most common style there, it certaionly does have imperative features for when you need them. It is functional, which I think is a good thing. It's not dogmatically purely functional, which I also think is a good thing. -- hendrik > > I think 80% of us grew up with Procedural or OOP languages and are > familiar with them. Just like OOP requires different thought patterns > than procedural, functional languages require (much) different thought > patterns than Procedural or OOP. So Guile might prove a challenge to > some, not because it's defective or complex in any way, but because > functional programming requires much different thought patterns. > > SteveT > > Steve Litt > May 2020 featured book: Troubleshooting Techniques > of the Successful Technologist > http://www.troubleshooters.com/techniques > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel instabilities
On Thu, May 28, 2020 at 07:49:04AM -0600, 'smee via Dng wrote: > Since you mention 4.19... > > I've got: kernel version: 4.19.98-1 (2020-01-26) kernel release: > 4.19.0-8-amd64cpu: Intel(R) Core(TM) i7- > 3740QM CPU @ 2.70GHz > I mentioned previously that when I run a cpu-heavy application (cpu > cryptominer) for a number of hours (14 hours to failure the only time I > clocked it) I get this problem where the gui freezes to the point that > I have to reboot. This started right after the upgrade to beowulf. > Just a note, all the machines I've upgraded from ascii to beowulf so > far have upgraded the kernel to 4.19. I'm on 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux from the beowulf repository; but then I'm running beowulf for quite a while now. I can't say I understand the version numbers -- both 4.9.0-6 and 4.9.88? -- hendrik > > > > On Thu, 2020-05-28 at 19:35 +1000, wirelessduck--- via Dng wrote: > > > You're very likely required to upgrade to a much newer Kernel > > > version. I > > > suggest you to use the most recent stable kernel version and build > > > it from > > > source ( Not that hard, ask me for help if needed) For me the > > > upgrade > > > fixed the issue. > > > > > > cheers, > > > Andreas > > > > There’s also a slightly newer version 4.19 available from backports > > repository. While not as new as the most recent stable kernel, it > > might be quicker and easier to test out than compiling as it’s > > available through apt. > > > > https://pkginfo.devuan.org/stage/ascii/ascii-backports/linux-image-amd64_4.19+105+deb10u3~bpo9+1.html > > > > If that doesn’t work then I agree that compiling the latest stable > > would be the next choice. > > ___Dng mailing > > list...@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LILO Framebuffer and X screen resolution
On Thu, May 28, 2020 at 08:37:01AM -0700, Ian Zimmerman wrote:
> On 2020-05-23 14:36, Marc Shapiro via Dng wrote:
>
> > I have been using Debian for the last 20+ years. I don't like systemd
> > and that has kept me on Stretch, where I can still use SysV as init. I
> > have tried several times to upgrade to Buster without SysV, but have
> > had no luck. So here I am at Devuan.
>
> You probably already know this, but just in case:
>
> You can do a minimal buster install. That will give you systemd but it
> will be quite easy to replace it with sysvinit before installing any
> more packages. It is easier than it was in jessie and stretch in fact.
>
> Yes, this would mean you need to reinstall all packages, but even that
> is no big deal with dpkg --{get,set}-selections.
>
> This is what I have done - I decided that devuan stable was too far
> behind with package versions for a desktop system.
Or try installing beowulf. That is, I believe, the devuan release
corresponding to buster.
-- hendrik
>
> --
> Ian
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LILO Framebuffer and X screen resolution
On 2020-05-23 14:36, Marc Shapiro via Dng wrote:
> I have been using Debian for the last 20+ years. I don't like systemd
> and that has kept me on Stretch, where I can still use SysV as init. I
> have tried several times to upgrade to Buster without SysV, but have
> had no luck. So here I am at Devuan.
You probably already know this, but just in case:
You can do a minimal buster install. That will give you systemd but it
will be quite easy to replace it with sysvinit before installing any
more packages. It is easier than it was in jessie and stretch in fact.
Yes, this would mean you need to reinstall all packages, but even that
is no big deal with dpkg --{get,set}-selections.
This is what I have done - I decided that devuan stable was too far
behind with package versions for a desktop system.
--
Ian
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel instabilities
Since you mention 4.19... I've got: kernel version: 4.19.98-1 (2020-01-26) kernel release: 4.19.0-8-amd64cpu: Intel(R) Core(TM) i7- 3740QM CPU @ 2.70GHz I mentioned previously that when I run a cpu-heavy application (cpu cryptominer) for a number of hours (14 hours to failure the only time I clocked it) I get this problem where the gui freezes to the point that I have to reboot. This started right after the upgrade to beowulf. Just a note, all the machines I've upgraded from ascii to beowulf so far have upgraded the kernel to 4.19. On Thu, 2020-05-28 at 19:35 +1000, wirelessduck--- via Dng wrote: > > You're very likely required to upgrade to a much newer Kernel > > version. I > > suggest you to use the most recent stable kernel version and build > > it from > > source ( Not that hard, ask me for help if needed) For me the > > upgrade > > fixed the issue. > > > > cheers, > > Andreas > > There’s also a slightly newer version 4.19 available from backports > repository. While not as new as the most recent stable kernel, it > might be quicker and easier to test out than compiling as it’s > available through apt. > > https://pkginfo.devuan.org/stage/ascii/ascii-backports/linux-image-amd64_4.19+105+deb10u3~bpo9+1.html > > If that doesn’t work then I agree that compiling the latest stable > would be the next choice. > ___Dng mailing > list...@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Shepherd [was Re: Mixing different init benefits: was: without-systemd.org not working]
Le 28/05/2020 à 02:29, Steve Litt a écrit : > My experimentations with Guile > ( http://troubleshooters.com/codecorn/scheme_guile/index.htm ) produced > no results indicating any kind of intermittent or unexpected behavior > in Guile. > > Guile is pure functional programming: With a few eceptions (like > printing), there is no state and no side effects. Loops are done with > recursion, best done with tail recursion. There is a purity of function > unavailable from OOP bolt-ons like C++, Perl, and to a lesser extent > Python. Anyone understanding recursion, functional programming and > lambdas can handle Guile, at least for reasonably simple code. As long > as the Guile interpreter is available on a mounted drive in early boot, > I see no reason for caution about Guile. > > I think 80% of us grew up with Procedural or OOP languages and are > familiar with them. Just like OOP requires different thought patterns > than procedural, functional languages require (much) different thought > patterns than Procedural or OOP. So Guile might prove a challenge to > some, not because it's defective or complex in any way, but because > functional programming requires much different thought patterns. Computer languages are IMHO the best concentrate of human intelligence which have been put into the domain of software. The closer they are to human concepts, the most power and freedom they give to the programmer. In this respect, functionnal languages are certainly more expressive than imperative ones. However Shepherd as PID1 goes against the common wisdom that init must be oversimple - see the exemple of Rich Felker, but Laurent Bercot would certainly be on the same side. Shepherd might live with sysv-init, in particular if it could be a subreaper. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel instabilities
> You're very likely required to upgrade to a much newer Kernel version. I > suggest you to use the most recent stable kernel version and build it from > source ( Not that hard, ask me for help if needed) For me the upgrade > fixed the issue. > > cheers, > Andreas There’s also a slightly newer version 4.19 available from backports repository. While not as new as the most recent stable kernel, it might be quicker and easier to test out than compiling as it’s available through apt. https://pkginfo.devuan.org/stage/ascii/ascii-backports/linux-image-amd64_4.19+105+deb10u3~bpo9+1.html If that doesn’t work then I agree that compiling the latest stable would be the next choice.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel instabilities
Hi Ricardo, On Thu, May 28, 2020 at 09:24:59AM +0200, Riccardo Mottola via Dng wrote: > I just tried adding "contrib" to my repositories and I see intel microcode > is available, I hope it helps. > > Do you know how this "update" works? will it be applied also when running > older kernels? Typically the microcode update will be prepend to the normal init-ramdisk image during creation of the init-ramdisk. The kernel will load this microcode in a very early stage. See following link for details https://wiki.debian.org/initramfs I remind that I had several issues with some Intel atom based celeron and certain kernel versions. There is a problem with the power saving in these cpus which was not handled properly in the Kernel. Starting with some kernel which used more aggresive power savings, the machine started crashing randomly. I think the problem is not limited to celerons it seems to persist since a while now, more or less solved for some usecases. It relates to the internal GPU of the processors. See here: https://bugzilla.kernel.org/show_bug.cgi?id=109051 You're very likely required to upgrade to a much newer Kernel version. I suggest you to use the most recent stable kernel version and build it from source ( Not that hard, ask me for help if needed) For me the upgrade fixed the issue. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf Kernel Panic on Qemu - 202005214
On 5/21/20 1:10 PM, c...@free.fr wrote: > the actual boot starts... and ends with : maybe there are some other helpful messages in between.. anything like "VFS: x" ? another thing to check, is iso's sha256sum correct? signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel instabilities
Hi all let me resurrect this thread. I am now working on this computer regular, lockdown has lessened here in Italy and I hope all you Devuaners are in good help. Unfortunately stability did not improve much On 3/18/20 4:28 PM, Hendrik Boom wrote: (1) Do we even know it's a kernel problem? (2) They don't seem to be specific to a particular kernel; Of course they might have entirely different causes. (3) Is Debian having similar probems? (4) Might it be something in the way the kernel is being used? Perhaps something takes over the mouse, touchpad, and keyboard so that the user becomes helpless? (5) Surely there is some relevant partial shutdown, dumping, and/or logging procedure that would provide clues? We know it is a kernel problem since I can boot 4.9.0-11 boots fine (typing right now) while 4.9.0-12 crashes very soon (sometimes you can get to X and it freezes right thereafter) but most often it freezes directly at boot. It is a hard freeze. My CPU is: model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz I just tried adding "contrib" to my repositories and I see intel microcode is available, I hope it helps. Do you know how this "update" works? will it be applied also when running older kernels? I do not see it applied in dmesg when running 4.9.0-11 grep "microcode updated early to" returns nothing. Also I wonder if when running 4.9.0-12 it is applied early enough and if it would help at all. I tried running 4.9.0-12 in recovery mode and I see the crash of the kernel. (I did attach a screenshot, but it cannot fit inside the 40K of this mailing list, so I am removing it) Riccardo ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
