[DNG] Announcing Devuan 4.0: Chimaera!
Dear Friends and Software Freedom Lovers, Devuan Developers are pleased to announce the release of Devuan Chimaera 4.0 as the project's newest stable release. This is the result of lots of painstaking work by the team and extensive testing by the wider Devuan community. --- What's new in Chimaera 4.0? * Based on Debian Bullseye (11.1) with Linux kernel 5.10. * Your choice of init: sysvinit, runit, and OpenRC. * Improved desktop support - virtually all desktop environments available in Debian are now part of Devuan, systemd-free. * New boot, display manager and desktop theming. * Enhanced accessibility: installation via GUI or console can now be accomplished via software or hardware speech synthesis, or using a refreshable braille display, and Devuan Chimaera has the ability to install desktop environments without PulseAudio, allowing speech synthesis in both console and GUI sessions at the same time. --- Installation and Documentation Whether you are upgrading an existing Devuan install, migrating from Debian or installing from scratch, instructions and guidance can be found online: https://devuan.org/os/install https://devuan.org/get-devuan. Packages, netboot images and installation media are available through a resilient network of http package mirrors, http, https, ftp and rsync iso mirrors, torrent and magnet. Please take time to read the Release Notes. They include important configuration information and tips to help your install or upgrade go as smoothly as possible. https://files.devuan.org/devuan_chimaera/Release_notes.txt For the impatient, you can go straight to the package and sources.list information or the installation media downloads: https://devuan.org/os/packages http://files.devuan.org/devuan_chimaera/ --- Resources and Support * Mailing list: https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng * IRC: #devuan #devuan-dev (Libera) * Forum: https://dev1galaxy.org * Press contact: free...@devuan.org * Source code: https://git.devuan.org * Bug tracker: https://bugs.devuan.org * Package information: https://pkginfo.devuan.org * Popularity contest: https://popcon.devuan.org --- After Chimaera The next Devuan release, 5.0, is codenamed Daedalus. Repositories are already available for the adventurous to test. --- Appreciation We wish to thank all of you for the incredible support given to Devuan. Without your help and feedback, Devuan could not be the reliable and versatile distribution that it is. To support the Devuan project you can examine our financial reports and donate at: https://devuan.org/donate --- Live long and prosper! The Devuan Development Team --- signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] random sudden stops
On Wed, Aug 25, 2021 at 08:10:55PM -0400, Hendrik Boom wrote: > For the past few months my home server (running an ascii installation > physically moved from another computer) has been suddenly stopping all > processing about once a month. Quite seriously, check it for excessive dust. Heat can do that. You can also keep a baseline of that... Here's what I use: $ cat bin/heat #!/bin/sh watch -n 5 "sensors ; top -b | head -20" I also recently learned about cpulimit(1), which is really useful for, as an example, transcoding. Could easily be something else, but checking for dust isn't a bad idea. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The audacity of it all...
On Wed, Aug 25, 2021 at 07:41:17AM +0200, tito via Dng wrote: > with this methods it will be a never ending cat and mouse game > and you give legitimation to audacity's new policy. There are other reasons to use this. Let's say you're doing security research and you want to strace or gcore a random binary but not let it write to disk or connect to the network. Here you are. This is a tool. Tools are good. -- Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The audacity of it all...
On Tue, Aug 24, 2021 at 06:41:59PM -0400, Mason Loring Bliss wrote: > So, whether you set it persistently or not, you start with: > > sudo sysctl -w kernel.unprivileged_userns_clone=1 > > ...and then you can run something that has no configured network: > > $ unshare -n ping 4.2.2.1 > unshare: unshare failed: Operation not permitted Didn't follow up here. One also needs to be mapped to root inside the namespace: $ unshare -r -n ping 4.2.2.1 connect: Network is unreachable Without that, it doesn't do much. =cough= -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] The audacity of it all...
When I first heard about Audacity's plans to start shooting data back to the mother ship, I was dismayed. But then I thought, "boy, we have some technical tools to address this" and I started digging. The obvious answer, since AppArmor made it into Devuan Beowulf, was to use that to block Audacity from using the network. After all, it can do absolutely everything I want without network access. Sadly, I soon ran into this, in apparmor.d(5): Some features are not supported on Debian yet: Network Rules DBus rules Unix socket rules I thought I'd check Debian Bullseye since it's out now, but it has the same limitation, which means Chimaera will have the same limitation. However, in digging, I noted that the same thing can be accomplished with the unshare(1) command. I tried "unshare -n" but it didn't work: $ unshare -n ping 4.2.2.1 unshare: unshare failed: Operation not permitted Turns out, there's a sysctl that defaults to "0" in Buster/Beowulf, but "1" in Bullseye/Chimera, that lets regular users do this. However, in addition to turning that on, as an additional step you have to say "map me to root in a new/cloned namespace so I can then have the privilege to drop the existing namespace". So, whether you set it persistently or not, you start with: sudo sysctl -w kernel.unprivileged_userns_clone=1 ...and then you can run something that has no configured network: $ unshare -n ping 4.2.2.1 unshare: unshare failed: Operation not permitted It's conceivable that a process running in this new space could note that it had no configured network and construct something, and as such this might not be as complete as the AppArmor answer would have been, but this has the advantage of being possible today. There's also an iptables-centric method: https://serverfault.com/questions/550276/how-to-block-internet-access-to-certain-programs-on-linux Either way, this is a good model for semi-trusted things that ought not to be allowed to use the network. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] ifupdown laptop wired/wifi trick
I've been managing network connections on my laptop by hand, and I was just
thinking that I'd like it to bring up its NICs automatically if it's
plugged in, but I didn't want to use ifplugd for various reasons, and
anyway, I like ifupdown and I want to stick with it.
I found Debian bug #120382 and it suggested using mii-tool in pre-up, and
that was just the right thing to do. The suggestion in the bug wasn't quite
the right syntax, but the right syntax was pretty obvious given the general
idea:
---
auto eth0
iface eth0 inet dhcp
pre-up /sbin/mii-tool eth0 | /bin/grep -qv "no link"
auto wlan0
iface wlan0 inet dhcp
pre-up /sbin/mii-tool eth0 | /bin/grep -q "no link"
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
---
The effect of this is that if I'm plugged into a wired network, eth0 fires
up dhclient. If I'm not, wpa_supplicant does its thing.
Interesting reading:
/usr/share/doc/ifupdown/examples/network-interfaces
There are a bunch of fun things you can do with ifupdown without invoking
the complexity of Network Manager documented there, but this mii-tool trick
isn't mentioned.
For folks on laptops, something worth learning is how to use
wpa_supplicant.conf to try a range of networks automatically. You can then
progressively try, for example, your home network, a work network, a coffee
shop network, and then look for open networks:
/usr/share/doc/wpasupplicant/README.Debian.gz
/usr/share/doc/wpasupplicant/examples/wpa_supplicant.conf
...and all only if the wired network isn't plugged in, if you use the
mii-tool trick.
Example /etc/wpa_supplicant/wpa_supplicant.conf:
---
network={
ssid="My Home"
psk="super secret"
priority=20
}
network={
ssid="Coffee Shop"
psk="also super secret"
priority=15
}
# But you're better off buying Fair Trade and drinking it at home.
# Work:
network={
ssid="MegaCorpWifi"
key_mgmt=WPA-EAP
eap=TTLS
identity="u...@example.com"
anonymous_identity="anonym...@example.com"
password="foobar"
ca_cert="blob://exampleblob"
priority=10
}
# Try open networks if none of the above are answering.
network={
key_mgmt=NONE
}
---
I'm mostly writing this so people realize that they aren't forced to use
some convoluted tool to flexibly manage networking. You can cover a wide
range of situations with good old ifupdown.
--
Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft!
awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] PartialSolve Re: Chimaera; Lost sound
On Fri, May 21, 2021 at 06:21:12PM +1000, terryc wrote:
> I'm still working on why the browsers(falkon & firefox-esr) and
> quiterss(what ever browser it loads) are not playing sound.
This is Beowulf, not Chimaera, but Firefox works fine with ALSA here,
including splitting input and output between different devices, etc.
$ cat ~/.asoundrc
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "dmix"
}
capture.pcm {
type plug
slave.pcm "hw:2,0"
}
}
I arrived at hw:2,0 (card 2, subdevice 0 - my USB webcam) for capture based
on:
$ arecord -l
List of CAPTURE Hardware Devices
card 0: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 2: ALC892 Alt Analog [ALC892 Alt Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: C525 [HD Webcam C525], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
We're plugging away at a wiki where we folks can easily document this
stuff.
--
Mason Loring Bliss (( If I have not seen as far as others, it is because
ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debian/Buster-to-Devuan/Beowulf : Version 1
On Wed, Apr 07, 2021 at 01:42:40PM +0200, Svante Signell via Dng wrote: > # Choose your editor > apt-get install emacs ... > emacs -nw /etc/network/interfaces And for anyone who only wants Emacs in a console, apt install emacs-nox ...and you won't get the X dependencies/bits. -- Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] On Non-Judicial Punishment of Individuals
On Sat, Apr 03, 2021 at 06:54:11PM -0700, Bruce Perens via Dng wrote: > On Non-Judicial Punishment of Individuals While this comes at the issue from a reasonable (and reasoned) angle, there is a significant issue to consider: This piece assumes a medical diagnosis but doesn't note public documentation of the diagnosis. We want to be aware of the problems with non-medical diagnosis just as we want to be aware of the problems with non- judicial punishment. This extends to speculation about the application of the ADA. I also worry some that the piece presents value judgements in a way that smacks of objective truth. This is somewhat troubling. My experience of Richard in proximity to women doesn't at all match what you're describing. As one of the more visible public figures in our space, you risk people accepting your value judgements as objective truth. I'm not suggesting you're wrong to use your lifetime of experience to filter and categorize your perceptions, but being a public figure, you may well bear an added burden when it comes to defining truth for people who might accept it unquestioningly. Personally I'm pleased that Richard is back on the board, just as I'm dismayed at some trusted staff members leaving the FSF. All of this takes the focus off of free software, and the people directly involved are hurting. Frankly, it makes me hope that my kids are able to forge a better world than what I've managed so far. -- Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FSF, RMS and a danger to almost all GPL code
On Thu, Apr 01, 2021 at 08:39:30AM -0400, Steve Litt wrote: > Didier Kryn said on Wed, 31 Mar 2021 12:07:50 +0200 > > > cancel-culture > > Please don't use that phrase, unless you're the second coming of Rush > Limbaugh. It's an ugly, Foxnews/right wing radio epithet for the > time-honored practice of boycotting, perhaps the last tool of power for > the average citizen. This bears some discussion. In a boycott, I choose to not deal with a company (usually) and that's it. I might publicise that I'm boycotting a place and why, but that's the extent of it. (To that end, my family boycotts Amazon and Wal-Mart.) This notion of "cancelling" someone is different. It's aimed at an individual, and it generally seeks to do them harm - see them out of a job, for instance, beyond public humiliation. I don't have a settled opinion about this. I've certainly thought "serves them right" when someone who harms other people is called out, but what's different here is that it's someone I respect, and a situation where I don't think the evidence presented against him holds up. This is someone who has dedicated his life to making the world a better place in a particular way, not, by comparison, an elected official mocking his electorate as they suffer and freeze to death (literally) because the climate disaster is catching up to us. And yet, I have to recognize that the people carrying the torches and pitchforks feel like RMS has done harm various ways. They think this, and they take the opinions and records as being valid, even if I can look at most of the same "evidence" and point out holes and context that utterly changes its character. It's worth using the phrase "cancel culture" because it's very different from a boycott, and we need to understand what it does, and how, and if there are better options for redressing grievances and finding justice. And I don't know how to do this. It'd be easy if everyone cared about people and we took care of each other, if people didn't victimize each other, but that's not yet the world we live in. I think "cancel culture" is the result of someone speaking up and saying "this cannot stand" and other people taking up the cry, but it's awfully close to mob justice. But if we don't want mob justice, we need a judiciary. We don't have one set up to rule on moral or ethical stances. We hardly prosecute white-collar or corporate crime at all, nowadays. So, there's the problem. What are possible answers? -- Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] motherboard BIOS update
On Fri, Jan 08, 2021 at 12:38:31PM -0700, Fred wrote: > fwupd.org doesn't work with Gigabyte. It's be worth reaching out to Gigabyte and saying "I'm a customer, and I'd like you to support fwupd". Looking at the list of companies that support the mechanism, it's clearly not a fly-by-night operation - it would be a way for Gigabyte to gain credibility and expand their customer base for effectively no effort. The fwupd folk would be quite happy to start working with Gigabyte, and have, as I understand it, reached out to them already, but Gigabyte needs to engage with them. -- Mason Loring Bliss (( "In the drowsy dark cave of the mind dreams ma...@blisses.org )) build their nest with fragments dropped http://blisses.org/ (( from day's caravan." - Rabindranath Tagore signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Disabling touchpad
On Sun, Dec 27, 2020 at 03:55:37PM -0500, Steve Litt wrote: > The attached touchtoggle.sh should fulfill your exact needs. Just > associate it with a convenient hotkey. Something worth noting is that it's reasonable to reference your stuff by name. For instance, on my T420: $ xinput | grep Synaptics ⎜ ↳ SynPS/2 Synaptics TouchPadid=11 [slave pointer (2)] Note that you *don't* have to parse out the ID. I can say, as an example: xinput disable "SynPS/2 Synaptics TouchPad ...and it'll do the right thing, far more simply. -- Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Fri, Dec 11, 2020 at 03:48:06PM +0100, Didier Kryn wrote: > I guess in Bash you could just issue 'exec startx', in which case bash > would go away, returning memory and leaving no place for intrusion. Oh, I hadn't considered that! Yeah, that should win. Thank you for the new perspective! -- Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Thu, Dec 10, 2020 at 10:31:38PM -0500, Mason Loring Bliss wrote: > Also, for laughs, in Beowulf, the xdm binary consumes 117K on disk, There's a pandemic on, so I'll forgive myself a little OCD. Sorted by RSS: $ ps uq 21538 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND mason21538 0.0 0.0 2388 1564 pts/3S22:38 0:00 dash $ ps uq 16459 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND mason16459 0.0 0.0 5640 1764 pts/3S22:32 0:00 ksh % ps uq 17848 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND mason17848 0.0 0.0 6688 2944 pts/3S22:34 0:00 -csh $ ps uq 20271 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND mason20271 0.3 0.0 9248 4060 pts/3S22:36 0:00 zsh $ ps uq 6064 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND mason 6064 0.0 0.0 8184 4532 pts/5Ss+ Dec09 0:00 -bash -- Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Thu, Dec 10, 2020 at 02:42:30PM -0500, Steve Litt wrote: > Wait a minute. When you say "without GUI", do you mean no X installed, > or do you mean it lacks the display manager to boot directly into X? > The former precludes desktop use; the latter is how I use my computer > every day, because startx and .xinitrc are my friends. Don't forget xdm, which ends up being what I use. I've never been keen on leaving a console sitting there logged in but largely forgotten just for startx, as someone could change to it and take advantage of it being somewhat vulnerable. But there are practical reasons to consider xdm. In terms of weight, compare: $ ps -uq 3944 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 3944 0.0 0.0 16396 2016 ?Ss Dec09 0:00 /usr/bin/xdm $ ps -uq 6181 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND mason 6181 0.0 0.0 7916 4140 pts/9Ss+ Dec09 0:00 -bash xdm is taking less than half the resident memory of a bash shell, so if you have to pick one of them to sit in the background doing nothing once it's facilitated, xdm consumes fewer resources. Also, for laughs, in Beowulf, the xdm binary consumes 117K on disk, versus 1.2M for bash. But this of course doesn't matter much, because deleting bash to save space is somewhat unlikely. Following the trail, though, dash consumes 119K on disk. Climbing up to the level of usable user shells, mksh consumes 275K on disk. (I can't seem to get myself to stick with tcsh long enough to call it usable, although I know some folks love it. But for completeness: 415K) -- Mason Loring Blissma...@blisses.org They also surf, who only stand on waves. signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Thu, Dec 10, 2020 at 01:40:39AM +0100, Adrian Zaugg wrote: > What shows > > apt remove --dry-run elogind I'll try to get a chance to do a new install, as I should figure out just what's pulling in what. I'll post this as soon as I've got it. I'm not sure what's pulling it in during debootstrap, but I can typically remove it. One thing I run now that wants either elogind or consolekit is libvirt-daemon-system on my hypervisors. I haven't yet taken the time to figure out why that's required. Someday, and/or I should look at alternatives. > Without GUI elogind can be removed easly with apt remove --purge elogind FWIW, you can also say (less typing) 'apt purge elogind'. I've got a recollection of purging elogind and having it insist on installing consolekit, but then being able to purge consolekit without it demanding elogind. I should take better notes whenever I encounter this kind of oddity. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Tue, Dec 08, 2020 at 09:22:03PM -0500, Mason Loring Bliss wrote: > On Wed, Dec 09, 2020 at 09:33:16AM +0900, Simon Walter wrote: > > > We were talking about libsystemd0 being a stub. > > It's not a stub. There's a bunch of functionality in there. A ton of it. > The elogind porters (who are distinct from Devuan/Debian maintainers) have > ifdef'd out a large amount of stuff, leaving a result that's pretty well > unreadable if you want to actually see what functionality is left. It's > doubtless easier for them to track upstream systemd this way, but it's an > awful mess, beyond the mess that systemd presents on its own, and even for > someone who does code analysis as part of his paid work, it's ...it's a mess, painful to trace, and painful to debug. Source code is meant for human programmers. Look at the elogind source code and tell me it's suitable for human consumption. I fear it's going to take a bunch of forked packages for Devuan to win free of it, given how Debian seems to be drinking the Kool-Aid. It wouldn't even be a problem if libsystemd0 actually presented functionality broken into logical units, packaged as distinct libraries. It's this whole "here, you have to take all of it at once to use any of it" lock-in strategy that makes it unacceptable. Here's a fairly recent EFF podcast with Cory Doctorow talking about user lock-in. It applies fairly directly, even if the users in this case are distribution packagers and not service end-users: https://www.eff.org/deeplinks/2020/11/podcast-episode-control-over-users-competitors-and-critics -- Mason Loring Bliss (( "In the drowsy dark cave of the mind dreams ma...@blisses.org )) build their nest with fragments dropped http://blisses.org/ (( from day's caravan." - Rabindranath Tagore signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Wed, Dec 09, 2020 at 09:33:16AM +0900, Simon Walter wrote: > We were talking about libsystemd0 being a stub. It's not a stub. There's a bunch of functionality in there. A ton of it. The elogind porters (who are distinct from Devuan/Debian maintainers) have ifdef'd out a large amount of stuff, leaving a result that's pretty well unreadable if you want to actually see what functionality is left. It's doubtless easier for them to track upstream systemd this way, but it's an awful mess, beyond the mess that systemd presents on its own, and even for someone who does code analysis as part of his paid work, it's > It is too easy to assume you are a troll by the way you edit my email. Hardly. https://en.wikipedia.org/wiki/Posting_style#Interleaved_style > If you can't trust the Devuan devs, then maybe you Devuan is not suitable > for your uses. I should say that if you're unaware of who's actually writing your software, perhaps it's not suitable for your uses. The Devuan developers didn't write elogind. Regardless, as I noted previously, Unix libraries group routines by function. There is no logical grouping to describe libsystemd0. It wants to be another level of libc and this is lazy design. If one wants a dbus library, one should use a dbus library. If one wants to manipulate green widgets, one chooses a library that manipulates green widgets. I'm not sure what a systemd library would accomplish beyond accessing systemd. In a system lacking systemd, it serves no purpose. > Why don't you find out who the authors of libsystemd0 are and present > your concerns to them? Why in the world would I do that? I don't care about systemd outside of a work context and I don't wish to have pieces of it running on my systems without an explicit invitation. I certainly don't want to have it forced on me, and I can think of no compelling reason why I should accept it. -- Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Tue, Dec 08, 2020 at 05:01:49PM -0500, Mason Loring Bliss wrote:
> Let's start with how much systemd code we're talking about. Admittedly, I'm
> not cutting out comments or whitespace here, but even so:
>
> .../elogind-241.4/src$ find . -name '*.c' -exec cat {} \; | wc -l
> 125582
Alright, this is misleading. Looking at various bits of source, elogind has
#ifdef'd out some substantial amount of the code. Hopefully this has been
done with a complete understanding of interdependencies so the code that's
left is coherent.
I still see nothing that convinces me that this thing should persist, of
course.
--
Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft!
(if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Fri, Dec 04, 2020 at 09:56:54AM +0900, Simon Walter wrote:
> Unfortunately for those who are scared of source code and perhaps those
> who are scared in general, it is all too easy to become paranoid. After
> all, you are at the mercy of those who are not scared. I'd say, pick up
> programming as a hobby and conquer your fear. Walk with your head high.
Doesn't that embarass you, writing something like that?
> Then maybe you'll understand what stub means.
I'm curious if you've actually looked at the source code we're talking
about.
Let's start with how much systemd code we're talking about. Admittedly, I'm
not cutting out comments or whitespace here, but even so:
.../elogind-241.4/src$ find . -name '*.c' -exec cat {} \; | wc -l
125582
--
Mason Loring Bliss (( If I have not seen as far as others, it is because
ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Tue, Dec 01, 2020 at 03:33:41PM +0100, Antony Stone wrote: > What, specifically, gets installed as part of Devuan which you don't want to > see there? As an exercise, try doing a minimal install via debootstrap, which is arguably the easiest way to tailor an install. I've thus far not managed to get an install through without elogind creeping in, even if I explicitly mark it as something to ignore. The Devuan live media I use for installs runs elogind. It sort of reminds me of the Agent Smith virus speech from The Matrix. > libsystemd0 is a stub library which contains none of the objectionable > code or "features" which people who don't want systemd are trying to keep > away from. Unix libraries bundle related functionality together so that you can link just that which you need. Can you explain how libsystemd0 fits into this model? I'm unclear on what set of related functions it provides. -- Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Mon, Nov 30, 2020 at 05:34:48PM -0500, Steve Litt wrote: > The fact that Redhat is #64 tells me not that many people are buying > their stupid support, Lest we get too excited, let me note two things: https://distrowatch.com/dwres.php?resource=faq#phr This says, What is this "Page Hit Ranking"? It is a light-hearted way of looking at popularity of distribution. Since each distribution has its own page, we thought it would be fun to track the number of visitors viewing individual distribution pages. The Page Hit Ranking (PHR) figure represents hits per day by unique visitors; as determined by the visitor's IP address. So, you need to ask yourself if the people buying Red Hat support contracts are visiting DistroWatch daily. I'd argue that, having made their choice, they probably aren't weighing the merits of deploying MX Linux to their datacenters. > And given Redhat's, Freedesktop's and Poettering's rhetoric about how > completely systemd has taken over, #64 is unexpectedly low This brings us to the other thing worthy of note. Try sometime to install Devuan (not Debian, Devuan) without systemd and you'll be in for a rude shock. It's installed by default, and it's a massive pain to eradicate it. Does this bother you? It bothers me. If it's impossible to install *Devuan* without systemd, that's problematic. (To forestall the inevitable pedantry, elogind is systemd. It's a major component of it. And libelogind0 maps directly to libsystemd0. A rose by any other name...) -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
On Tue, Nov 03, 2020 at 12:24:35PM +0900, Simon Walter wrote: > > Could it be related to this? > > > > https://github.com/NLnetLabs/unbound/issues/303 > > I don't think so - unless you are paranoid about anything that RH employees > contribute to. Hah, if you're paranoid about projects RH employees contribute to, then you're all in trouble. :P But yes. I'd found an issue where Unbound wasn't obeying service management in Devuan, and then that spiraled out into it being CVE-worthy. But for our purposes, unbound changes ownership if its PIDfile, and this means that our start-stop-daemon refuses to operate on it - if the process can be subverted, it can write any PID in there, for instance, and cause us to kill an arbitrary daemon. If the process can make the PIDfile into a symlink, it can maybe cause us to overwrite arbitrary files, and so forth. It's not yet wholly clear how upstream will fix it. Depending on that, we might end up needing to fork it - Debian will be unaffected since they don't insist on sysvinit compatibility any more. For my part, I've stopped using unbound at all. I've been using BIND for many years, and it works just fine in this role too. -- Mason Loring Bliss ma...@blisses.orghttp://blisses.org/ For more enjoyment and greater efficiency, consumption is being standardized. signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Building De{vu,bi}an kernel packages with embedded ZFS
Some working notes for building ZFS into the kernel using the new mechanisms. The last time I built Debian kernels, it was with make-kpkg, and evidently things have improved substantially since then. I've been building custom ZFS modules for a while, as some of my hardware that uses ZFS is too slow to really have DKMS be viable. But even with the modules, you have the issue of needing to build a new ZFS kmod for each upgrade, and then if for some reason you install the kmod in a different apt run from when you installed the new kernel, you'll probably find that depmod didn't run and your initramfs didn't catch the new module, and you have to correct it... I've done this often enough that I've got a fairly strict procedure where I add the new kmod-zfs on the same run as when I install the kernel, but this requires a little more discipline than is ideal. So, last night I decided to try building ZFS into the kernel so I don't need modules at all. The down side is that I'm building my own local kernel. The upside is also that I'm building my own local kernel. :) Plus, I can just let the system update normally, pulling whatever's newest from my local repository. (I'll document that sometime - more reason for me to work on our wiki project.) A great reference for the new way to build kernel packages is here: https://debian-handbook.info/browse/stable/sect.kernel-compilation.html Build prerequisites are noted here: https://wiki.debian.org/BuildADebianKernelPackage Since the last time I was building my own, Linux has learned how to build Debian kernel packages, so there's no further need to have extra tools, and you don't have to build as root any more, both of which are nice. Since my goal is to build ZFS into my kernel, I need to configure it and run a supplied script. It's assumed that you've unpacked the kernel source into a local directory: mkdir ~/kernel cd ~/kernel tar xf /usr/src/linux-source-4.19.tar.xz Adding in ZFS bits: cd ~/zfs-0.8.5/ ./configure ./copy-builtin ~/kernel/linux-source-4.19/ And then finally building the kernel: cd ~/kernel/linux-source-4.19/ cp /boot/config-4.19.0-12-amd64 .config sed \ -i 's/CONFIG_SYSTEM_TRUSTED_KEYS=.*/CONFIG_SYSTEM_TRUSTED_KEYS = ""/g' \ .config make oldconfig # say 'y' when asked about ZFS and # whack enter when asked about additional X.509 keys make deb-pkg LOCALVERSION=-bliss KDEB_PKGVERSION=$(make kernelversion)-1 In truth, I edited the .config to eliminate CONFIG_SYSTEM_TRUSTED_KEYS manually after I ran "make oldconfig". This should work as written - I've tested it up to but excluding the actual build. I did see the following warnings as the build process got partway through ZFS but I've not observed any fallout from this. AS fs/zfs/icp/asm-x86_64/sha1/sha1-x86_64.o fs/zfs/icp/asm-x86_64/sha1/.tmp_sha1-x86_64.o: warning: objtool: sha1_block_data_order()+0x11: unsupported stack pointer realignment AS fs/zfs/icp/asm-x86_64/sha2/sha256_impl.o fs/zfs/icp/asm-x86_64/sha2/.tmp_sha256_impl.o: warning: objtool: SHA256TransformBlocks()+0x19: unsupported stack pointer realignment AS fs/zfs/icp/asm-x86_64/sha2/sha512_impl.o fs/zfs/icp/asm-x86_64/sha2/.tmp_sha512_impl.o: warning: objtool: SHA512TransformBlocks()+0x1c: unsupported stack pointer realignment I'm running the kernel built by this process on a couple systems now to give it a chance to do its thing for a while. My understanding is that running built-in is the least-tested configuration, so make sure you've got reliable and tested back-ups. (But of course you do already, right?) NOTE: while a lot of the GPL/CDDL interaction people complain about is quasi-legal FUD - the whimsical notion of modules becoming derivative works, for instance, has never been tested in court - what we're doing here is pretty clearly defined, and while your building ZFS into the kernel and using it yourself is Just Fine, you're unambiguously violating the GPL if you distribute the resulting binaries to other people, so don't do that. Finally, note also that you still have to build and install the ZFS userland tools. This process I've documented just obviates needing a separate kernel module. You can follow the instructions here: https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html TL;DR: cd ~/zfs-0.8.5/ ./configure make -j1 deb-utils At some point, to go along with this, I'll post my native-ZFS-root installer scripting and notes, which assumes modules and will optionally assume built-in ZFS before long, and which supports either LUKS or native ZFS encryption, both with or without mirroring, on either UEFI or legacy systems. (It's flexible. It'll even install Debian or Ubuntu.) (It'll make the most sense for me to ship instructions for a local repository first.) -- Mason Loring Bliss (( If I have not s
Re: [DNG] Clarification please
On Thu, Oct 29, 2020 at 04:53:43PM +, g4sra via Dng wrote: > Please correct me if I am mistaken, I thought 'unbound' was tied to > 'systemd creep' nowadays and have been avoiding it for that reason alone. No, that's systemd-resolved. Unbound is unrelated. That said, I've stopped using unbound and I'm using straight BIND as my local resolver lately. It's pleasant. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Complete system HDD encryption w/o LLVM.
On Tue, Sep 29, 2020 at 07:57:46PM +0100, g4sra via Dng wrote:
> > If you include the "initramfs" option in /etc/crypttab, keys noted in
> > entries marked with that will be automatically included.
> >
>
> Not in the scripts I had, they explicitly excluded any keys for the root
> filesystem because Debian Devs know better than me (including them in an
> initramfs is insecure).
Ah, sorry. I was thinking of filesystems to be unlocked, not key data
itself. I include "initramfs" in crypttab and I use passphrases on boot,
and that keyword is what enables the prompt for the filesystem(s) in
question. I sometimes have others that use keys that are on the encrypted
root, and those don't specify "initramfs" as they can wait until the normal
boot phase.
Only vaguely related, something I haven't played with yet that I'd like to:
https://github.com/latchset/clevis
--
Mason Loring Blissma...@blisses.org
They also surf, who only stand on waves.
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Complete system HDD encryption w/o LLVM.
On Tue, Sep 29, 2020 at 04:02:35PM +0100, g4sra via Dng wrote: > Copy /boot over onto / > * rebuild the initramfs in the NEW /boot on / * > ^^^ > ^^^ you will need to hack the initramfs-tools scripts or they will > exclude the Luks key ^^^ If you include the "initramfs" option in /etc/crypttab, keys noted in entries marked with that will be automatically included. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Complete system HDD encryption w/o LLVM.
On Tue, Sep 29, 2020 at 08:58:42PM +0700, Андрей via Dng wrote: > Question is, Is it possible to to achieve same goal without LLVM -- > i.e. to partition system HDD with fdisk, and then still have full > encryption? Yes, or at least, mostly. There needs to be unencrypted data that contains the decryption code. GRUB itself can handle LUKS decryption, but that would involve a manual installation. There are a number of ways to encrypt a system, in any event, and you can certainly use the "manual" partitioning in the Debian installer to set up a system that's largely encrypted, without LVM, but remember to supply an un- encrypted /boot, as unless something's changed very recently, Debian (and Devuan by extension) doesn't know to configure GRUB to unlock an encrypted /boot. I found this that talks about encrypted /boot (or /boot on encrypted root) but it would require manual installation, and I'm not sure how easy it'd be to adapt Debian's GRUB scaffolding to accomodate it. Might be easy, might be nearly impossible. But: https://wiki.archlinux.org/index.php/Grub#Encrypted_/boot -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
On Thu, Sep 17, 2020 at 04:48:06PM +0300, Dimitris via Dng wrote: > tito already wrote the solution for nm in this thread : Ah, this'll teach me not to read the whole thread before I reply. > so you can use local dns caching, unbound, dnsmasq, other... FWIW, I've been using BIND for this role lately, and it's been quite pleasant. -- Mason Loring Bliss ma...@blisses.orghttp://blisses.org/ For more enjoyment and greater efficiency, consumption is being standardized. signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
On Wed, Sep 16, 2020 at 08:45:06AM -0400, Hendrik Boom wrote: > On Wed, Sep 16, 2020 at 02:11:57AM -0400, Steve Litt wrote: > > > > Speaking of Netowrk manager, am I the only one who hates it messing > > with /etc/resolv.conf? > > No. You are not the only one. I prefer ifupdown, but I like Network Manager for laptops. This particular behaviour can be managed, which is useful for me given that I have various ways I need to manage resolv.conf on different systems. For what it's worth, here's an excerpt from the NetworkManager.conf(5) man page - take special note of the last paragraph: dns Set the DNS (resolv.conf) processing mode. If the key is unspecified, default is used, unless /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf, /run/systemd/resolve/resolv.conf, /lib/systemd/resolv.conf or /usr/lib/systemd/resolv.conf. In that case, systemd-resolved is chosen automatically. default: NetworkManager will update /etc/resolv.conf to reflect the nameservers provided by currently active connections. dnsmasq: NetworkManager will run dnsmasq as a local caching nameserver, using a "split DNS" configuration if you are connected to a VPN, and then update resolv.conf to point to the local nameserver. It is possible to pass custom options to the dnsmasq instance by adding them to files in the "/etc/NetworkManager/dnsmasq.d/" directory. Note that when multiple upstream servers are available, dnsmasq will initially contact them in parallel and then use the fastest to respond, probing again other servers after some time. This behavior can be modified passing the 'all-servers' or 'strict-order' options to dnsmasq (see the manual page for more details). unbound: NetworkManager will talk to unbound and dnssec-triggerd, providing a "split DNS" configuration with DNSSEC support. /etc/resolv.conf will be managed by dnssec-trigger daemon. systemd-resolved: NetworkManager will push the DNS configuration to systemd-resolved none: NetworkManager will not modify resolv.conf. This implies rc-manager unmanaged -- Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Can this drive be saved?
On Sat, Sep 05, 2020 at 01:41:46PM -0400, Hendrik Boom wrote: > Nowadays the hardware replaces individual bad blocks without bothering > the file system. Where it can, yeah. That said, I've seen some of the corruption that we're supposed to never see - the bitflips in files that people use to demonstrate self-healing filesystems - prior to my become a ZFS zealot. The awfully nice thing about ZFS is that if you have a mirror or better, each drive stores both data and a checksum of that data, so you have an awfully good chance of finding one bit of recorded data that matches one checksum, and if you have that, ZFS can rewrite all the bad data. Even with a single disk, you can specify multiple copies to achieve the same thing, although catastrophic failure of the disk is always a possibility, making a proper mirror *and* back-ups preferable. As a random note, the upstream ZFS custom package instructions work out of the box on Devuan, and they still ship sysvinit files when built that way. https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html At some point there will be other filesystems that do the same. BtrFS isn't far behind, and hopefully some increased attention will get it the rest of the way. Red Hat's Stratis and DragonflyBSD's Hammer2 will both have self- healing working before long, using different approaches. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RFC: wiki software
On Fri, Sep 04, 2020 at 07:53:54PM -0700, tom wrote: > How many Gemini and Kristall (or any other Gemini client of your > choosing) https://gemini.circumlunar.space/ As it turns out, we were talking about that at the last meeting, and there's probably interest in it. -- Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] RFC: wiki software
Hi all! We're looking for opinions about wiki software. First choice at the moment is TWiki but we want more options and more perspective to get us to the best possible decision. Goals, not in a particular order: * Ideally not Python, PHP, Java unless it's otherwise perfect. * Supports ACLs for per-account and/or per-group editing privs. Ability to disable edits by people not logged in. * Potentially supports ACL-based visibility in addition to editing privs. * Supports at least a minimum live editor, with mark-up being fine - no need for WYSIWYG. * Flat files on the back end - ideally content can be captured to version control, can come from version control, etc. * JavaScript not required for clients. We'll continue poking at TWiki while we gather data. -- Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] buster to beowulf
On Thu, Jan 16, 2020 at 06:45:44PM -0500, Hendrik Boom wrote: > Is there a draft of the instructions from buster to beowulf? A draft I could > maybe help debug by following it? This is stolen from the forums and modified slightly. Most of the wording is taken directly from the post, but I've added details so I can find everything in one spot. Taken from https://dev1galaxy.org/viewtopic.php?id=3044 -- Short version: - boot buster, install sysvinit-core -- download and install devuan-keyring: wget http://pkgmaster.devuan.org/devuan/pool/main/d/devuan-keyring/devuan-keyring_2017.10.03_all.deb dpkg -i devuan-keyring_2017.10.03_all.deb -- change sources to devuan, update, upgrade deb http://pkgmaster.devuan.org/merged beowulf main non-free contrib deb-src http://pkgmaster.devuan.org/merged beowulf main non-free contrib deb http://pkgmaster.devuan.org/merged beowulf-security main non-free contrib deb-src http://pkgmaster.devuan.org/merged beowulf-security main non-free contrib deb http://pkgmaster.devuan.org/merged beowulf-updates main non-free contrib deb-src http://pkgmaster.devuan.org/merged beowulf-updates main non-free contrib -- install eudev and let it fail. This might save some time on the first reboot. reboot and install eudev, remove or purge systemd if it doesn't get removed automatically. (possibly libnss-systemd also) (optional) install libelogind0 if you want to replace libsystemd0. Without elogind, it's not pulling in the desktop apps. -- Beware of "predictable interface naming" - depending on how you configure your network, you might see your NIC names change. -- Mason Loring Bliss"An equation for me has no meaning unless it expresses ma...@blisses.orga thought of God." - Srinivasa Ramanujan signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] PXE booting, initial notes
I want to be able to install via PXE booting, but Devuan doesn't (yet) provide the tools for this. So, I've started poking around, and I've got something crufted together. There's more work to do, but I wanted to share what I've got now. Maybe it'll inspire someone and they'll cross the finish line sooner than me. I stared with netboot.tar.gz from Debian and a Devuan netboot ISO. My DHCP server is Debian 9 right now, but this shouldn't matter much. I added this extra bit of configuration, global scope in /etc/dhcp/dhcpd.conf. allow booting; next-server 1.2.3.4; filename "pxelinux.0"; Change 1.2.3.4 to the name or address of your DHCP/tftp server. I then installed tftpd. Something that ends up being useful is adding the -s flag to inetd.conf and restarting inetd, so that we don't have to edit all the files we'll pull from the ISO. So, at the end of the appropriate line: /usr/sbin/in.tftpd -s /srv/tftp The Debian netboot stuff is all relative paths, whereas the ISO looks for /linux and /initrd.gz. The -s flag is fine for either Devuan or Debian. We want pxelinux.0 from Debian's netboot.tar.gz until I learn how to build it locally, so: cd /srv/tftp ; tar xf /path/to/debian/netboot.tar.gz rm ldlinux.c32 pxelinux.0 pxelinux.cfg version.info cp debian-installer/amd64/pxelinux.0 . rm -r debian-installer (In short, we pulled out that one file, and nuked everything else.) The rest of the bits come from the Devuan ISO: mount -o loop devuan_ascii_2.1_amd64_netinst.iso /mnt cp /mnt/isolinux/* . cp /mnt/linux . cp /mnt/initrd.gz . cp -r /mnt/install . mkdir pxelinux.cfg ln -s ../isolinux.cfg pxelinux.cfg/default Note that you can't actually install from this yet, as what we boot is quite literally the netinst CD's contents, and it wants to find an attahed CD, but this is an initial set of notes, so we'll push on. Next for me: I want to net-install Beowulf ZFS installs, based on my physical media installs, so I'll write up notes about how to use debootstrap to build an install environment we can netboot, presumably with an NFS root. We should be able to identify the config bits that want a CD and swap in config bits that just default to wanting a network mirror. If you take their netboot.tar.gz initrd and unpack it: gzip -cd initrd.gz | cpio -id in a directory somewhere, pay attention to, among other things: sbin/debian-installer* lib/debian-installer* We presumably have all the tools we need, and just need to point debconf/d-i in the right direction. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ascii/Beowulf nonfree firmware
On Fri, Jan 10, 2020 at 10:05:25AM -0700, 'smee via Dng wrote: > I powered off, removed and replaced the battery, and booted up again > and wifi works fine still. So it appears the nonfree firmware wasn't > needed for anything on my install, at least so far. By comparison, the wifi in my Thinkpad T420 requires the non-free firmware: iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Advanced-N 6205 AGN, REV=0xB0 -- Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
