Re: [DNG] installation images
On Thu, 2022-09-08 at 12:29 +0100, Peter Duffy wrote: > On Thu, 2022-09-08 at 21:21 +1000, Ralph Ronnquist wrote: > > On Thu, Sep 08, 2022 at 11:46:50AM +0100, Peter Duffy wrote: > > > I assume that at some point, the installation iso images are > > > going > > > to > > > be rebuilt to include the new devuan-keyring package? Until this > > > is > > > done, a devuan install can only be completed by using the > > > wget/chroot/dpkg kludge. > > > > > > Given LP's move to M$, there's probably more interest than usual > > > in > > > devuan and other non-systemd distros at the moment - so maybe > > > this > > > needs doing quite urgently. > > > > > > I did manage to rebuild the chimaera netinstall image with the > > > new > > > devuan-keyring package yesterday (I needed to install several > > > chimaera > > > VMs, and it was an interesting challenge). The new image appears > > > to > > > work (install on a virtualbox VM completed without a problem, and > > > the > > > VM booted fine). If it would be helpful, I'm happy to give > > > details > > > of > > > how I did it - but I'm conscious that although it seems to work, > > > my > > > new > > > image is probably slightly different from the original, and I > > > don't > > > want to muddy any waters. The best by far would be to have new > > > images > > > available, built using the standard process. On the other hand, > > > it > > > might be good for the process of generating debian/devuan > > > installation > > > images to be more widely known (there doesn't seem to be a lot of > > > information on the web about it, and what there is seems mostly > > > to > > > be > > > out-of-date and/or broken). > > > > To build a chimaera netinstall, the following command sequence > > might > > work: > > > > $ git clone https://git.devuan.org/devuan/installer-iso.git > > $ cd installer-iso > > $ TRIAL=yes ./build-sudo chimaera netinstall 4.2.meown > > > > You obviusly need sudo, or you may run it as root. > > > > That scripting will firstly debootstrap a chimaera installer > > building > > hosting filesystem, then chroot into that for the actual iso > > building. > > The resulting ISO ends up at chimaera.$ARCH.fs/installer-iso/ with > > the > > name of netinstall-$ARCH.iso. > > > > I'm doing like that so it must work the same for everyone ;) > > > > Ralph. > > Thanks for that - I was hoping that the tools to do this were > generally > available. I'll give it a try. > That worked fine - the image built successfully, and an install from it on a virtualbox VM was also successful. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] installation images
On Thu, 2022-09-08 at 21:21 +1000, Ralph Ronnquist wrote: > On Thu, Sep 08, 2022 at 11:46:50AM +0100, Peter Duffy wrote: > > I assume that at some point, the installation iso images are going > > to > > be rebuilt to include the new devuan-keyring package? Until this is > > done, a devuan install can only be completed by using the > > wget/chroot/dpkg kludge. > > > > Given LP's move to M$, there's probably more interest than usual in > > devuan and other non-systemd distros at the moment - so maybe this > > needs doing quite urgently. > > > > I did manage to rebuild the chimaera netinstall image with the new > > devuan-keyring package yesterday (I needed to install several > > chimaera > > VMs, and it was an interesting challenge). The new image appears to > > work (install on a virtualbox VM completed without a problem, and > > the > > VM booted fine). If it would be helpful, I'm happy to give details > > of > > how I did it - but I'm conscious that although it seems to work, my > > new > > image is probably slightly different from the original, and I don't > > want to muddy any waters. The best by far would be to have new > > images > > available, built using the standard process. On the other hand, it > > might be good for the process of generating debian/devuan > > installation > > images to be more widely known (there doesn't seem to be a lot of > > information on the web about it, and what there is seems mostly to > > be > > out-of-date and/or broken). > > To build a chimaera netinstall, the following command sequence might > work: > > $ git clone https://git.devuan.org/devuan/installer-iso.git > $ cd installer-iso > $ TRIAL=yes ./build-sudo chimaera netinstall 4.2.meown > > You obviusly need sudo, or you may run it as root. > > That scripting will firstly debootstrap a chimaera installer building > hosting filesystem, then chroot into that for the actual iso > building. > The resulting ISO ends up at chimaera.$ARCH.fs/installer-iso/ with > the > name of netinstall-$ARCH.iso. > > I'm doing like that so it must work the same for everyone ;) > > Ralph. Thanks for that - I was hoping that the tools to do this were generally available. I'll give it a try. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] installation images
I assume that at some point, the installation iso images are going to be rebuilt to include the new devuan-keyring package? Until this is done, a devuan install can only be completed by using the wget/chroot/dpkg kludge. Given LP's move to M$, there's probably more interest than usual in devuan and other non-systemd distros at the moment - so maybe this needs doing quite urgently. I did manage to rebuild the chimaera netinstall image with the new devuan-keyring package yesterday (I needed to install several chimaera VMs, and it was an interesting challenge). The new image appears to work (install on a virtualbox VM completed without a problem, and the VM booted fine). If it would be helpful, I'm happy to give details of how I did it - but I'm conscious that although it seems to work, my new image is probably slightly different from the original, and I don't want to muddy any waters. The best by far would be to have new images available, built using the standard process. On the other hand, it might be good for the process of generating debian/devuan installation images to be more widely known (there doesn't seem to be a lot of information on the web about it, and what there is seems mostly to be out-of-date and/or broken). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Key is expired
On Tue, 2022-09-06 at 11:33 -0600, Chris Dos wrote: > I also had to manually delete the previous key in order for this to > work: > apt-key del "E032 601B 7CA1 0BC3 EA53 FA81 BB23 C00C 61FC 752C" > > After that: > wgethttp://deb.devuan.org/devuan/pool/main/d/devuan-keyring/devuan-keyring_2022.09.04_all.deb > sudo dpkg -i devuan-keyring_2022.09.04_all.deb > sudo apt update > > Just spent that last few hours updating all our Devuan servers. May > want to put this information on the home page or something. > > Chris > I've not found that I needed to do the "apt-key del" step for it to work - I just do the wget and then the dpkg. After that, all seems fine. Did you find that you needed to delete the old key for the new one to work? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] chimaera install problem
On Tue, 2022-09-06 at 17:46 +0100, Peter Duffy wrote: > Ralph, thanks for the workaround - it worked fine. I had been trying > something similar, but I'd forgotten about the chroot. (Or to coin a phrase, close but no ch(e)root ;) ) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] chimaera install problem
On Tue, 2022-09-06 at 23:02 +1000, Ralph Ronnquist wrote: > > The required hands-on to make use of the current installer ISOs > includes the use of wget and dpkg at the point where the installation > first breaks, though probably only via a C-A-F2 escape to a root > shell > while the installation (at C-A-F1) is blocked and waiting on the > error > report dialog. > > At that point you use wget to grab the devuan-keyring package > http://deb.devuan.org/merged/pool/DEVUAN/main/d/devuan-keyring/devuan-keyring_2022.09.04_all.deb > and store that at /target, so you can follow up with manual > installation into /target, by: > # chroot /target /usr/bin/dpkg -i devuan-keyring_2022.09.04_all.deb > > Following that, you re-enter the installation at C-A-F1 and select > "continue" so that it re-tries with the failing step using the the > updated keyring. > > On the side of all that I should add that I also taken have the > opportunity to polish the installer-iso project so that it easily > builds ISOs for the old releases. Some trial builds of that are > currently available for testing at https://ido.rrq.id.au/download Ralph, thanks for the workaround - it worked fine. I had been trying something similar, but I'd forgotten about the chroot. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] chimaera install problem
Adrian and Olaf - thanks for the comments. This is definitely the expired key problem - so at the moment, chimaera can't be installed via the netinstall image. Probably the same for other devuan versions. Adrian - I tried changing the date as you suggested. That doesn't work - I now get a message in the log saying: "http://deb.devuan.org/merged/dists/chimaera/InRelease is not valid yet" I found that I could get the install to complete if I told it to ignore the error, and the resulting system would boot. However, it's obviously just the bare-bones base system from the netinstall image. Are the netinstall images going to be re-generated fairly soon? If not, is it worth while thinking of a way of importing the new key into the install process? On Mon, 2022-09-05 at 16:49 +0100, Peter Duffy wrote: > Sorry if this has been addressed before - I did look through the > posts, > but couldn't see anything relevant. Also sorry if I'm missing > something > obvious. > > I'm trying to install chimaera on a virtualbox VM, using the > netinstall > image (devuan_chimaera_4.0.0_amd64_netinstall.iso, dated Nov 18 2021) > - > I've done this many times before, without a problem. This time, when > I > get to "configure the packet manager", it comes back with "The > installer failed to access the mirror". I used wireshark to check > that > it's talking to the network and the server - it appears to be doing > so > (accessing server at 95.216.15.86). > > I'm wondering if it could be another effect of the recent key expiry > problem. > > > > ___ > 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
[DNG] chimaera install problem
Sorry if this has been addressed before - I did look through the posts, but couldn't see anything relevant. Also sorry if I'm missing something obvious. I'm trying to install chimaera on a virtualbox VM, using the netinstall image (devuan_chimaera_4.0.0_amd64_netinstall.iso, dated Nov 18 2021) - I've done this many times before, without a problem. This time, when I get to "configure the packet manager", it comes back with "The installer failed to access the mirror". I used wireshark to check that it's talking to the network and the server - it appears to be doing so (accessing server at 95.216.15.86). I'm wondering if it could be another effect of the recent key expiry problem. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Key is expired
Ludovic, thanks for that. Confirmed that the new key seems to work, and upgrade now in process. One point which I'm sure is obvious, but just thought I'd mention it: "dpkg " => "dpkg -i " On Sat, 2022-09-03 at 19:27 +0200, Ludovic Bellière via Dng wrote: > Hello list, > > In order to resolve the gpg key being outdated, the following steps > needs to be taken: > > wget > http://deb.devuan.org/devuan/pool/main/d/devuan-keyring/devuan-keyring_2022.09.04_all.deb > sudo dpkg devuan-keyring_2022.09.04_all.deb > sudo apt update > > Cheers, > Ludovic > > > On Sat, 03 Sep 2022, Elimar Riesebieter wrote: > > > > > Hi all, > > > > the signing key 'Devuan Repository (Amprolla3 on Nemesis)' is > > expired: > > > > W: GPG error: http://deb.devuan.org/merged stable InRelease: The > > following signatures were invalid: EXPKEYSIG BB23C00C61FC752C > > Devuan Repository (Amprolla3 on Nemesis) > > > > Elimar > > -- > ___ > 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] article about devuan
On Mon, 2022-08-01 at 11:39 +0100, Peter Duffy wrote: > If one of the IT > news sites like register.com got interested in the debate, it would > probably be good publicity for devuan, if nothing else. For "register.com", read "theregister.com". Apologies - I should have checked before posting. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] article about devuan
On Sun, 2022-07-31 at 09:09 -0500, goli...@devuan.org wrote: > On 2022-07-31 07:29, Peter Duffy wrote: > > > > Is it worth while considering putting a link to the article on > > devuan.org, together with a response answering the criticisms in > > detail? > > > > devuan.org is not a social news service for trivia. If any Devuan > articles were to be posted, it should be these: > > http://dev1galaxy.org/files/Linux_Magazine_171_Reprint_Devuan.pdf > http://dev1galaxy.org/files/Linux_Magazine_Reprint_Devuan.pdf > > But beating our own drum publicly invites a response and we really > don't > need to stir that pot again . . . IMO, of course. > > We are #2 in Distrowatch rankings (from user reviews not ratings ie > the > bean counter). That speaks for itself. Run silent, run deep . . . > > golinux For what it's worth, here's my own view. The article makes claims about, and accusations against, devuan which either deliberately or from misconceptions are clearly erroneous. The question is whether or not these claims could damage the reputation of devuan and put people off trying it. If not - we don't need to do anything. But if so - there should be a rebuttal of the claims and accusations. It could be done by posting a comment in response to the original article. But that would originate from - or at least would appear to originate from - a single individual, and unless the response was discussed and debated beforehand, it would probably clash to some extent with the collective views of the devuan community. An "official" and semi-permanent response posted on devuan.org or in some other appropriate place would be seen as coming from the devuan project as a whole. If one of the IT news sites like register.com got interested in the debate, it would probably be good publicity for devuan, if nothing else. As I say - if we take the view that the article is a storm in a teacup, to be forgotten soon, we probably don't need to do anything. I know the value of "run silent, run deep". But my own current motto - in connection with systemd and just about everything else which is happening and not happening at the moment - is: "Do not go gentle into that good night: rage, rage against the dying of the light". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] article about devuan
On Sat, 2022-07-30 at 06:07 -0400, Steve Litt wrote: > On Fri, 2022-07-29 at 14:27 +0200, tito via Dng wrote: > > https://linuxiac.com/best-systemd-free-linux-distributions/ > > > > I think the author knows nothing about devuan and spreads FUD > > > > I thought most of the Devuan review was accurate and complimentary. > However, I've > never thought of Devuan as "retro" or particularly inconvenient for > newbies. > > SteveT Very strange article. On one hand, he does include devuan in his "five best proven . . . ". On the other - some of his comments are just baffling. "many of the useful graphical tools that modern Linux users are used to are absent." Eh? I wonder if the author isn't aware of the fact that there's a range of different window managers and front-ends, each with a different look-and-feel, and that all of them are available in all distros. The author describes himself as a "linux professional", so he should be aware of it. "To use and understand Devuan, you must change your mindset and perception of the distribution’s core beliefs". That's just bizarre. Is he talking about the "core beliefs" of debian, or of linux in general? Either way - devuan reinstates and re-emphasises the "core beliefs". "However, as is fortunately always the case in open source software, users always have a choice." Except that in the case of systemd-based distros, it's Hobson's choice: use any init system you want, provided it's systemd. If the author had ever become aware of this, he's looking the other way now. Is it worth while considering putting a link to the article on devuan.org, together with a response answering the criticisms in detail? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Lennart now working for Microsoft
On Wed, 2022-07-13 at 15:49 -0500, hal wrote: > On July 13, 2022 3:31:37 PM CDT, Syeed Ali > wrote: > :: Microsoft has a great interest in embracing Linux via WSL with the > :: intent to obsolete the need to dual boot. With many critical > :: distributions and software requiring systemd, it only makes sense > to > :: make sure that WSL has complete support; indeed better support > than on > :: Linux. Combined Windows and WSL can thereby be extended nicely in > ways > :: pure Linux cannot. > :: > :: ___ > :: Dng mailing list > :: Dng@lists.dyne.org > :: https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > Microsoft has only an interest in not having any competition. from > DOS, to Internet Explore vs. Netscape, to SCO Linux. Every few years > they try again. this is all just another example. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I'm sure that is correct. M$ were obviously behind the SCO thing. Thank heavens for groklaw - without Pamela Jones, SCO's legal action might have succeeded, and we might now be paying them for linux licences (or using something else). I do find it interesting that Red Hat haven't commented on Poettering's departure as yet (or at least, I haven't seen any comment from them so far). M$ and IBM haven't always been rivals - worth remembering that OS/2 was originally a joint venture. Then they decided to go their separate ways and fork the OS/2 project: IBM carried on developing OS/2; M$ hacked their version into Windows 95 (remember they took over the front page of the Times to advertise the launch of it?). (Shame that OS/2 vanished off the radar. I used it daily for a number of years: it was infinitely better than windows.) Obviously something's going on. I guess time will tell what it is. For now, it at least seems extremely good news that systemd is now firmly tarred with the M$ brush. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Lennart now working for Microsoft
The waters do seem very muddy at the moment. The one thing which seems self-evident is that if Poettering is continuing to work on systemd, it's not going to be in his spare time - so that means that it's going to be in the context of M$, and almost certainly in that of WSL. I'd give a lot to know what's currently passing between Poettering and Kay Sievers. Sievers is still at Red Hat - so far anyway. I wonder if M$ and Red Hat are negotiating some sort of deal. On Tue, 2022-07-12 at 10:35 +0200, Edward Bartolo via Dng wrote: > Let me understand... So, this excellent coder first grabs the > opportunity offered to him by RedHat, and now, after the latter made > him rich, he is leaving them! Please, anyone explain to me, how can > anyone extend a day beyond the usual 24 hours? Systemd is not a > simple > game like the many one can find, it is literally a very complex piece > of software with many functions that hardly can be logically imagined > to be produced by the same project. This latter fact, is asking for > more systemd problems. > > Regrettably, I have it running on my raspberry pi mini-computer > because I could not find a way to let the OS recognise and use an > IQAudIO DAC PRO hat (a sound card). If Devuan can do it, that would > be > the death knell of my installation using the blessed systemd. > > Thanks to all for using and supporting Devuan. > ___ > 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] Lennart now working for Microsoft
It's an interesting development, and in a strange way it feels as though it's been coming. IBM owns Redhat and M$ owns systemd (Poettering has said that he's continuing to work on systemd. Presumably that's not going to be in his spare time ;) ). I wonder how that's going to play out. Maybe M$ will make IBM an offer for Redhat. It seems to me that at the very least, the fact that systemd is now M$- tainted is going to make a lot more people start to think about dropping it. That's probably good news for Devuan, and other distros that have already eschewed systemd. On Fri, 2022-07-08 at 19:30 +0200, Harald Arnesen via Dng wrote: > Steve Litt [08/07/2022 15.57]: > > > What scares me is if he starts putting Microsoft-centric stuff in > > systemd, Linux will need to either migrate away from systemd > > Wouldn't that be what we all want? > > or be > > subsumed by microsoft. > > Won't happen. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Microsoft azure and devuan
Quite a long time ago, I mentioned that I'd been tasked with upgrading some linux VMs running under Microsoft Azure, and had decided to try to use devuan. I then found that devuan wouldn't work under azure. The problem was walinuxagent - aka waagent and azurelinuxagent, the glue layer which sits between the azure infrastructure and linux, and enables azure to do things like start and stop VMs and collect stats and metrics. It didn't work properly under devuan. It turned out that there were actually two problems: - walinuxagent needs to know about each supported distro, and hadn't been told about devuan: the default for unsupported distros was to assume that systemd was present. - to determine the distro under which it was running, walinuxagent used the python function platform.linux_distribution. This was incapable of distinguishing between devuan and debian (when run under devuan, it claimed that the distro was debian). Figuring out the context of the problem was difficult. It wasn't a devuan problem, as the walinuxagent package is taken directly from the debian repo; it wasn't a debian problem as the problem was in walinuxagent; the first part of the problem could be fixed by telling walinuxagent about devuan; python already had a new module/function distro.linux_distribution which was able to distinguish between debian and devuan, and walinuxagent fell back to this if platform.linux_distribution was not found - but if the latter was available, it would use it. Eventually, I decided to work on this myself. The walinuxagent repo is on github, so I forked it onto my own github account. Adding devuan as a known distro was fairly trivial (there's a structure built into walinuxagent to enable extra distros to be added and to tell it whether or not to use systemd). I then wrote a chunk of extra python code which would be called whenever platform.linux_distribution() was called and returned a result of "debian", and would re-check to see if it was really devuan. I got this all to work, and created an azure VM running devuan (beowulf). It seemed to work fine (the VM has now been in service for over 1.5 years). I then raised a pull request on the upstream azure walinuxagent repo to merge my changes. My pull request was acknowledged and put up for a code review - but for some reason, nothing further happened for a long time (maybe it was to do with problems caused by the pandemic). I have to admit that I had concerns about my extra code. I'd done extensive testing - but it was a big chunk of code which referenced a number of things in the linux environment, any of which could change independently of walinuxagent. I was conscious that if it was merged into the main repo, it would eventually get run on every debian-based VM in azure, and if there was something that I'd overlooked and which caused problems, it would cause problems on all of them. To put it mildly, that would probably be Bad News. Then chimaera appeared - and from my point of view, there was one extremely useful enhancement: debian bullseye, and therefore devuan chimaera, had moved to python 3.9. In python 3.8, the buggy and unreliable platform.linux_distribution had been removed. This forced walinuxagent to use distro.linux_distribution - and as this could distinguish between debian and devuan, my extra python code wasn't needed any more. So I cancelled the old pull request and started again, and this time just made the changes to walinuxagent to allow it to recognise devuan and use non-systemd utilities and functions on the VM. I then raised another pull request on the azure walinuxagent upstream repo, and after correcting a few issues, I heard on Wednesday that my changes have been merged. So when the next release of walinuxagent appears in the distros, it should support devuan. This should make it generally possible to run devuan VMs under azure. If anyone wants to have a look at my code, it can be cloned from my github account: https://github.com/peter9370/WALinuxAgent The version which works on chimaera and hopefully later releases is in the branch "devuan_support_new". There's also a branch "devuan_support_pre_chimaera" which contains the version including my extra code, which worked on beowulf. I'm not sure when the next release is due: I'll keep an eye on the upstream repo. Apologies for the length of that - it's been a long journey, and difficult to summarise concisely. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] grub 2.04 and kernel 2.6
One additional point. When I installed beowulf on the box with the GT1030 card, the display was fine. It was only when I upgraded to chimaera that the problem started. Don't know if firmware-misc-nonfree is installed by default in beowulf and then removed by the chimaera upgrade - at some point, I'll try this. On Tue, 2022-02-15 at 10:27 +, Peter Duffy wrote: > I wasn't quite there! > > The upgrade to grub 2.06 fixed the boot problem - but when I booted into > chimaera, it came up with a major graphics problem - 640x480 display, no > tty sessions available, and /dev/dri and /dev/fb0 didn't exist: messages > in /var/log/Xorg.0.log saying that the framebuffer couldn't be created. > Graphics driver is nouveau: I considered trying NVidia's own driver, but > I couldn't even boot into rescue mode - the boot sequence never reached > the command prompt! > > I mentioned that I have two identical boxes on which I'm working these > problems. Hardware is ASUS H310M motherboard; Intel i5-9600K (6-core); > 16g RAM. (It's strange that I've got the two boxes: I accidentally > bought two lots of this kit, and decided to keep the second set as > spares - I then decided to use them to upgrade the old box. Am I ever > glad that I did so ...) > > However, the two boxes are not quite identical - one has NVidia GT610 > (bought in 2013), the other has an NVidia GT1030 (bought this year). > After upgrading beowulf to chimaera and upgrading to grub 2.06, the > chimaera installation on the box with the old NV card worked fine. It > was the one with the new NV card where the graphics borked. > > I swapped the primary disks between the two boxes. The problem was still > on the box with the new NV card. > > I did some googling and fortunately found a post which gave me the > solution. I had to install firmware-misc-nonfree. After this, the > graphics were fine on both boxes. Interesting that the new card required > firmware, whereas the old one didn't. > > Why NVidia rather than Radeon? I've tried both over the years - but I've > stuck with NV because I just find that the "look" seems to be better - > the display usually seems more solid (less perceptible flicker), the > colours seem clearer, and (especially) the fonts seem more readable. > > On Mon, 2022-02-14 at 18:23 +, Peter Duffy wrote: > > > That fixed the problem! All three systems - chimaera, win7 and CentOS - > > now boot successfully. > > > ___ > 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] grub 2.04 and kernel 2.6
I wasn't quite there! The upgrade to grub 2.06 fixed the boot problem - but when I booted into chimaera, it came up with a major graphics problem - 640x480 display, no tty sessions available, and /dev/dri and /dev/fb0 didn't exist: messages in /var/log/Xorg.0.log saying that the framebuffer couldn't be created. Graphics driver is nouveau: I considered trying NVidia's own driver, but I couldn't even boot into rescue mode - the boot sequence never reached the command prompt! I mentioned that I have two identical boxes on which I'm working these problems. Hardware is ASUS H310M motherboard; Intel i5-9600K (6-core); 16g RAM. (It's strange that I've got the two boxes: I accidentally bought two lots of this kit, and decided to keep the second set as spares - I then decided to use them to upgrade the old box. Am I ever glad that I did so ...) However, the two boxes are not quite identical - one has NVidia GT610 (bought in 2013), the other has an NVidia GT1030 (bought this year). After upgrading beowulf to chimaera and upgrading to grub 2.06, the chimaera installation on the box with the old NV card worked fine. It was the one with the new NV card where the graphics borked. I swapped the primary disks between the two boxes. The problem was still on the box with the new NV card. I did some googling and fortunately found a post which gave me the solution. I had to install firmware-misc-nonfree. After this, the graphics were fine on both boxes. Interesting that the new card required firmware, whereas the old one didn't. Why NVidia rather than Radeon? I've tried both over the years - but I've stuck with NV because I just find that the "look" seems to be better - the display usually seems more solid (less perceptible flicker), the colours seem clearer, and (especially) the fonts seem more readable. On Mon, 2022-02-14 at 18:23 +0000, Peter Duffy wrote: > That fixed the problem! All three systems - chimaera, win7 and CentOS - > now boot successfully. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] grub 2.04 and kernel 2.6
I cloned the grub git repo from
https://salsa.debian.org/grub-team/grub.git
- and then, using the git command-line environment and "set debug=all",
I narrowed the problem down to the file grub-core/loader/i386/linux.c,
somewhere between lines 798 and 891. ("debug=all" causes a lot of
messages showing what's happening and whereabouts in the code it is:
very useful feature. I tried using the "linux" command to load the v2
kernel (crashed) and then a v4 kernel image (loaded successfully)).
However, in spite of various git diffs, I wasn't getting anywhere fast -
so I decided to try a line of less resistance. Working on the assumption
that whatever the problem was, someone by now had probably spotted and
fixed it, I downloaded the packages for grub 2.06-2 via
https://pkginfo.devuan.org/cgi-bin/package-query.html
- and installed them on the chimaera system, over 2.04-20.
That fixed the problem! All three systems - chimaera, win7 and CentOS -
now boot successfully.
I had to make one change to /etc/default/grub - I added the line:
GRUB_DISABLE_OS_PROBER="false"
(that seems to have been introduced since 2.04-20, and apparently
defaults to true).
So - something got broke and was then fixed. It would be nice to know
what. But in the meantime - this definitely feels like progress :)
On Sun, 2022-02-13 at 21:05 +, Peter Duffy wrote:
> I've got an old box running CentOS 6.2 and Windows 7. Without going into
> details, this box is vital and I use it every day. Finally I decided
> that I had to bite the bullet and upgrade the linux system, and I
> decided to go for chimaera.
>
> Built a new box from scratch and cloned all the disks, using dd, to
> fresh HDDs (there are several big data disks in the box). Made another
> clone of the first disk just for safety's sake, then installed chimaera
> on free space on the first disk - successful; chimaera and windows 7
> both booted fine. But CentOS 6.2 wouldn't boot - sometimes automatic
> reboot, sometimes blank screen and hung box.
>
> Switched back to the latest clone disk, which fortunately booted
> successfully, made a fresh clone of the working disk, then tried again:
> this time, installed beowulf. Install was successful - and this time
> devuan, windows 7 and CentOS 6.2 all booted successfully.
>
> Took another safety clone of the first disk (I'm beginning to wonder if
> I've exhausted the world's stock of 2T HDDs) and then upgraded beowulf
> to chimaera. Upgrade successful. Again, the CentOS 6.2 system wouldn't
> boot.
>
> CentOS 6.2 uses kernel 2.6 - it's possible to upgrade to a later one,
> but this is frowned upon. I suppose it's based on RedHat and
> derivatives' policy of setting a base version per distro and then
> retrofitting updates. (I did once try upgrading to a v4 kernel, and the
> system became completely unstable.)
>
> Removed the primary disk, put in the clone with beowulf installed, and
> verified that all was still working. Then put the disk with chimaera in
> another box with identical hardware, and started digging into the
> problem. Grub on chimaera = 2.04-20; on beowulf = 2.02+dfsg1-20
> +deb10u4. Booted into chimaera and downloaded the packages for the
> beowulf grub release (grub2, grub2-common, grub-common, grub-pc, and
> grub-pc-bin), and used them to downgrade grub on the chimaera system -
> successful. Rebooted - CentOS 6.2 now boots. Tried going into the grub
> command line environment on each box, and using the "linux" command to
> load the 2.6 kernel image: result was in grub 2.02, it works fine, and
> in 2.04, the box reboots at that point.
>
> So current conclusion is that something has happened between grub 2.02
> and 2.04 which prevents the latter from loading linux v2 kernels. The
> challenge now is to find out what, and if it's possible to work around
> it in grub 2.04. (I should say that I originally assumed that the
> problem was down to moving a disk (or a clone of it) from a non-UEFI
> environment to a UEFI one - but setting everything in the firmware to
> "legacy only" didn't have any effect.)
>
> Just wondered if anyone had any thoughts and comments (other than why
> the hell am I still running CentOS 6.2 on this box), before I start
> rummaging through the grub changelogs. Apologies for the length of this
> and also if I've missed something obvious. The above is a heavily
> boiled-down summary of about a fortnight of stress and lost sleep.
>
> ___
> 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] grub 2.04 and kernel 2.6
On Mon, 2022-02-14 at 06:57 -0500, Curtis Maurand wrote: > Wow. Nice piece of troubleshooting. Thanks :) Not there yet though - still some way to go ;) > Have you thought about virtualizing some of this? I have a windows 7 > machine that I virtualized a long time ago. I just move it from host to > host. VMWare has a free tool that will convert your physical machine to > a virtual machine. qemu has tools to convert from vmdk (vmware virtual > machine format) to qcow2 for kvm. Even better, you can run them at the > same time. :-) > > Just a thought. > -Curtis I have another box that I use principally for VMs (ryzen 7 16-core with 64g ram) and on that, I've got both windows 7 and 10 VMs - but I'm still trying to migrate the software from the physical to the virtual systems. There are strange dependencies which just don't seem to work in the VMs (they're virtualbox-based - I might have more success with vmware). Also - worth keeping in mind that after the chimaera upgrade and with grub 2.04, windows 7 boots fine. It's the CentOS 6.7 linux system which won't boot! :( ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] grub 2.04 and kernel 2.6
A couple of afterthoughts on this (after starting to work on the bug). The CentOS system is actually 6.7, not 6.2 as I'd thought. It has been upgraded fairly regularly over the years. The kernel isn't vanilla 2.6 - it contains a vast number of patches retrofitted by Red Hat (the version number is 2.6.32-696.16.1). On Sun, 2022-02-13 at 22:56 +, Peter Duffy wrote: > Hi Emanuel > > Thanks for that link. It's OK - I'm not hosting websites on my CentOS 6 > box! There are a number of reasons why I've been terrified of trying to > upgrade this box up to now - and the experience of the last fortnight > has tended to confirm most of my existing fears and add a few more > besides. I'm just glad that I decided to take a clone of the hard disk > before starting the upgrade. > > If the grub guys have just arbitrarily decided not to support kernel v2, > then it was probably a bit high-handed of them. Red > Hat/CentOS/Scientific Linux/Oracle version 6 was the last version before > systemd'struction, and I suspect that there may be quite a lot of boxes > around still running it. > > > On Sun, 2022-02-13 at 23:09 +0100, Emanuel Loos via Dng wrote: > > Hello Peter, > > > > looks like someone else is experiencing the same issue (though there > > where no answers yet): > > > > https://www.linuxquestions.org/questions/linux-kernel-70/gnu-grub-version-2-04-you-need-to-load-the-kernel-first-4175707760/ > > > > I don't see version 2 of the Linux kernel listed on https://kernel.org/ > > so if you are hosting websites there how is this secure? If you want a > > stable kernel, how about a longterm version? How about configuring and > > compiling it yourself so it matches your needs best? > > > > By the way: They are GNU/Linux or GNU+Linux distributions, Devuan calls > > itself a GNU+Linux distribution, Debbian calls itself a GNU/Linux > > distribution. They are all based on the GNU operating system with the > > Linux kernel. > > > > The GNU Project, developing an operating system that's completely free > > software (as in freedom, not free beer), was the start of the free > > software movement, long before Open Source existed, but it doesn't get > > acknowledged that much since companies are okay with the idea of Open > > Source (viewing releasing the source code as a good idea sometimes, > > because it is more profitable), but really don't like the idea of free > > software (viewing the freedom of computer users as a must and not > > granting the four essential freedoms of free software when releasing > > software as something unethical which does harm to society). > > > > Kind Regards > > > > Emanuel Loos > > > > On 2/13/22 10:05 PM, Peter Duffy wrote: > > > I've got an old box running CentOS 6.2 and Windows 7. Without going into > > > details, this box is vital and I use it every day. Finally I decided > > > that I had to bite the bullet and upgrade the linux system, and I > > > decided to go for chimaera. > > > > > > Built a new box from scratch and cloned all the disks, using dd, to > > > fresh HDDs (there are several big data disks in the box). Made another > > > clone of the first disk just for safety's sake, then installed chimaera > > > on free space on the first disk - successful; chimaera and windows 7 > > > both booted fine. But CentOS 6.2 wouldn't boot - sometimes automatic > > > reboot, sometimes blank screen and hung box. > > > > > > Switched back to the latest clone disk, which fortunately booted > > > successfully, made a fresh clone of the working disk, then tried again: > > > this time, installed beowulf. Install was successful - and this time > > > devuan, windows 7 and CentOS 6.2 all booted successfully. > > > > > > Took another safety clone of the first disk (I'm beginning to wonder if > > > I've exhausted the world's stock of 2T HDDs) and then upgraded beowulf > > > to chimaera. Upgrade successful. Again, the CentOS 6.2 system wouldn't > > > boot. > > > > > > CentOS 6.2 uses kernel 2.6 - it's possible to upgrade to a later one, > > > but this is frowned upon. I suppose it's based on RedHat and > > > derivatives' policy of setting a base version per distro and then > > > retrofitting updates. (I did once try upgrading to a v4 kernel, and the > > > system became completely unstable.) > > > > > > Removed the primary disk, put in the clone with beowulf installed, and > > > verified that all was still working. Then put the disk with chimaera in > > > another box
Re: [DNG] grub 2.04 and kernel 2.6
Hi Emanuel Thanks for that link. It's OK - I'm not hosting websites on my CentOS 6 box! There are a number of reasons why I've been terrified of trying to upgrade this box up to now - and the experience of the last fortnight has tended to confirm most of my existing fears and add a few more besides. I'm just glad that I decided to take a clone of the hard disk before starting the upgrade. If the grub guys have just arbitrarily decided not to support kernel v2, then it was probably a bit high-handed of them. Red Hat/CentOS/Scientific Linux/Oracle version 6 was the last version before systemd'struction, and I suspect that there may be quite a lot of boxes around still running it. On Sun, 2022-02-13 at 23:09 +0100, Emanuel Loos via Dng wrote: > Hello Peter, > > looks like someone else is experiencing the same issue (though there > where no answers yet): > > https://www.linuxquestions.org/questions/linux-kernel-70/gnu-grub-version-2-04-you-need-to-load-the-kernel-first-4175707760/ > > I don't see version 2 of the Linux kernel listed on https://kernel.org/ > so if you are hosting websites there how is this secure? If you want a > stable kernel, how about a longterm version? How about configuring and > compiling it yourself so it matches your needs best? > > By the way: They are GNU/Linux or GNU+Linux distributions, Devuan calls > itself a GNU+Linux distribution, Debbian calls itself a GNU/Linux > distribution. They are all based on the GNU operating system with the > Linux kernel. > > The GNU Project, developing an operating system that's completely free > software (as in freedom, not free beer), was the start of the free > software movement, long before Open Source existed, but it doesn't get > acknowledged that much since companies are okay with the idea of Open > Source (viewing releasing the source code as a good idea sometimes, > because it is more profitable), but really don't like the idea of free > software (viewing the freedom of computer users as a must and not > granting the four essential freedoms of free software when releasing > software as something unethical which does harm to society). > > Kind Regards > > Emanuel Loos > > On 2/13/22 10:05 PM, Peter Duffy wrote: > > I've got an old box running CentOS 6.2 and Windows 7. Without going into > > details, this box is vital and I use it every day. Finally I decided > > that I had to bite the bullet and upgrade the linux system, and I > > decided to go for chimaera. > > > > Built a new box from scratch and cloned all the disks, using dd, to > > fresh HDDs (there are several big data disks in the box). Made another > > clone of the first disk just for safety's sake, then installed chimaera > > on free space on the first disk - successful; chimaera and windows 7 > > both booted fine. But CentOS 6.2 wouldn't boot - sometimes automatic > > reboot, sometimes blank screen and hung box. > > > > Switched back to the latest clone disk, which fortunately booted > > successfully, made a fresh clone of the working disk, then tried again: > > this time, installed beowulf. Install was successful - and this time > > devuan, windows 7 and CentOS 6.2 all booted successfully. > > > > Took another safety clone of the first disk (I'm beginning to wonder if > > I've exhausted the world's stock of 2T HDDs) and then upgraded beowulf > > to chimaera. Upgrade successful. Again, the CentOS 6.2 system wouldn't > > boot. > > > > CentOS 6.2 uses kernel 2.6 - it's possible to upgrade to a later one, > > but this is frowned upon. I suppose it's based on RedHat and > > derivatives' policy of setting a base version per distro and then > > retrofitting updates. (I did once try upgrading to a v4 kernel, and the > > system became completely unstable.) > > > > Removed the primary disk, put in the clone with beowulf installed, and > > verified that all was still working. Then put the disk with chimaera in > > another box with identical hardware, and started digging into the > > problem. Grub on chimaera = 2.04-20; on beowulf = 2.02+dfsg1-20 > > +deb10u4. Booted into chimaera and downloaded the packages for the > > beowulf grub release (grub2, grub2-common, grub-common, grub-pc, and > > grub-pc-bin), and used them to downgrade grub on the chimaera system - > > successful. Rebooted - CentOS 6.2 now boots. Tried going into the grub > > command line environment on each box, and using the "linux" command to > > load the 2.6 kernel image: result was in grub 2.02, it works fine, and > > in 2.04, the box reboots at that point. > > > > So current conclusion is that something has happened between grub 2.02 > >
[DNG] grub 2.04 and kernel 2.6
I've got an old box running CentOS 6.2 and Windows 7. Without going into details, this box is vital and I use it every day. Finally I decided that I had to bite the bullet and upgrade the linux system, and I decided to go for chimaera. Built a new box from scratch and cloned all the disks, using dd, to fresh HDDs (there are several big data disks in the box). Made another clone of the first disk just for safety's sake, then installed chimaera on free space on the first disk - successful; chimaera and windows 7 both booted fine. But CentOS 6.2 wouldn't boot - sometimes automatic reboot, sometimes blank screen and hung box. Switched back to the latest clone disk, which fortunately booted successfully, made a fresh clone of the working disk, then tried again: this time, installed beowulf. Install was successful - and this time devuan, windows 7 and CentOS 6.2 all booted successfully. Took another safety clone of the first disk (I'm beginning to wonder if I've exhausted the world's stock of 2T HDDs) and then upgraded beowulf to chimaera. Upgrade successful. Again, the CentOS 6.2 system wouldn't boot. CentOS 6.2 uses kernel 2.6 - it's possible to upgrade to a later one, but this is frowned upon. I suppose it's based on RedHat and derivatives' policy of setting a base version per distro and then retrofitting updates. (I did once try upgrading to a v4 kernel, and the system became completely unstable.) Removed the primary disk, put in the clone with beowulf installed, and verified that all was still working. Then put the disk with chimaera in another box with identical hardware, and started digging into the problem. Grub on chimaera = 2.04-20; on beowulf = 2.02+dfsg1-20 +deb10u4. Booted into chimaera and downloaded the packages for the beowulf grub release (grub2, grub2-common, grub-common, grub-pc, and grub-pc-bin), and used them to downgrade grub on the chimaera system - successful. Rebooted - CentOS 6.2 now boots. Tried going into the grub command line environment on each box, and using the "linux" command to load the 2.6 kernel image: result was in grub 2.02, it works fine, and in 2.04, the box reboots at that point. So current conclusion is that something has happened between grub 2.02 and 2.04 which prevents the latter from loading linux v2 kernels. The challenge now is to find out what, and if it's possible to work around it in grub 2.04. (I should say that I originally assumed that the problem was down to moving a disk (or a clone of it) from a non-UEFI environment to a UEFI one - but setting everything in the firmware to "legacy only" didn't have any effect.) Just wondered if anyone had any thoughts and comments (other than why the hell am I still running CentOS 6.2 on this box), before I start rummaging through the grub changelogs. Apologies for the length of this and also if I've missed something obvious. The above is a heavily boiled-down summary of about a fortnight of stress and lost sleep. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Early Days at Bell Labs
Thanks for the link to that - brilliant talk. I've always thought that Brian Kernighan himself was the great communicator in the UNIX group - I wonder whether "The C Programming Language" and "The Unix Programming Environment" would have happened without his obvious ability to take abstruse and difficult material and make it accessible. If I had one incredibly tiny nit to pick, it would be that he didn't mention GNU (it appeared once in the slide showing Linus' original email). Without GNU, it's reasonable to suppose that linux wouldn't have happened. On Sun, 2022-01-16 at 04:12 -0500, Steve Litt wrote: > Hi all, > > This was discussed on the devuan-offtopic IRC channel, so I watched the > video: > > https://www.youtube.com/watch?v=ECCr_KFl41E > > It's Brian Kernighan discussing the formation of Unix, starting from > the back story of the creation of Bell Labs, including predecessors > CTSS and Multics, and C predecessors BCPL which was modified to become > B, and why Dennis Richie added types to B to make C. > > This video really hits its stride when Kernighan discusses piping and > redirection, and the ease of creating wonderful things out of small > parts that, and Kernighan used these words, "do one thing and do it > well." > > I felt like I was watching a fellow traveller who respected simplicity, > and creating powerful systems from simple tools. It was a much needed > reaffirmation for a guy who, when he's not with his Devuan buddies, > endures countless taunts for not using the pulseaudio-mandated Zoom, or > a Mac, or even Windows. They call me a tinkerer, even though my user > interface has changed not one bit in seven years (Openbox with dmenu > and UMENU2). Kind of ironic considering the changes their beloved Gnome > and KDE have put them through during that time. > > This video is such a breath of fresh air in a world worshipping Gates, > Jobs and Poettering. I suggest you watch it. I think it will bring a > smile to your face. > > SteveT > > Steve Litt > Spring 2021 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] Qt, KDE, unbelievable
That's a neat idea. Good luck with developing it - keep us posted on how it goes. Reminds me a bit of something that occurred to me a long time ago, when I was having to attend an endless stream of pointless, irrelevant, boring meetings. I wondered about virtual meetings: I'd program a "virtual meeting agent" to say what I had to say (if anything), and record what I needed to hear (if anything); at the set date/time, the agent then would "attend" the meeting with all the other agents (whilst I got on with something useful), and then come back and tell me about it. On Thu, 2022-01-20 at 10:36 -0300, Eike Lantzsch ZP6CGE via Dng wrote: > I am looking for a way to fake that I'm opening/reading the ads so the > magazine et all get paid but without having my screen actually littered > with ads and especially my ears not molested. That would be nifty. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
Obviously the higher up the management tree that one goes, the less the likelihood of finding someone who knows what systemd is, let alone appreciates that running a systemd-based distro on a server is a risk, if not actually a danger. In my own case - (a) I hate systemd for all the standard reasons - and more - and (b) I resent the requirement for learning a load of new commands, file syntax and administration procedures, when the new stuff offers no advantages whatsoever. I also (c) know from personal experience that systemd occasionally causes hangs in bootup and shutdown, and that's obviously disastrous if it affects a server with 300+ users. From the management point of view, (a) and (b) are irrelevant (although it might be expected that my 25+ years' experience should give them some weight); (c) ***should*** be relevant. The challenge is to find a way to convey the fact that it's relevant. On Wed, 2021-12-01 at 21:03 -0500, Steve Litt wrote: > Radisson via Dng said on Wed, 1 Dec 2021 21:55:13 +0100 > > >Am 19.11.21 um 12:29 schrieb Peter Duffy: > >> I've recently been asked to recommend an upgrade route for a number > >> of linux servers, and I proposed going to devuan. In response, I've > >> had a concern raised which took me by surprise. It was suggested > >> that in the future, it may not be possible to find staff who have > >> the skills to administer and manage servers running non-systemd or > >> pre-systemd distros/releases. > >> > > > > > >FUD, > > But it's the customer's FUD, so if the OP wants to get money for a > well-crafted project, he needs to address this issue. > > >i do unix since 25 year and if your sysadmin is not capable the manage > >a few scripts whats that ? > > From my point of view is systemd a still developing target, that no > > one > >really understands. > > If there's a PID1/supervisor that nobody really understands, that says > a lot of that PID/supervisor. I use runit, and I can explain it in > minute detail. That's the difference between runit and systemd. > > SteveT > > Steve Litt > Spring 2021 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] system administration of non-systemd distros and releases
Thanks for posting that. I confess that I'd not seen it before. It does indeed hit all the nails squarely on the heads. On Sat, 2021-11-27 at 15:39 -0600, goli...@devuan.org wrote: > On 2021-11-27 15:00, Mark Rousell wrote: > > On 25/11/2021 22:57, Steve Litt wrote: > >> Like I said in 2014, > >> they won't quit until the cat command requires systemd. > > > > They won't stop until SystemD is in the kernel, such that Linux > > unavoidably is SystemD. > > > > Just have to repost this prescient rant about systemd from 2014. My all > time fav! > > Open letter to the Linux World > From: Christopher Barry > Date: Tue Aug 12 2014 - 15:35:49 EST > > http://lkml.iu.edu//hypermail/linux/kernel/1408.1/02496.html > > golinux > ___ > 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] system administration of non-systemd distros and releases
nother init > system” then yes. But there are so many dependencies where devs of all > sorts of software have to make an either/or choice of whether to > support SystemD (which you can’t do if you want your package to run on > the majority of platforms) or support the “traditional” way, that it > would mean every package developer putting a lot of work in to deal > with the alternatives. E.g. simple logging of diagnostics etc would > mean having two lots of logging code to handle syslog or SystemD > logging. Agreed. One of the things which gives me the red mist about this is that there'll come a point - if it hasn't come already - where anyone developing or modifying a linux application will need to go cap-in-hand to the systemd equivalent of Barad-dûr and check that what they're doing will be compatible with the latest incarnation of systemd. And maybe that's being too paranoid. I once tried the experiment of setting up a sacrificial virtualbox VM, installing centos 7, and then forcing the removal of systemd, just to see what would happen. It was interesting. Over 500 dependent packages got removed; I then rebooted, and was dropped into a single-user shell (probably reasonable, as I'd removed the init system). To add insult to injury, both background and foreground were set to black, so that I couldn't even see what I was typing. I remember that the phrase "nuked back to the stone age" kept going through my mind. I noted the names of a few of the more surprising packages which had been removed as dependents, then reverted back to the pre-systemd-removal virtualbox snapshot (oh yes, I had taken one!). I then poked about inside the noted packages. One of the ones removed was ebtables - I found that the only thing which made it dependent on systemd was the existence of a systemd config file (kind of chicken-and-egg). The old init script was still there. I removed the systemd config file, fiddled about with the rpm configuration files and rebuilt the package: systemd dependency gone. I did think of continuing the experiment and writing something to work through all the auto-removed packages to find all the ones which fell into the same category and process them in the same way, but I got pulled off onto other things. I might take it up again at some point: the existence of a devuan analogue to an RPM-based distro like centos or scientific linux might put the cat among the pigeons. > On this, I am in agreement with Steve Litt - the SystemD project has > an incentive to maximise their intrusion into every aspect of system > operation. Because the harder they can make it for devs to make they > software run on SystemD or any other init system, the more they can > make other software depend on SystemD and thus make it harder to keep > SystemD optional in the wider view. > > So having had SystemD create such a gulf between the requirements to > run on “traditional” systems dn SystemD systems, effectively any shim > would have to recreate a heck of a lot of SystemD. And we all > know that such a shim would be trivial to write given the well > documented and stable interfaces between the SystemD components > I'm not convinced that writing an "init subsystem plugboard" would be impossible - although certainly non-trivial. But after all, it's just software. Anything's possible. During the days when the hurd was being actively developed, it must have seemed as though there would never be an open-source equivalent of unix. Then Linus Torvalds appeared on the horizon. Andrew Tridgell reverse-engineered a rather obscure network protocol and wrote a server for it - and then discovered that he'd implemented a linux-based version of SMB and opened up the door for linux access to windows file shares. We who know and appreciate the benefits of devuan can push it towards others - but convincing them and getting them to try it is another matter. But if there existed a package which interposed itself between systemd and the rest of the system, so that systemd could be trivially replaced with another init subsystem, it would open up vast scope for demonstrating that it was actually possible for linux to work without systemd. The stakes couldn't be higher, and there are obviously many other people who are thinking on these lines. Cometh the hour, cometh the programmer. Maybe? > > >> Peter Duffy said on Thu, 25 Nov 2021 13:51:18 + > >> > >>> I've said it before and I'll say it again. All this could have > been > >>> avoided - if systemd had been made optional from day 1. People who > >>> liked it could use it; people who didn't like it could use > something > >>> else. > > And in the Debian world, I distinctly recall there being an air of > “don’t worry, it’s optional anyway” alongside the “and it’s only > another init system” arguments. &g
Re: [DNG] system administration of non-systemd distros and releases
It's a bit like the charlatans and fake doctors in past centuries. They'd invent an illness, and then claim to have a remedy for it: https://en.wiktionary.org/wiki/marthambles On Thu, 2021-11-25 at 09:55 -0800, Syeed Ali wrote: > On Thu, 25 Nov 2021 10:35:13 -0500 > Steve Litt wrote: > > > I quote then-Redhat CTO Brian Stevens: "Red Hat's model works because > > of the complexity of the technology we work with." > > Create the problem, provide the solution. > ___ > 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] system administration of non-systemd distros and releases
The trouble is that it's not just an OS for geeks - it's the OS on which the vast majority of the internet runs. If the sysadmins who maintain the servers which form the infrastructure and backbone of the internet were to get de-skilled, that would be a very big problem. (Although, I should say that I personally can't for a moment imagine that that would happen.) On Thu, 2021-11-25 at 19:50 +0100, Didier Kryn wrote: > For myself, I prefer Linux to remain an OS for geeks rather than try > to catch the market of clueless users, but the last has been, for > decades, the quest of Gnome, and now of Freedesktop. Systemd fits well > in the plot. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Viewing file content (was Re: system administration of non-systemd distros and releases)
Personally, if I want to look at a file without editing it, if it's
small, I'll use view - which gives me the vi interface with the file in
read-only mode. It means I get the same interface and facilities that I
use when actually editing files, and it's easy to remember and (usually)
automatic. If I'm examining logs, I normally use less: handles big files
well, and (to coin a phrase) has more functionality than "more". It also
has the brilliant ctrl-f feature to show updates to the log in real-time
(like "tail -f" but with the advantage that the "tailing" mode can be
entered and exited without losing access to the file).
On Fri, 2021-11-26 at 18:40 +0900, Olaf Meeuwissen via Dng wrote:
> Hi,
>
> Steve Litt writes:
>
> > What could possibly be easier than vim /var/log/messages, or
> > vi /var/log/messages, or emacs /var/log/messages, or
> > nano /var/log/messages? And notice with the old way, you have a choice,
> > rather than having to look at log output with the vendor's proprietary
> > tool.
>
> Maybe I'm peculiar but I always find it absolutely, totally jaw-dropping
> when people use text *editors* to *look* at file content. Makes my toes
> curl up and blood curdle.
>
> Why on earth would you want to edit your system logs anyway?
>
> On De{bi,vu}an derivatives, I'd use `pager`. On any other Unix-based
> OS, I'd use `more` or `less`, preferably.
>
> # On my own machines `lv` makes a fine `pager` for me. On the fly
> # decompression and handling of many different encodings. So for me,
> # it's just
> #
> # pager /var/log/syslog.2.gz
> #
> # without any `zmore` or `zcat` piping. There is still no zpager :-/
> # but with `lv` I don't really need one.
>
> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
> GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
> Support Free Softwarehttps://my.fsf.org/donate
> Join the Free Software Foundation https://my.fsf.org/join
> ___
> 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] system administration of non-systemd distros and releases
So customers pay to be insulated from complexity. Just so obviously a blatant restating of the M$ attitude - which is the reason why there are so many clueless computer users the world over, and by extension, so much cybercrime. But if systemd makes it more difficult to solve problems, and makes the system more unreliable, then the customers aren't even getting what they paid for before systemd was introduced. The problem is obviously proving whether or not systemd really does make a system more unreliable/undiagnosable. The argument for/against is just so completely and rabidly polarised that getting any impartial evidence about any aspect of it is about as feasible as getting impartial evidence about the effects of brexit. I've wondered for a long time if it would be independently possible to make systemd optional. I had in mind a kind of virtual plugboard which would sit between the system and the init subsystem, and to some extent control interaction between the two (allowing "loopback switches" to both init system and applications, to pre-empt init system functionality which wasn't desired). It wouldn't be a permanent solution or even workaround - just a way of hopefully demonstrating the benefits of having systemd as optional rather than mandatory (if you want to tame or study something, first get it into a cage). I did mention it on here a while ago, but after the horrified responses, I didn't pursue it. However, it was interesting to see that, according to distrowatch, MX Linux is currently the most popular distro, and it offers systemd as an option. Apparently they use systemd-shim to facilitate this. This is probably (hopefully?) a bit out-of-date now, but some of the comments are still interesting: https://mxlinux.org/blog/so-we-could-use-a-little-help-with-systemd-shim/ On Thu, 2021-11-25 at 10:35 -0500, Steve Litt wrote: > Peter Duffy said on Thu, 25 Nov 2021 13:51:18 + > > >I've said it before and I'll say it again. All this could have been > >avoided - if systemd had been made optional from day 1. People who > >liked it could use it; people who didn't like it could use something > >else. Email traffic to the systemd developers would tend to consist of > >genuine problem reports and requests for enhancement, rather than hate > >mail. So there would have been no need for the systemd team to > >barricade themselves behind a wall of silence and arrogance. And > >systemd itself would gradually improve. Massive win-win in every > >conceivable way. The scary thing is that LP and co. must see that as > >clearly as anyone else. > > The following is my opinion. I didn't sit on the Redhat board of > directors, but neither did anyone on this list or the Debian-Users > list, as far as I know. > > Redhat wasn't looking for a win-win. They were looking for a > win-it-all, and that meant that traditional Linux, and all its > adherents, lost. When systemd was starting to be foist on the world, > Redhat was a vendor of support and training. You can't make very much > on support and training for an easy technology. Only by complexifying > Linux could they grow their business. > > Now I'll show you the smoking gun, which actually happened several > years before systemd. Click the following link and search for the word > "complexity" in the following URL: > > http://asay.blogspot.com/2006/10/interview-with-red-hat-cto-brian.html > > I quote then-Redhat CTO Brian Stevens: "Red Hat's model works because > of the complexity of the technology we work with." > > Systemd fanboiz are quick to point out this statement had nothing to do > with systemd because it was uttered at least 3 years before systemd > development began. From my viewpoint, whether it was about systemd or > not doesn't matter. As they say in the courtroom, his statement "goes > to motive". Redhat's model works only in the face of complexity. > > So Redhat finds PoetterPinhead with his gigantically complexified and > dismodular "init system" so rickety it needs constant fixes, hires him > and about 6 others to keep the albatross running, and sics it on Linux > in order to complexify Linux so there's more demand for Redhat's > consulting and training. > > Meanwhile, view any video with PoetterPinhead. He thrives on conflict. > With his albatross welded into Linux, he gets a chance to argue to his > heart's content. He gets paid to travel the world putting people down. > He's in heaven. > > So although what you write about the fact that making it optional would > have lessened the drama and conflict is correct, that was never going > to happen, because lessening drama and conflict was never the goal. > > SteveT > > Steve Litt > Spring 2021 featured book
Re: [DNG] system administration of non-systemd distros and releases
tup when running such a distro/release. The most recent occurrence of this was when I took on the management of a server which was malfunctioning occasionally. I found that at some point - probably accidentally - it had been upgraded to Ubuntu 15, the first fully-systemd release. Also, it was running mysql, and the mysql root directory had been moved to a non-default location. One problem was that mysql would not shut down properly - often, the mysqld process had to be killed manually. One day, the power to the server got interrupted, and it wouldn't come up again. I managed to boot it from a rescue CD, and spent several hours trying to discover what had gone wrong - without success. The systemd "tools" drove me insane - it felt as though they were actively preventing me from accessing the information I needed. Eventually, I tried a hunch: maybe the default credentials required by mysqladmin might not have been copied across when the mysql database directory was moved (one of the nastiest gotchas in running mysql under debian and derivatives). This proved to be the case, and when I'd fixed it, the system came up happily, and a reboot also worked. (As soon as possible, I rolled it back to Ubuntu 14.) The problems were: (a) I'd not been able to find any explicit information about the issue. Obviously, my unfamiliarity with the systemd tools probably didn't help - but it seemed that journalctl was only showing a sanitized and censored version of the available information; (b) systemd would apparently not proceed without confirmation that mysql was up and running. I've had similar mysql-related problems happen on non-systemd systems - but they always came up in spite of the mysql startup problem, and the source of the problem was obvious from the (text-based) logs. In this case, at least I had physical access to the server, and could press the power button and stick a rescue CD into the drive. The thought of the same kind of problem happening on a box in an unattended server farm, or on a VM in a cloud-based hosting environment, with no or limited virtual console access - and of course it would happen in the middle of the night ... Well, it just doesn't bear thinking about! I've said it before and I'll say it again. All this could have been avoided - if systemd had been made optional from day 1. People who liked it could use it; people who didn't like it could use something else. Email traffic to the systemd developers would tend to consist of genuine problem reports and requests for enhancement, rather than hate mail. So there would have been no need for the systemd team to barricade themselves behind a wall of silence and arrogance. And systemd itself would gradually improve. Massive win-win in every conceivable way. The scary thing is that LP and co. must see that as clearly as anyone else. On Fri, 2021-11-19 at 11:29 +, Peter Duffy wrote: > I've recently been asked to recommend an upgrade route for a number of > linux servers, and I proposed going to devuan. In response, I've had a > concern raised which took me by surprise. It was suggested that in the > future, it may not be possible to find staff who have the skills to > administer and manage servers running non-systemd or pre-systemd > distros/releases. > > I've tried to give reassurance - but I'm still wondering if this could > be a valid concern. I'd always taken the view that it's primarily the > linux sysadmin community which is trying to stop the onslaught of the > systemd juggernaut - but obviously, the greater the proportion of > servers running systemd-based distros/releases, the less staff get > exposed to non-systemd management techniques and tools. > > I'd be grateful for thoughts and comments. > > ___ > 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
[DNG] system administration of non-systemd distros and releases
I've recently been asked to recommend an upgrade route for a number of linux servers, and I proposed going to devuan. In response, I've had a concern raised which took me by surprise. It was suggested that in the future, it may not be possible to find staff who have the skills to administer and manage servers running non-systemd or pre-systemd distros/releases. I've tried to give reassurance - but I'm still wondering if this could be a valid concern. I'd always taken the view that it's primarily the linux sysadmin community which is trying to stop the onslaught of the systemd juggernaut - but obviously, the greater the proportion of servers running systemd-based distros/releases, the less staff get exposed to non-systemd management techniques and tools. I'd be grateful for thoughts and comments. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan in the news today
Good article - one of the best and most even-handed summaries of the systemd position that I've read. One issue is that he oversimplifies the position re. gnome: he doesn't make it clear that it's gnome 3 which has co-dependencies with systemd, and that some of the desktop environments that he mentions are based on gnome 2 On Thu, 2021-02-25 at 00:12 -0300, Roberto Scattini via Dng wrote: > > > On Wed, Feb 24, 2021 at 10:29 PM Nelson H. F. Beebe via Dng > wrote: > > Some of you may wish to look at this story on Google News > today: > > The Best Linux Distributions Without systemd > > > https://www.howtogeek.com/713847/the-best-linux-distributions-without-systemd/ > > Devuan gets a whole section of the article, which notes > > >> ... > >> Devuan was forked from Debian in 2014. It’s solid and > stable and has a > >> thriving community. > >> ... > > > showed up in my feed, indeed. > excellent news! > > > > -- > Roberto Scattini > > ___ > 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] ..devuan to the rescue? Easiest possible newbie email server setup, ideas?
On Thu, 2020-10-01 at 11:31 +0200, Alessandro Vesely via Dng wrote: > On Tue 29/Sep/2020 11:10:12 +0200 Simon Hobson wrote: > > Alessandro Vesely via Dng wrote: > > > >>> I have no choice over the neighbours ! > > > >> Don't buy overly cheap connections... > > > > Doesn't matter how much you pay - unless you get an entire net-block to > > yourself then you have no control over the neighbours. Only the ISP has > > control over the neighbours. > > > Correct. ISPs which maintain a restricted set of non-spamming customers tend > to ask for higher rates. Mass discount ISPs, cutting abuse team costs, > accept > anyone. Tell me about it! My provided mail router has been blacklisted several times because of neighbours' spamming activities. I keep wondering about going for a more exclusive package (in all senses) but it would be a big increase in the yearly fee. Oh for the days when I was a Demon Internet customer and had my very own class C address ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Is t worth the effort for SPF?, DMARC>, DKIM?, etc
Thank you for that note on SPF - it clarified it for me in a way that other documentation on this has failed to do up to now. On Thu, 2020-10-01 at 00:07 -0700, Rick Moen wrote: > Quoting terryc (ter...@woa.com.au): > > > On Sun, 27 Sep 2020 17:20:06 +0200 > > Alessandro Vesely via Dng wrote: > > > > > > > You can also publish DKIM and SPF records so as to produce > > > DMARC-aligned authentication for any hosted domain. Users won't > > > notice any difference. > > > > Does anyone have any figures on how effective these methods are? > > It seems we get a new idea every few years and none make the slightest > ^^^ > > difference in spam levels. > ^ > > You have made a fundamental, basic error. > > SPF and DMARC are _antiforgery_ extensions to DNS and SMTP. They permit > a domain owner to publish information in their authoritative DNS to > advise recipients of SMTP about what SMTP-originating IP addresses ought > to be considered _authorised_ SMTP senders for their domains, vs. which > others ought to be rejected as forgeries. > > Nothing about SPF and DMARC say 'this will reduce spam'. They're about > making domain forgery (in received SMTP mail) be detectable and able to > be confidently rejected upon receipt. > > DKIM is a (poorly designed, IMO) method for individual SMTP-mail > originating system to cryptographically sign outbound SMTP mail, > permitting receiving systems to verify that the mail contents hasn't > been tampered with en-route. > > Since I personally refuse to have anything to do with DKIM or DMARC > (both designed by the same team at Yahoo), I'll illustrate SPF's > value proposition to a domain owner. I'm the owner/operator of domain > linuxmafia.com (among others). Here is that domain's publicly > proclaimed SPF record: > > :r! dig -t txt linuxmafia.com +short > "v=spf1 ip4:96.95.217.99 -all" > > That record says, translated into English, "Please accept as from an > authorised SMTP source for domain linuxmafia.com _only_ mail originated > by IPv4 address 96.95.217.99. Please hardfail (reject) mail received > from any other IP address." > > My putting that information in my DNS is a huge win for my domain's good > reputation as a clean SMTP source, in that it states extremely clearly > what mail _purporting_ to be from linuxmafia.com ought to be considered > by receiving MTAs (that honour my wishes) to be genuine. Of course, I > have zero ability to compel or persuade receiving SMTP systems to check > and honour my domain's SPF record, but many do, and every little bit > helps. > > Occasionally, someone tries to convince me that SPF is A Bad Thing for > any of several uncompelling reasons, most often because they have been > accustomed to originating mail from _their_ domains from arbitrary IP > addresses on TCP port 25 (SMTP), and fear that widespread adoption of > SPF will somehow make it less likely that their carefree habit will > continue much longer. My response inevitably is that I really couldn't > care less whether they like SPF or not. It permits me to unambiguously > declare to the public that IP address 96.95.217.99 is the only valid > source of SMTP mail from my domain, thereby exposing as forgeries mail > from anywhere else (falsely) claiming to be from my domain, so it is > A Good Thing for my domain, and I don't give a tinker's damn whether my > interlocutor approves of it. > > And none of this has anything particularly to do with 'reducing spam'. > That just isn't the point, and the only people debating that supposed > issue are folks who never bothered to look up what the thing _is_. > > > > > The only result is that there is now an industry of religious extremism > > in "blacklisting" sites that don't follow their desired implementation. > > To be blunt: You have not bothered to understand what you're writing > about. I would suggest you do so. > > ___ > 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] removing systemd from rpm-based distro
On Fri, 2020-09-25 at 13:31 +0200, Tito via Dng wrote: > > Il 25/09/20 13:03, Peter Duffy ha scritto: > > Apologies - this is probably off-topic, or at least veering off in that > > direction. Also apologies if this has been addressed previously and I've > > missed it - if so, I'd appreciate it if someone would point me at the > > discussion. > > > > Given the successful removal of systemd from debian, and the consequent > > existence of devuan - it seemed to me that the obvious next step would > > be to take an RPM-based distro (maybe centos) and attempt to apply > > equivalent procedures to it. > > > > But - at least based on extensive google searches - I can't find any > > evidence that this has even been considered, let alone tried. > > > > If it had been tried and found to be impossible, impractical or > > pointless, and if this had been reported, that would seem reasonable. > > But the lack of any mention or discussion of it whatsoever seems > > strange. > > > > Hi, > you can try PCLinuxOS which is rpm based and systemd free. > > https://www.pclinuxos.com/ > > Ciao, > Tito > Thanks for the heads up on that - I'll give it a try and report back. Strange that, apparently, it uses the apt package manager but rpm packages. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] removing systemd from rpm-based distro
Apologies - this is probably off-topic, or at least veering off in that direction. Also apologies if this has been addressed previously and I've missed it - if so, I'd appreciate it if someone would point me at the discussion. Given the successful removal of systemd from debian, and the consequent existence of devuan - it seemed to me that the obvious next step would be to take an RPM-based distro (maybe centos) and attempt to apply equivalent procedures to it. But - at least based on extensive google searches - I can't find any evidence that this has even been considered, let alone tried. If it had been tried and found to be impossible, impractical or pointless, and if this had been reported, that would seem reasonable. But the lack of any mention or discussion of it whatsoever seems strange. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
On Mon, 2020-09-21 at 18:07 -0700, Rick Moen wrote: > Quoting marc (marc...@welz.org.za): > > > Hmm - that might require some background: I'd venture that most of > > these scripts were written when sh was just a symlink to bash, and > > dash didn't exist, nevermind as a debian package. > > But that was always a blunder. The shebang should have been set to bash > explicitly, if bash-specific features are used: In the cases of which > you spoke, the coder made a lazy and unsupportable assumption. With respect, I'd tend to disagree with that to some extent. The /bin/sh symlink is built in, and is there from the point that the system is installed. So it's a feature made available to users, and it's arguably not a blunder to use it. Whether it's a good feature or not is definitely a moot point. The convention in linux (think since it originated) was that /bin/sh pointed to bash - until Debian decided to do it differently. I'd agree that best practice is specifying bash explicitly in the shebang, if it's required (something that I personally have always done since I first bitten by the bash/dash problem). I'm trying to remember what happens on systems that default to ksh and csh - I assume that on those, the shebang always needs to specify the shell to be used. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
On Tue, 2020-09-22 at 02:20 +0200, marc wrote: > > One thing about this which strikes me as a bit ironic is debian's use of > > the dash shell, made to be POSIX-compliant, and so causing endless > > problems for scripts using bash's additional non-POSIX functionality, > > but not specifying bash explicitly in the shebang line. > > Hmm - that might require some background: I'd venture that > most of these scripts were written when sh was just a symlink > to bash, and dash didn't exist, nevermind as a debian > package. > > The word decree is too strong, but at some point debian > system scripts were supposed to be written to be /bin/dash > compatible, but instead of changing all existing system scripts > to start with /bin/bash, and only replacing them > with /bin/sh once full checked/rewritten, they were kept > at /bin/sh as people hoped for the best - a quick win. > > I, for one, never bought into the reasoning for migrating > system scripts away from bash to sh. The argument that > bash is too large struck me as odd - there were critical > dependencies on perl and python with a much larger dependency > graph, and much bigger startup costs... > > More importantly I think it is good that one uses the same language > that one types into the terminal every day when extending the > distribution - that makes a sysadmin equal to the distribution maintainer, > instead of specialising that into a different caste... > > regards > > marc I was bitten by this when the company which I worked for (about 8 years ago) decided to move their development environment from Red Hat to Ubuntu - it turned out that the two were so incompatible that we ended up having to provide each user with separate Red Hat and Ubuntu PCs. But we still had to make the development system work under both environments. Most of the development process was driven by a big suite of shellscripts. The first we knew that there was a problem was when the builds under Ubuntu failed with no indication of why. It turned out that they used bash features - the one which really hit us was the use of "==" in test expressions (illegal in dash). For some reason (can't remember why), we couldn't change the shebang, so had to work through all the scripts and find workarounds for the bash features. It wasn't a nice task. My main feeling was one of frustration: bash's new features were introduced as an improvement, not as a deliberate violation of standards. Ubuntu/Debian's defaulting to dash just seemed like an act of puritanism. The situation became even worse when it was decided to revert to using bash as the default interactive shell, but keep /bin/sh pointing to dash. So an admin script would be written, and work fine (in bash) - and then be set up as a cron task, whereupon it would fail (because it was now running under dash). OK, the fix was easy - just specify the exact shell in the shebang - but remembering to do that took some effort for a while. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
Thinking that over, I wasn't sure if the appositeness of "straitjacket" to systemd was obvious - if it was, apologies. What I meant was something which was originally devised to protect someone from harming themselves or others, but which became a symbol of unnecessary and cruel restriction of personal liberty. Also, the "One flew over the cuckoo's nest" sense of the sane being locked up in an asylum run by lunatics. On Mon, 2020-09-21 at 13:34 +0100, Peter Duffy wrote: > Band-aid or straitjacket? (Latter probably appropriate in all senses of > the word ;) ) > > On Sun, 2020-09-13 at 21:22 -0700, Bruce Perens via Dng wrote: > > The problem for me is that I would rather work on new stuff. Systemd > > and so on are symptoms of the Unix design not really being a good fit > > for modern demands. That doesn't mean that you band-aid them with > > systemd, it's time for a different architecture. It is also time for > > what comes after Open Source, as I have talked about > > here: https://www.youtube.com/watch?v=vTsc1m78BUk > > It's not clear how much of this I will personally get to work upon. > > > > > > Thanks > > > > > > Bruce > > > > On Sun, Sep 13, 2020 at 9:08 PM terryc wrote: > > > > On Sun, 13 Sep 2020 11:13:02 -0500 > > goli...@devuan.org wrote: > > > > > > > A link to this rant was posted on FDN yesterday. I had never > > heard of > > > Luke Smith before and was not particularly impressed with > > either his > > > presentational style or his bemoaning the death of white, > > male > > > privilege but . . . I could very well imagine Linux going > > down the > > > path his "nightmare" imagines. > > > > > > > > > > https://libre.video/videos/watch/b576019d-8957-4efb-8571-6a14e0889136 > > > > entry for the worst video ever made? > > Thank for watching it and summarising it. > > > > > > If Debian doesn't wake up and reverse course what will > > become of > > > Devuan? The entire Linux ecosystem as we have known it could > > become a > > > nostalgic footnote in the history of the digital age. > > > > > > It's a good time to be old . . . > > > > Feels that way. > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > > > > > > -- > > Bruce Perens - CEO at stealth startup. I'll tell you what it is > > eventually :-) > > ___ > > 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
One thing about this which strikes me as a bit ironic is debian's use of the dash shell, made to be POSIX-compliant, and so causing endless problems for scripts using bash's additional non-POSIX functionality, but not specifying bash explicitly in the shebang line. On Sat, 2020-09-12 at 16:28 -0400, Steve Litt wrote: > Hi all, > > I think Devuan might want to "put back" POSIX commands Debian has > removed (but provides packages for). See the following thread from > Debian-User: > > https://lists.debian.org/debian-user/2020/09/msg00334.html > > Lennart Poettering has repeatedly and with certainty let us know he has > no use for POSIX. I guess now the Debian project is acting as his proxy > in this matter. > > Did you notice the one guy who said it would be "it would be 'rude' to > impose something wanted by only a part of the users"? > > Personally, if my operating system doesn't come, as a baseline, with > vi, ed, cut, grep, sed, awk, bc, dc, diff, dd, df, du, fg, head, tail, > and the like, then it isn't an OS I'd want to use. The fact that an OS > isn't certified POSIX is no excuse for deliberately leaving out easily > included POSIX programs and features. > > Is it possible for Devuan to "put back" what Debian sabotaged? > > Thanks, > > SteveT > > Steve Litt > Autumn 2020 featured book: Thriving in Tough Times > http://www.troubleshooters.com/thrive > ___ > 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] Danger: Debian POSIX hostility
Band-aid or straitjacket? (Latter probably appropriate in all senses of the word ;) ) On Sun, 2020-09-13 at 21:22 -0700, Bruce Perens via Dng wrote: > The problem for me is that I would rather work on new stuff. Systemd > and so on are symptoms of the Unix design not really being a good fit > for modern demands. That doesn't mean that you band-aid them with > systemd, it's time for a different architecture. It is also time for > what comes after Open Source, as I have talked about > here: https://www.youtube.com/watch?v=vTsc1m78BUk > It's not clear how much of this I will personally get to work upon. > > > Thanks > > > Bruce > > On Sun, Sep 13, 2020 at 9:08 PM terryc wrote: > > On Sun, 13 Sep 2020 11:13:02 -0500 > goli...@devuan.org wrote: > > > > A link to this rant was posted on FDN yesterday. I had never > heard of > > Luke Smith before and was not particularly impressed with > either his > > presentational style or his bemoaning the death of white, > male > > privilege but . . . I could very well imagine Linux going > down the > > path his "nightmare" imagines. > > > > > https://libre.video/videos/watch/b576019d-8957-4efb-8571-6a14e0889136 > > entry for the worst video ever made? > Thank for watching it and summarising it. > > > > If Debian doesn't wake up and reverse course what will > become of > > Devuan? The entire Linux ecosystem as we have known it could > become a > > nostalgic footnote in the history of the digital age. > > > > It's a good time to be old . . . > > Feels that way. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > > -- > Bruce Perens - CEO at stealth startup. I'll tell you what it is > eventually :-) > ___ > 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] Mixing different init benefits: was: without-systemd.org not working
(Apologies for restating that - I thought that my original mention of it hadn't made the list for some reason. I now see that it did.) On Fri, 2020-05-22 at 10:19 +0100, Peter Duffy wrote: > (There's a brilliant moment in "The Taking of Pelham 123" ... ___ 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
I know about uselessd - I suspect that it was reading about it that planted the seed for the "init-wrapper" idea - that of limiting systemd's power without systemd even being aware that it was being limited. I've not got far in thinking this through in terms of details - I assumed that it would be impossible to implement in a practical sense, and anyway the idea was just too crazy to be taken seriously. If I did contemplate doing it, first thoughts would be on the lines of modified libraries which would pre-empt existing ones. I agree that the value of this would increase substantially if the abstraction/glue layer was viewed as a general init system monitoring/controlling/auditing facility - it did occur to me that it would be a way of distilling out the best of all the init systems to which it was exposed. Just supposing that this led anywhere, I certainly wouldn't propose proactively keeping the systemd team updated re. progress. Obviously, given that it would presumably be an open-source project, they'll find out anyway - but if they can't see the obvious win-win from making systemd optional, they're not going to see the benefits of a project which could conceivably control and limit systemd's power and influence (both in terms of individual systems and the linux community as a whole). Thinking about systemd, and choosing whether to do what it asked and what to report back, the image which kept coming to mind (can't imagine why ;) ) was that of a convicted gangster controlling the mob from a prison cell - but he or she is completely at the mercy of feedback received, and has no way of knowing what is actually taking place. (There's a brilliant moment in "The Taking of Pelham 123". They're trying to get the money to the subway station before any more hostages get shot, and aren't going to make the deadline. Garber, the train dispatcher, suddenly realises that the crooks can't know what's happening on the surface, and tells them that the money's arrived before it actually does.) On Thu, 2020-05-21 at 14:09 -0400, Steve Litt wrote: > On Thu, 21 May 2020 10:59:15 +0100 > Peter Duffy wrote: > > > I think that the thing that I found tantalising was the idea of > > sniffing what systemd tried to do, and then deciding whether or not > > to do it, > > Many have tried this. Web search "uselessd". > > But your suggestion becomes much more valuable if expressed as > "sniffing what each init system tried to do, and then deciding whether > or not to do it". > > * Busybox init > * Epoch > * OpenRC > * Runit > * s6 (plus s6-rc) > * Suckess init plus [daemontools | runit | s6] > * systemd > * sysvinit > > > and what responses to send back to systemd. > > If you mean the daemon reports back to the process supervisor success > or failure, s6 has that now, in a much simpler form than systemd's > dbus-centered bizarro. And such reporting isn't all that necessary > because the admin can roll his own tests. > > If you mean do this research and report the research results back to > the systemd project, I'm not interested in helping systemd, and systemd > isn't interested in anything making them more interoperative. > > 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] without-systemd.org not working
If LP doesn't see the obvious benefit of making systemd optional, I
can't see that he'd go to the trouble of creating a plug-and-play setup
to allow alternatives to systemd to get in on the act. (Would a dictator
suggest the tryout of other political systems, to see how they stacked
up against autocracy?)
I think that the thing that I found tantalising was the idea of sniffing
what systemd tried to do, and then deciding whether or not to do it, and
what responses to send back to systemd. I had a mental image of a
convicted gangster directing the mob from his or her prison cell -
he/she can give out the instructions, but is entirely dependent on what
feedback is relayed from outside the jail. ("The Taking of Pelham 123" -
they're trying to get the money to the subway station before any more
hostages get shot, and aren't going to make it. In a flash of
inspiration, Garber, the train dispatcher, realises that the crooks have
no way of knowing what's happening on the surface, so tells them the
money's arrived before it actually does).
One possible real benefit of a glue/abstraction/jail layer did occur to
me. Eventually, it would itself become an init system, with a
distillation of (hopefully) the best bits of all the init systems which
had used it.
I totally agree re. PID1 and the need for simplicity. Maybe I should
just get out more (eventually, anyway ;) )
On Wed, 2020-05-20 at 18:45 -0400, Steve Litt wrote:
> On Tue, 19 May 2020 10:29:02 +0100
> Peter Duffy wrote:
>
> > Apologies for following up on my own post - just an afterthought.
> >
> > When I originally encountered systemd, the word was that it was so
> > pervasive that it couldn't be removed (obviously, now we know
> > different ;) )
> >
> > Given the alleged non-optionality of systemd, I started to wonder
> > about some kind of an init system wrapper (or even jail) - an
> > abstraction layer which would sit between the init subsystem and the
> > main system, and sanitise and homogenise interactions between the
> > two; init systems, including systemd, could be plugged and unplugged
> > into the top surface as desired; the abstraction layer would manage
> > commands and responses (including lying to the init subsystem if the
> > latter tried to do something dangerous or antisocial).
>
> Oh please don't suggest this: Poettering might do it.
>
> The job of an init system (not systemd, that's a software analogy of
> those old electronic circuits encased in epoxy so nobody could reverse
> engineer them) is to:
>
> 1) Run as PID1, listening for certain
>
> 2) PID1 forks off early boot stuff to mount, unencrypt, construct
> devices, set up the network, and the like.
>
> 3) PID1 forks off a daemon handler. The best daemon handlers are, in my
> opinion, djb style process supervisors like daemontools, runit and
> s6.
>
> 4) Upon receipt of a certain signal, PID1 forks or execs the shutdown
> script.
>
> It really is just that simple. There's no need to add anything to
> accommodate badly behaved init system authors.
>
> 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] without-systemd.org not working
Apologies for following up on my own post - just an afterthought. When I originally encountered systemd, the word was that it was so pervasive that it couldn't be removed (obviously, now we know different ;) ) Given the alleged non-optionality of systemd, I started to wonder about some kind of an init system wrapper (or even jail) - an abstraction layer which would sit between the init subsystem and the main system, and sanitise and homogenise interactions between the two; init systems, including systemd, could be plugged and unplugged into the top surface as desired; the abstraction layer would manage commands and responses (including lying to the init subsystem if the latter tried to do something dangerous or antisocial). I know - first reaction is to recoil in horror and disgust at the very thought (adding another layer of complexity to something which is already overcomplex). But there's something tantalising about it. On Mon, 2020-05-18 at 12:04 +0100, Peter Duffy wrote: > One of the things which always baffles me about systemd was that right > from the word go, there was something which would have nipped in the bud > all the controversy, pain, recriminations, etc. etc. Make systemd > optional (so that, for example, it could be selected at install time > from a range of available init systems, and later, if desired, removed > and reinstalled). > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] without-systemd.org not working
Thanks for the heads up on that - fascinating article. One of the things which always baffles me about systemd was that right from the word go, there was something which would have nipped in the bud all the controversy, pain, recriminations, etc. etc. Make systemd optional (so that, for example, it could be selected at install time from a range of available init systems, and later, if desired, removed and reinstalled). That way, people who liked it could use it, and people who didn't like it could use something else. Win-win situation: users could use the init system which they wanted to use; and systemd developers wouldn't have to spend all their time fending off howls of protest and hatred, and could concentrate on making systemd better (and if they introduced something that reduced the overall systemd usage, then they'd know (hopefully) that it wasn't a good idea). It's so obvious and self-evident that it must be concluded that there are other factors and agendas at work. Which conclusion is deeply depressing. On Fri, 2020-05-15 at 14:44 -1000, Joel Roth via Dng wrote: > On Fri, May 15, 2020 at 12:09:46PM -0700, spiralofhope wrote: > Reminds me to revisit https://ewontfix.com/14/ > for Felker's Broken by Design article on systemd. > > None of the other init systems could compete > sysvinit due to the latter's huge installed > base. Except when marketing came along... > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] waagent again
It's been pointed out to me that when I posted about my work on the waagent package, I accidentally gatecrashed another thread. Apologies for that - I'll try to do better in future ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] waagent
(Apologies if I've posted this to the wrong list - shall I repost it to the devuan-dev list?) On Wed, 2020-04-29 at 15:21 +0100, Peter Duffy wrote: > I'm currently setting up a virtualbox image based on Devuan ASCII, for > eventual upload to azure as a base image for creating VMs. > > I've hit some problems with the waagent package in the Devuan > repositories - basically they boil down to: > > 1) the python function platform.linux_distribution() returns "debian" > instead of "devuan" > > 2) waagent loads an instance of the class osutil which contain a set of > method overrides specific to a particular distro/release. However, it > doesn't have one for Devuan, so this, combined with (1) causes it to > load an osutil instance for debian, and this means that it expects > systemd functionality to be present. > > I've fixed (2) on my local sandbox (created an osutil instance for > Devuan) and I'm preparing to do a fork/pull from github to get the > changes reviewed and hopefully integrated. > > (1) is a bit of a problem. I can work around it by defining a > file /etc/lsb-release, which is seen and used by > platform.linux_distribution() - but I'm worried about making a > system-wide change to fix an application-specific problem: it could > break other things which rely on the python function returning "debian". > So I'm going to try to identify Devuan directly from within waagent, > rather than relying on python. > > Any thoughts re. python identifying Devuan as "debian" would be welcome > - should this be flagged up as a bug, or is it necessary? > > > ___ > 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
[DNG] waagent
I'm currently setting up a virtualbox image based on Devuan ASCII, for eventual upload to azure as a base image for creating VMs. I've hit some problems with the waagent package in the Devuan repositories - basically they boil down to: 1) the python function platform.linux_distribution() returns "debian" instead of "devuan" 2) waagent loads an instance of the class osutil which contain a set of method overrides specific to a particular distro/release. However, it doesn't have one for Devuan, so this, combined with (1) causes it to load an osutil instance for debian, and this means that it expects systemd functionality to be present. I've fixed (2) on my local sandbox (created an osutil instance for Devuan) and I'm preparing to do a fork/pull from github to get the changes reviewed and hopefully integrated. (1) is a bit of a problem. I can work around it by defining a file /etc/lsb-release, which is seen and used by platform.linux_distribution() - but I'm worried about making a system-wide change to fix an application-specific problem: it could break other things which rely on the python function returning "debian". So I'm going to try to identify Devuan directly from within waagent, rather than relying on python. Any thoughts re. python identifying Devuan as "debian" would be welcome - should this be flagged up as a bug, or is it necessary? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What an Ad hominem!
I agree. For me, the thing which has always put me off above all other things was the fact that systems running systemd often did not shut down cleanly. Manageable if it's a laptop on your desk and you have access to the on/off button and the power cord. Not so good if the box is a business-critical server, housed in an unattended bunker 200 miles away, and it's 03:00 in the morning. The risk's just too great. Are there any stats for the takeup of Devuan (and/or the persistence of old pre-systemd releases of other distros) in the server community? I have been unable to find them. Would be very interesting. On Sun, 2020-04-19 at 11:31 +0200, Edward Bartolo via Dng wrote: > Hi, > > SystemD detractors may, like myself, be repelled from using it because > everytime they installed a systemd based distribution, it always > greeted them with a system-wide freeze. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
