Re: [Dng] What to do with udev? Some ideas...
On Wed, Dec 31, 2014 at 11:29:15AM -0500, Walter Dnes wrote: > On Wed, Dec 31, 2014 at 03:03:50PM +0100, Enrico Weigelt, metux IT consult > wrote > > On 31.12.2014 10:59, Jude Nelson wrote: > > > > Hi, > > > > > However, future entanglements with systemd and kdbus could make this > > > much harder, to the point that eudev has no choice but to diverge > > > from udev, thereby increasing the maintenance burden considerably. > > > > yeah, sooner or later there'll need to do a full fork. > > we should get in contact with them (I just posted a first mail onto > > their maillist). > > Hi; I read that post. Has anyone here considered "mdev" from the > busybox package? I'm not a C/C++ programmer, just a Gentoo user, > but I've been able to replace udev with mdev on my home machines. I was > the -disturber who started up the wiki page... > https://wiki.gentoo.org/wiki/Mdev Yes, mdev has been mentioned numerous times on this list. I tried following that page or a related one to set up X11 sans udev on Debian, but never got keyboard input working. (Wondering about configuration/if I need to recompile Mesa and X...). > I've also managed to enable automounting of USB devices using an ash > script (I did say I'm not a C/C++ programmer). *GUI NOT REQUIRED* See > the wiki pages... > https://wiki.gentoo.org/wiki/Mdev/Automount_USB > https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount > Part of the reason for the "um" script is to allow a regular user to > unmount a USB key or drive, without constantly running as root, and > "giving away the store", security wise. I wonder if mount -o users,... would do what you want. > /etc/mdev.conf supports executing commands after-creating and > before-removing a device, analagous to "writing udev rules", but > different format. busybox is actively maintained at > http://www.busybox.net/ so it should be around permanently. > > -- > Walter Dnes Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] libudev and device querying
On Wed, Dec 31, 2014 at 02:44:49PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 31.12.2014 13:44, Matteo Panella wrote:
> > On 31/12/2014 13:16, Enrico Weigelt, metux IT consult wrote:
> >> hmm, which ones for example ?
> >> maybe we should have a deeper look into them.
> >
> > Accounting for direct rdeps alone:
> >
> > (jessie-amd64)morpheus@vingilot:~$ apt-cache rdepends libudev1
> > libgudev-1.0-0
> > libudev1
> > Reverse Depends:
>
>
>
> Wow, that's a _really_ long list.
>
> Just did a little bit of digging. File managers seem to use it for
> querying available devices for mounting. IMHO, these tasks should
> be moved to an separate agent, which can be called via some simple
> command line interface - each device manager then should supply it's
> own implementation for that command.
>
> What do you think about that ?
It's possible to get a list without a device manager:
parse the output of 'blkid'.
The issue is that you'll need to update that periodically, and polling
is not very nice.
Setting up an fanotify hook on /dev wouldn't work since fanotify doesn't
support create/delete/move events, which are all that we want.
But maybe watching /dev/disk/by-{uuid,label}/ for create/delete events
with inotify would do it. Then we could configure mdev so that when a
device of devtype "partition" is added, it links it into the right
directory. udev already does this.
Those who use a static /dev without these directories would get the
results of the first blkid, and no updates--which seems like exactly
what they would want.
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What to do with udev? Some ideas...
mesa uses udev to load the correct hardware driver. There is a fallback available if you configure it with --enable-sysfs or a similar flag. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] NetworkManager alternative
On Wed, Dec 31, 2014 at 01:44:39PM +0100, Enrico Weigelt, metux IT consult wrote: > On 26.12.2014 21:09, Mauro Cicio wrote: > > I gave up on NM and I am having a great experience with wicd > > Just switched my Ubuntu notebook to wicd, some days ago, and it > seems to work quite well. > > One thing which is still sucking: it uses the ugly dbus. > Perhaps I'll find some time to rewrite it using fuse. dbus is probably used to communicate with wpa_supplicant; the alternative is using UNIX sockets or using wpa_cli, which in turn uses UNIX sockets. The protocol seems to be some ASCII-based protocol where you open two sockets, wait for acknowledgement, write a one-line command to one socket, and listen to the other for the response. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What to do with udev? Some ideas...
On Wed, Dec 31, 2014 at 11:08:32PM -0500, Jude Nelson wrote: > On Wed, Dec 31, 2014 at 1:55 PM, Isaac Dunham wrote: > > mesa uses udev to load the correct hardware driver. > > There is a fallback available if you configure it with --enable-sysfs > > or a similar flag. > I haven't read the mesa code yet, but it sounds like mesa uses udev to help > it (1) insert the right kernel module, and (2) load the right firmware. > udev gets its information from sysfs and/or its netlink socket, so I'd > imagine mesa uses a similar technique with the --enable-sysfs option. Do > you know if this is the case? Not quite. 0: Before the display server starts, the hotplugger/system init scripts/root loads the right kernel driver. The kernel/hotplug helper/hotplug daemon loads the right firmware (and creates a device). 1: Display server starts, probing for drivers (which are hardware-specific libraries implementing the API X or Wayland wants in terms that the kernel drivers can understand.) 2: Depending on the display server driver, either this driver or a user program needing gl/egl/... loads and initializes Mesa. 3: In the course of initialization, Mesa probes for (OpenGL) drivers (libraries which compile generic gl/egl/... commands into hardware-specific commands). If I'm understanding the code correctly, * with udev: the mesa loader passes udev an fd for a device, and udev returns the vendor and chip pci ids * with enable-sysfs: the mesa loader looks up the major and minor for a device (fstat()), then it generates a sysfs path based on the major and minor, then it looks there for vendor and chip ids Finally, the mesa loader compares the vendor and pci ids to a list it has, and selects a driver (hardware-specific library) to dlopen(). udev might use the same method for looking ids up, or it might not. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] dpkg packaging problems
On Fri, Jan 02, 2015 at 04:52:11PM +0100, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > > I'm just packaging Jude's fskit to various deb distros using > pbuilder + git-buildpackage. > > Unfortunately, the .so's loose the +x flag in the package > (while usual 'make install' is okay) - it seems that some of the > dh stuff drops that flag :( ls -l /lib/i386-linux-gnu/ in my Debian partition shows all .so's except ld-2.19.so being chmod a-x. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] vdev update and design document
On Wed, Jan 14, 2015 at 07:56:15AM +, Noel Torres wrote: > On Friday, 2 de January de 2015 19:43:04 Jude Nelson escribió: > > Hi Luke, > > > > I should point out, the ACL criteria for matching processes do not all have > > to be specified, specifically for the reason you point out. Using the > > SHA256 to match the process should be a tool of last resort, useful only > > when the executable's path, inode number, and PID listing commands are > > unreliable (for example, a program that runs from an arbitrary location but > > for which no PID listing program can be created). Also, taking the SHA256 > > would be very slow compared to the other criteria. I'll update the design > > document to emphasize that vdev does not need all of the criteria to be > > set--just the ones that describe the class of processes the ACL affects. > > > > As much as I would like to revoke file descriptors, I'm afraid there's no > > way to do this that I know of without the kernel's help (but I'd love to > > learn of one). Systemd-logind has the same problem--once a process opens a > > file descriptor, another process can't force it to close it (i.e. with > > systemd-logind, the client can simply dup(2) the file descriptor before > > systemd-logind closes it). FreeBSD has revoke(2), but AFAIK there is no > > equivalent syscall for Linux. > > Just a wild idea... > > We could use /dev-real for the device nodes and /dev for named pipes pointing > to the device nodes. The named pipes can be connected or disconnected at > will, > depending on the invoking process, while specialized programs (or root) could > just lurk around /dev-real if something needs to be debugged. This works for > reading and writing, but not for locking or ioctl, I know, but it is an > idea... This will instantly break: -mount -OSS and ALSA audio (note that these both expect a device in /dev). -anything that manipulates block devices/partitions -anything that checks device type/major/minor eg, one could check that /dev/*random has the right major and minor. I don't know if it would work with ttys/ptys. > Just two (euro) cents > > er Envite Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Purpose of all this complicated device management?
On Sat, Jan 17, 2015 at 08:06:05PM +0100, k...@aspodata.se wrote: > Gravis: > > karl, what's with the hostility? > > Oh, maybe it come out to harsh, sorry for that. > > > vdev is by no means required and > > nothing depends on it, so nobody is being forced to even install it. > > also, since it is based on FUSE, it won't actually add/remove static > > device files, so when the program exits, it will go back to your > > static device files. you can set rules in the vdev config file so > > that you can make devices behave as you wish. vdev is still in > > development, so no behavior is set in stone and can updated for new > > situations as they are discovered/reported. > > I think I was mostly talking about udev, or rather about people who > don't accept that some users actually don't need udev. > > /// > > One use case I could find useful is to have an xdev that I could > run from-time-to-time to check if I'm missing something in /dev. For what it's worth, I've used "busybox mdev -s" for this purpose. Note that it *creates* devices, rather than outputting a list of filenames with attributes. > Also a lib that maps major/minor to /dev/name and the like, a command > that "scans lspci" and the like, and suggests kernel modules, > which I then at my own discretion can add to /etc/modules. > I.e. an udev that instead of taking over the system, gives me some > tools I could use to examine a system. To map major/minor/devtype to /dev/name (note: /dev/zero has the same major/minor as /dev/ram5; one is char, the other is block) you really need to recurse through /dev and find the first file that matches. I could write a non-threadsafe version of said function using nftw() in a day, I suppose; if I lift the dirtree code from toybox and patch it to fit, it might be not be much more work... So does "libsysdev" sound like a good name, and char * sysdev_getdevname(int major, int minor, int ischar); seem like a good prototype? Your proposed command that would "scan lspci" is roughly equivalent to either of these command lines: find /sys -name modalias | xargs sort -u | xargs resolve_modalias find /sys -name uevent -exec sed -ne 's/^MODALIAS=//p' + | \ sort -u | xargs resolve_modalias where resolve_modalias is a command that finds all entries in /lib/modules/`uname -r`/modules.alias expanding to match each argument. Sample: $ resolve_modalias pci:v8086d27D8sv1025sd015Bbc04sc03i00 snd_hda_intel I've implemented resolve_modalias in the past, and there have been similar commands written elsewhere. But really, your requests are very close to the standard usage for mdev. Substitute "modprobe -abq" for "resolve_modalias", and the command line above is the standard way to autoload drivers. > Regards, > /Karl Hammar Hope this helps, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] minimal init
On Sat, Jan 17, 2015 at 11:13:46PM +0100, k...@aspodata.se wrote: > Someone mentioned [1]. > > So I tried busybox's init. It works great, my exp. config is at [2]. > > /// > > Also it would be possible to have a startup script (/etc/rcS) like: > > #!/bin/bash > > echo -n "Which init do you want to use? " > read -t 5 a # bash's read has a timeout option > if [ $? -gt 0 ] > then > echo timeout, use normal init > exec /sbin/normal_init > else > echo Switching to init_$a > exec /sbin/init_$a > fi > > /// > > Basically, nothing hinders one to choose init's on the fly, or ? Wouldn't work: init is PID 1 (init starts /etc/rcS, not the other way around). If you wanted to switch init after boot, you need to have that script in /sbin/init and have all other inits at other paths. > (Well yes, they need different /etc/inittab's, but that is solvable.) > > Regards, > /Karl Hammar > > [1] http://www.troubleshooters.com/linux/init/manjaro_experiments.htm > [2] http://turkos.aspodata.se/computing/busybox_init.txt HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] libsysdev preview
On Sun, Jan 18, 2015 at 01:11:15PM +0100, k...@aspodata.se wrote:
> Isaac Dunham:
> > On Sat, Jan 17, 2015 at 08:06:05PM +0100, k...@aspodata.se wrote:
> > > Also a lib that maps major/minor to /dev/name and the like, a command
> > > that "scans lspci" and the like, and suggests kernel modules,
> > > which I then at my own discretion can add to /etc/modules.
> > > I.e. an udev that instead of taking over the system, gives me some
> > > tools I could use to examine a system.
> >
> > To map major/minor/devtype to /dev/name (note: /dev/zero has the same
> > major/minor as /dev/ram5; one is char, the other is block) you really
> > need to recurse through /dev and find the first file that matches.
> >
> > I could write a non-threadsafe version of said function using nftw()
> > in a day, I suppose; if I lift the dirtree code from toybox and patch
> > it to fit, it might be not be much more work...
> >
> > So does "libsysdev" sound like a good name, and
> > char * sysdev_getdevname(int major, int minor, int ischar);
> > seem like a good prototype?
>
> Yes.
>
> Mesa uses the name sysfs, which might be better than sysdev.
> The following two might be a good start:
>
> $ grep ^sysfs src/loader/loader.c
> sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
> sysfs_get_device_name_for_fd(int fd)
>
> and
>
> dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min)
>
> libsysfs seems to be taken:
> http://linux-diag.sourceforge.net/Sysfsutils.html
> http://storage.jak-stik.ac.id/linux/doc/sysfsutils/libsysfs.pdf
libsysfs, which is used by udev, has already taken the sysfs_ namespace.
I don't want to collide with that.
I'd like to provide something that can be utilized as a fallback when
libudev is missing/udev doesn't start.
Optimally, the API will be simple enough that developers then say
"And why aren't we using this *instead* of libudev?"
A preview is available at
https://github.com/idunham/libsysdev
There's a basic example at util/devinfo.c, and the header has comments
tersely explaining what inputs each function takes.
I wrote it so that the udev usage in xf86-input-evdev can be
replaced with more or less this:
devfd = open(devicenode, O_RDONLY);
if (devfd < 0)
goto out;
devpath = sysdev_devfd_to_syspath(devfd);
if (devpath) {
if (strstr(devpath, "LNXSYSTM"))
rc = TRUE;
free(devpath);
}
close(devfd);
out:
return rc;
I have not yet tested that, however.
It builds with "make" (no ./configure).
It will build and install into /usr/{bin,lib,include} by default.
On debian, devuan, and related distros, you will need to install with:
make LIBDIR="/usr/lib/$TRIPLET" install
On non-pure64 64-bit installs of other distros, you will need to set
LIBDIR to point to the appropriate directory (lib32 or lib64).
Before I fix that, I'd like some pointers on how to pick up the
right triplet on multiarch and the right libdir on multilib.
(as a shell snippet).
I want to add a .pc file for pkg-config; I've delayed that to get the
code out as soon as possible.
Comments, requests, patches welcome; flames to /dev/null.
Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] libsysdev preview
On Mon, Jan 19, 2015 at 04:05:46PM -0500, Jude Nelson wrote:
> Hey Isaac, this looks great! Starred and watched :)
Thanks!
> Related, I've just committed some (very) preliminary code for
> libudev-compat in the vdev repository that's meant to be both API and
> ABI-compatible with libudev. I think we're working towards the same
> end--make a library that can replace libudev but without depending on a
> specific device manager.
Glad to hear about this.
I note that udev supposedly uses/used libsysfs, in case that's useful
information.
udev exposes a *lot* of its internals.
> If you're interested, I have some sysfs-parsing code written and tested for
> vdev's Linux back-end, located here [1]. You might find it useful to
> libsysdev. It's available under either GPLv3+ or ISC.
>
> -Jude
>
> [1] https://github.com/jcnelson/vdev/blob/master/vdevd/os/linux.c
Thanks for the link.
Reading it over, it seems our purposes are roughly inverse:
vdev starts with DEVPATH, parses information, and spits out a device.
libsysdev starts with a device, finds something like DEVPATH, and spits
out either said path or information available there.
So far, the only information libsysdev gets is PCI ids, and as far as I
can see vdev mainly checks device type and uevent information.
I'm planning to add a little more code for the sake of easily finding
which input devices are what type, to aid in configuring X sans udev.
I've used Xfbdev and similar stuff, but often find myself wondering where
the keyboard is.
Now, a few comments/questions on your code:
* While the mechanism is clear for most of it, I find myself wondering
how vdev_linux_sysfs_read_device_mode() works.
If I'm following it correctly, you're just assuming that either
/sys/dev/char/%u:%u exists and it's a character device, or
/sys/dev/block/%u:%u exists and it's a block device.
This will break as soon as you hit /dev/ram*, since they have the same
major/minor numbers as /dev/{mem,kmsg,null,full,port,zero,random,urandom}
It seems that you can use the inodes from stat() instead.
* Is there some file explaining the overall architecture?
* What coding style are you using? While I've seen styles both more
and less legible, I haven't run across anything that uses that much
whitespace.
Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] libsysdev preview
On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote: > Regarding the architecture, I have a design document here: > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html Is this what > you're looking for? Or did you want a more low-level document describing > the implementation details? I was asking about implementation details (something like the HACKING document that many projects have, giving an overview of how it works internally). Being mainly acquainted with C, I might not be able to follow it myself, but it may well be useful for people who want to contribute. > Regarding whitespace, my style is based on Stroustrup's adaptation of K&R. > I add whitespace where I do because it helps me read code better and add > comments. Ah. I find that the Linux kernel style (also based on K&R) seems most clear to me; it seems quite different on the surface. (Styles are styles, though. There's always variation.) > Looking forward to seeing what you do with libsysdev :) I'm seriously > considering moving libudev-compat out of vdev entirely, and having it use > libsysdev as a backend (either way, I don't want it to be coupled to vdev). > I'm getting the impression that libsysdev won't really make a good backend for the udev API; libudev is a much more low-level interface, with somewhat different logical division and flow. (Abstractly, I'd be happy if it did work. But wasting time for the sake of promoting libsysdev isn't going to help replace udev.) Thanks for the comments! Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Announcing libsysdev 0.1.0
Hello all, Those who've been following the list in the last couple days may have seen some mention of libsysdev, a library that aims to provide an easy-to-use API to get information about devices from sysfs. It's available from git at: git://github.com/idunham/libsysdev.git I've just released libsysdev 0.1.0. Source code may be found at: https://github.com/idunham/libsysdev/archive/0.1.0.tar.gz (I'll have to tag releases using a different approach.) The license is a "0-clause BSD" license, meaning that you can do anything you want, without any conditions beyond what the laws of your country impose on all software. This new release exports 5 functions, features pkg-config/pkgconf support, has a small sample program at util/devinfo.c, and provides man pages for the library and the sample program (libsysdev.3 and util/devinfo.1). There's an initial port of xf86-input-evdev to libsysdev at: https://github.com/idunham/xf86-input-evdev Notes for packagers/builders: It's built with make (gnu make/freebsd-make/pmake should work equally well), configured only using variables that you can set on the command line. eg: make CFLAGS="-O2 -g0" CC=gcc make install LIBDIR=/usr/lib/i386-linux-gnu Other than LIBDIR and CFLAGS, the defaults should be suitable for a debian/devuan package. The header and docs can be shared by all arches. Release notes: Announcing libsysdev 0.1.0, the first public release. libsysdev is a library to get information about devices from sysfs. No daemons are required; it should be equally compatible with udev, mdev, and static /dev. Requirements are as follows: *libc supporting _XOPEN_SOURCE=700 or _XOPEN_SOURCE=600 + _ATFILE_SOURCE, and exposing major()/minor() with _BSD_SOURCE defined. *c89 or more current compiler. *Linux kernel, with sysfs mounted. Non-Linux systems don't use sysfs, so this won't work. sysfs was introduced in Linux 2.5.x. *pkg-config or pkgconf is recommended for development using libsysdev, but building with -lsysdev should work. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] libsysdev preview
On Thu, Jan 22, 2015 at 10:32:39AM -0500, Steve Litt wrote: > Cool Jude! > > As a member of the "minimum dependencies" crew, I just have to ask: > Would libsysdev, libdevq et al already be installed on a native Systemd > installation? It's important that vdev be easily installable, without > too much dependency hell. > > Please tell me when vdev is ready for testing on systems like > Manjaro-systemd and CentOS. I'll derive great satisfaction from further > incursions into Redhat's territory. Realistically, libsysdev will almost certainly not be preinstalled on a systemd based installation in the near future. It may well not be preinstalled *anywhere* for several months, if it does catch on. libsysdev is not intended to have any requirements beyond a libc that supports POSIX 2001 (_XOPEN_SOURCE=600) and _ATFILE_SOURCE. That is equivalent to POSIX 2008 (_XOPEN_SOURCE=700), and should be available since glibc 2.4 or in any version of musl. Yes, I'm in favor of minimal dependencies. If a command-line tool needs more than libc, I start wondering why. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Announcing libsysdev 0.1.0
On Wed, Jan 21, 2015 at 09:49:37PM -0500, Jude Nelson wrote: > Hey, this is cool! Looking forward to putting it to use in libudev-compat, > since it looks like I'll be needing a way to find a device file's sysfs > path. > Glad to hear that it will be useful. Is sysdev_devfd_to_syspath() or sysdev_getsyspath() optimal for you? Are there any adjustments to the API that would make it easier to use? Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] libsysdev preview
On Fri, Jan 23, 2015 at 10:57:39PM +0100, k...@aspodata.se wrote:
> Isaac Dunham:
> > On Sun, Jan 18, 2015 at 01:11:15PM +0100, k...@aspodata.se wrote:
> ...
> > > Mesa uses the name sysfs, which might be better than sysdev.
> > > The following two might be a good start:
> > >
> > > $ grep ^sysfs src/loader/loader.c
> > > sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
> > > sysfs_get_device_name_for_fd(int fd)
> > >
> > > and
> > >
> > > dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min)
> ...
> > Optimally, the API will be simple enough that developers then say
> > "And why aren't we using this *instead* of libudev?"
>
> If I get some time over I'd like to try replacing mesa's routines with
> libsysdev.
Mesa's internal --enable-sysfs is essentially equivalent to libsysdev.
(It was actually the inspiration for what I've written.)
> > There's a basic example at util/devinfo.c, and the header has comments
> > tersely explaining what inputs each function takes.
>
> devinfo doesn't handle partitions ?
>
> $ devinfo /dev/sda
> /sys//devices/pci:00/:00:13.1/:03:06.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/device
> $ devinfo /dev/sda1
> $
A partition has no "device" link; there's nothing you get from sysfs
besides "this is partition 'n', here's the alignment, here's where it
starts and ends, and by the way here's a bunch of stats about how much
use it's seen this boot".
The device link contains information like the driver in use, modalias,
model, vendor, and a whole bunch of other things; and everything I was
after was in the device link.
If it's meaningful, I can change this behavior; but that *will*
break the trick I mention -
cat `devinfo /dev/input/`/name
depends on going into .../device
Or I could add an option to just get the DEVPATH.
> > It builds with "make" (no ./configure).
> > It will build and install into /usr/{bin,lib,include} by default.
>
> You can use:
>
> PREFIX=/usr/local make
> PREFIX=/usr/local make install
>
> or similar to make it install in your preferred dir.
For what it's worth, I went to a bit of effort to ensure that PREFIX,
DESTDIR, LIBDIR, and so forth do not change anything before
"make install".
> > On debian, devuan, and related distros, you will need to install with:
> > make LIBDIR="/usr/lib/$TRIPLET" install
> > On non-pure64 64-bit installs of other distros, you will need to set
> > LIBDIR to point to the appropriate directory (lib32 or lib64).
>
> Works fine on a pure 32-bit debian.
Installing directly in /usr/lib will work, but for packaging multiarch
is important.
Thanks,
isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Boot loader?
On Fri, Jan 30, 2015 at 05:39:28PM -0500, Steve Litt wrote: > Hi all, > > Is it just me, or is Grub2 as complex and error prone as systemd? > > I'm wondering if we can have alternate boot loaders. > > SteveT Besides (e)lilo, there's (sys|ext|iso)linux and grub4dos-chenall. grub4dos is a superset of grub legacy: it supports boot from ntfs, loading a DOS kernel, and find --set-root among other things. The grub4dos maintainer said "GRUB2 does what I'm after, project retired", but someone involved in more Windows-oriented projects picked it up because grub2 is not a trivial update for many projects that use grub4dos. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Boot loader?
On Sat, Jan 31, 2015 at 12:59:51PM -0500, Neo Futur wrote: > going further than just grub, I think it could be good for devuan to > be the distro coming with different default packages, a few ideas : > > * grub/lilo as a default bootloader > * trinity ( great fork of kde3 ) as a default DE > * a grsecurity enabled kernel ? > * eudev or other udev alternative > * more generally always choosing the alternatives that are the most > respectful of users and unix philosophy, as defaults I will note that there is an interesting complication with grsecurity kernels: The X server needs to be able to read sysfs or else have a connection with a daemon that can, or drivers will not be properly loaded and configured. grsec has an option that makes sysfs and procfs unreadable except by root, so that X needs udev or must run as root. (If I recall correctly, non-root X is only possible with systemd or on openbsd, so that's a moot point for now.) > another idea to make devuan different : > > * shipping a server oriented flavour, with no DE as a default, a grsec > kernel as a default and only the packages needed for a server, that > could also be used as a minimal install, small download, that you can > later upgrade, add a DE . . . "No DE as a default": does this this mean not having GNOME/KDE but perhaps X11, (v)twm or similar, xutils/xapps, and xterm? Or does it mean no X? I presume it would include openssh and maybe a lightweight vim. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] fd leak in evdev patch (was: Re: Announcing libsysdev 0.1.0)
On Fri, Jan 30, 2015 at 08:46:13PM +0300, Jack L. Frost wrote: > On Wed, Jan 21, 2015 at 01:11:39PM -0800, Isaac Dunham wrote: > > I've just released libsysdev 0.1.0. > > Source code may be found at: > > https://github.com/idunham/libsysdev/archive/0.1.0.tar.gz > > (I'll have to tag releases using a different approach.) > > > > There's an initial port of xf86-input-evdev to libsysdev at: > > https://github.com/idunham/xf86-input-evdev (in the sysdev branch, once again) I looked over this again and noticed that there's an fd leak; I've pushed a fix for it, which seems to work here. > Packaged both for Arch: > https://git.fleshless.org/pkgbuilds/tree/libsysdev > https://git.fleshless.org/pkgbuilds/tree/xf86-input-evdev-libsysdev > > Did not test, so if anyone wants to, that'd be nice. Thanks! (Though I don't use Arch.) The point of the patch is that you can now use evdev without udev. By the way, I'm about to try sending this upstream (to xorg-devel). My main request to this list is please, don't bring the flames and complaints about udev over there. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Some downgrades may be needed e.g. cups Re: Towards systemd-free packages
On Tue, Feb 03, 2015 at 04:14:10PM +0100, Godefridus Daalmans wrote: > Hi, > > Jude Nelson posted an enormous rdepends list, of what packages would need to > be changed for Devuan Jessie,but from my own experimentation I concluded > that it wasn't so bad if we are willing to give up on a few other things: > > - Give up on GNOME for the moment > > - Accept that a few key packages may have to be kept somewhere *between* > Wheezy and Jessie for the moment, for example cups > > > Unfortunately I didn't accurately write down what I did myself.. so correct > me if I talk nonsense! > > but IIRC, I figured out that: > > - if I accepted an older version of CUPS (1.5.3-5+deb7u4 from Wheezy before > the dependency on libsystemd-daemon0) it would work, and also > > - there was some version of libudev0 or libudev1 (208-6??) which caused much > less hair-tearing than later versions. > Yes, I held that package. I think it's the only reason that xorg* depends on systemd. > From comparison of https://packages.debian.org/stable/admin/cups and > https://packages.debian.org/testing/admin/cups : > > Jessie cups = version 1.7.5-10 currently but I downgraded it to > 1.5.3-5+deb7u4, the Wheezy version. > > The new cups depends on cups-daemon which depends on libsystemd0 (did they > combine libsystemd-daemon0 with the other ones into libsystemd0 or > something?) All the libsystemd-* packages got merged, because they'd multiplied beyond being manageable. cups can be rebuilt without much patching, I think-alpine has cups 2.x working nicely, and systemd does't even build here. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Towards systemd-free packages
On Sun, Feb 08, 2015 at 11:08:24AM +, Jaromil wrote: > here the current thread on this > https://git.devuan.org/devuan/devuan-project/issues/6 > > Over the weekend I've assessed the first minimal group of packages, > processed them via the new Devuan SDK and committed them on our > packages-base git https://git.devuan.org/groups/packages-base > If you like to adopt maintainance of a package there, please open an > issue and I'll give you write access. The package-base repos will be > automatically pulled by our Jenkins, compiled and if succesful put into > the Devuan package repository, so all the work can be done here. > > About systemd extirpation: the real culprit is bsdutils, aka util-linux, > that Debian has tied to systemd because of the logger. What a paradox to > have 'bsdutils' bound to systemd however... > > I'm still in an early stage of development and haven't yet completed the > SDK with functions to test the installer, however this is my current > approach at cleaning up util-linux, touching as less as possible > https://git.devuan.org/packages-base/util-linux/commit/a51bce5830336af3c5ec9da6de95af926c1b1609 > > Once compiled and installed into a Devuan schroot, it allows to remove > libsystemd0 and then sysvinit gets installed automatically, without > warnings about removing a core component. My approach was slightly more minimal; the sample services can stay without a dependency. I've been running Debian with the patched bsdutils for a while, no problems and no systemd. (After holding udev, nothing else wants systemd.) > I'll let the dust settle now and look at Franco's push on the CI. > My next steps on the SDK will be update the documentation and work on > the installer and livecd baking mechanism. > > My guess now is that we'll have i386 and amd64 as available > architectures for a start and arm will come slightly later. Will mipsel come up sometime? I ask because ImgTech's Creator CI20 (dual-core JZ4780 mipsel32) ships with Debian Wheezy...and I've been thinking about getting one. ... As soon as you start populating the i386 repository, I'm ready to switch. If the packages build at all like they should, it will work; and if not, I've recovered this partition before from worse. ;-) Another package that our discussions seem to point at a reason for forking is busybox. Debian ships busybox with mdev and docs showing how to configure it, but there's no mdev package. I'm thinking there could be a package that installs /etc/init.d/mdev, /etc/mdev.conf, and the needed /sbin/mdev=>../bin/busybox symlink. Also, packages for busybox init and the bsdutils equivalents would be nice... I'm not sure how to handle the fact that busybox inittab is incompatible with sysvinit besides a conflict; yes, we could install them as alternatives, but then /sbin/init must be in sync with /etc/inittab. (I'd be willing to maintain busybox, if those changes are acceptable. I'm not sure I qualify to maintain anything, though--I live in Northern California, have never met anyone on the web of trust, and it's a pretty long trip to get to the Bay Area...the only thing I can point at is what I've put on github.) Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Raspberry Pi 2
On Tue, Feb 10, 2015 at 04:30:30AM -0500, Gravis wrote: > to my knowledge, cross compilation has minimal overhead. while having > native targets is good for testing, it won't have a significant impact > on compile time. It doesn't work on a majority of packages, as I understand (build scripts that rely on running compiled code, that don't respect CC, and many other causes.) You can use qemu, but that's generally ~80% CPU overhead. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Towards systemd-free packages
On Thu, Feb 12, 2015 at 09:27:10AM +, Jaromil wrote: > its sort of ready now, but as "I'm eating my own dogfood" (tm) I already > notice the staging workflow can be made better by creating different git > repositories for new versions of the same source, rather than different > branches. This because one can simply copy files between different repos > if they need to be merged, while with the branch approach the unit for > merging are commits and to have files out of them the commits must be > rebased and split (rather painful). You can use: $ git checkout -- ... (tree-ish can be a branch name, hash, tag, or any other reference form git understands). With the version of git in Jessie, this will checkout the files specified and add them to the stage. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] John Goerzen asks, "Has modern Linux lost its way?"
On Thu, Feb 12, 2015 at 09:42:07AM -0500, Steve Litt wrote:
> On Thu, 12 Feb 2015 11:25:46 +0100
> Didier Kryn wrote:
>
> > Same kind of dislike towards network-manager. This is the first
> > package I use to remove after installing Debian. The reason: I don't
> > know really what it does and how, but it goes in the middle of my
> > way. I am well off with ifplugd, wpa_supplicant and a roaming
> > configuration of wlan0.
>
> Didier,
>
> Please, please, PLEASE post instructions on how to do everything
> discussed in the preceding paragraph. I've had a lot of trouble
> replacing NetworkManager/Wicd with wpa_supplicant and iwlist, even
> though I know it's perfectly possible.
>
> If you could place these instructions on the web and let us know the
> URL, I know I'd be eternally grateful, and I bet I'm not alone.
I've done it myself, many times. But I don't have a website to point
you at.
I can provide an overview of how you do it, and some references.
(If you want to copy/extend/distribute this, please do so!)
OVERVIEW:
iwlist doesn't really work nicely with wpa_supplicant*; a better approach
is to create a minimal wpa_supplicant.conf that contains the line:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=networking
start wpa_supplicant (as root):
wpa_supplicant -Dwext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
then run "wpa_cli" (as root or any user in group "networking")
and at the prompt there enter:
> scan
> scan_results
Or use "wpa_cli scan; sleep 5; wpa_cli scan_results" where sleep is just
to wait for results from the scan to become available.
To configure wpa_supplicant to connect to an open network:
Append this to wpa_supplicant.conf:
network={
ssid="Private_SSID"
key_mgmt=NONE
}
For a WPA network "WPA_SSID":
wpa_passphrase "WPA_SSID" passphrase >>/etc/wpa_supplicant/wpa_supplicant.conf
For a WEP network "WEP_SSID":
network={
ssid="WEP_SSID"
key_mgmt=IEEE8021X
eap=MD5
wep_key0=ff
}
Add as many of these entries as you need to
/etc/wpa_supplicant/wpa_supplicant.conf; each network= stanza defines
an alternate network (or set of networks) to connect to.
After configuring wpa_supplicant, run
wpa_cli reconfigure
wpa_cli reassociate
#now check if you're connected:
wpa_cli status
You will now have to manually configure the interface; this may be
just running the dhcp client:
dhclient wlan0
Once you have wpa_supplicant running, you may want to add the proper
configuration to /etc/network/interfaces for future use:
# you may prefer to use "manual wlan0" and then add this to rc.local:
# ifup wlan0 &
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
*While iwlist gives you a list of SSIDs, it doesn't really clarify
whether an "encrypted" network is WPA or WEP. If you only need to use
WEP or open networks, iwlist and iwconfig are adequate.
SECURITY:
/etc/wpa_supplicant/wpa_supplicant.conf should be chmod o-rwx unless
you intend to let anyone with access to your computer read network
passwords.
Anyone in the group specified at the top of wpa_supplicant.conf will be
able to connect to wpa_supplicant and control it; you may wish to give
them g+rw access to wpa_supplicant.conf
(In the example the group is "networking".)
Internally, the way this works is that /var/run/wpa_supplicant/ is
chown root:$GROUP
and contains a series of sockets named for the interfaces controlled.
REFERENCES:
First off, the manpages you should be reading:
ifup(8), interfaces(5), wpa_supplicant.conf(5), wpa_supplicant(8),
wpa_cli(8), wpa_action(8), wpa_passphrase(8)
Links:
https://wiki.debian.org/WPA
https://wiki.debian.org/WiFi/HowToUse#Command_Line
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] John Goerzen asks, "Has modern Linux lost its way?"
On Thu, Feb 12, 2015 at 09:30:58AM -0500, Steve Litt wrote: > On Thu, 12 Feb 2015 07:33:51 +0200 > Martijn Dekkers wrote: > > > Whilst I am still utterly amazed with how awesome Linux servers are, I > > don't think we will ever get there with desktops. > > Just for fun, try Openbox with custom key-combos, including an easy to > hit key-combo to run dmenu. You might like to customize dmenu so its > menu displays down the screen instead of across the top (-L). Or just: apt-get install icewm Comes up and works *right* out of the box, though it might not look like everyone's first choice (the default theme is rather gray.) You can add shortcut keys in ~/.icewm/keys: key "Shift+Print" scrot -u -b key "Print" scrot And all the default keybindings are in the example preferences; there are plenty of features you might not know about: $ grep Tile ~/.icewm/preferences # KeySysTileVertical="Alt+Shift+F2" # KeySysTileHorizontal="Alt+Shift+F3" In other words, you can rearrange windows with alt+shift+F2-F5, move the top window to any corner you like with the keys bound to KeyWinArrange*, and so on...out of the box, no customization needed. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Nice feature for vdev
On Thu, Feb 12, 2015 at 09:50:08AM -0500, Steve Litt wrote: > Here's the source of this desire. I have bad eyesight. No matter how I > set VGA or console or whatever in Grub, when udev runs, it changes the > screen to a framebuffer with teensy-tiny fonts I can't read. Which > means all my virtual terminals end up with that same teensy-tiny font. What's happening is that udev autoloads modules, including the driver for the graphics card. If you don't want to blacklist the graphics driver (not recommended!), you can get console-setup, run dpkg-reconfigure, and you can set your font at 16x32 if you want. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Towards systemd-free packages
On Thu, Feb 12, 2015 at 08:21:26PM -0500, Rob Owens wrote: > On Fri, Feb 06, 2015 at 12:05:35AM +, Nuno Magalh?es wrote: > > Hi, > > > > On Tue, Feb 3, 2015 at 3:47 AM, Jude Nelson wrote: > > > Considering the dependencies on libsystemd0, libpam-systemd, libudev0, and > > > libudev1, I get: > > > > I don't see eudev or mdev in Debian's repos, are there any viable > > alternatives? > > > Debian does have udevil. I'm not sure if it's a complete replacement > for udev, but it allowed me to do USB automounting on Jessie without > systemd. Udevil is unmaintained upstream, as far as I know. udevil depends on libudev1, so it's not at all a replacement. mdev is in busybox. I've managed to bring up my system with it, but when I tried starting X I couldn't get the keyboard working. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] John Goerzen asks, "Has modern Linux lost its way?"
On Thu, Feb 12, 2015 at 10:01:15PM -0500, Gravis wrote: > install IceWM? but-but-but it's C++, so it's large and bloated, > right? right??? ???_??? Bloated? IceWM? Absolutely...*if* you're comparing it to twm, jwm, or a few other such window managers. Here, it's +3911k installed, including esound and ttf-dejavu-core. icewm itself is just under a megabyte, the session manager and background setter are each a quarter of that, and the tray is a bit shy of half a megabyte. It's written in C++ but does not depend on libstdc++, just X11, gdk-pixbuf, Xft, and optionally your choice of esd, alsa, or oss. jwm and mwm are just over 300k; vtwm is 532k + librplay; ctwm is over one and a half megs installed (+librplay); twm is 231k; herbstluftwm is 524k; fvwm1 is 702k, and the fvwm icons are 1.6 megs. Right now I'm actually using mwm, which was part of why I installed Jessie (the Lesstif->Motif transition). *box is written in C++ too. So what do you use? Yes, include the window manager, as well as the tray, menu, acpi/net/cpu monitor, dock, background setter, and key-binding tools as applicable. All of those are included in icewm (as well as virtual desktops). Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Towards systemd-free packages
On Fri, Feb 13, 2015 at 06:21:09PM +0300, Jack L. Frost wrote: > On Fri, Feb 13, 2015 at 06:10:40PM +0300, Jack L. Frost wrote: > > On Fri, Feb 13, 2015 at 01:59:48AM +0000, Isaac Dunham wrote: > > > mdev is in busybox. I've managed to bring up my system with it, but > > > when I tried starting X I couldn't get the keyboard working. > > > > That's because by default X tries to hotplug input devices with evdev. And > > evdev requires libudev. > > There is a evdev fork that works with libsysdev tho: > > https://github.com/idunham/xf86-input-evdev > > > > There's also a git repo documenting life with mdev on a desktop: > > https://github.com/slashbeast/mdev-like-a-boss > > >Isaac Dunham > Did I really just suggest a person's own project to them? :D Yup. It's OK, though. I tried running X with mdev several months ago, and somehow forgot about trying that with libsysdev. My experiments seemed to indicate that a udev-based X will not get any input devices when run without udev, so I tried specifying the input devices (mouse and keyboard) manually. I never figured out the keyboard, but I could probably find it now with devinfo. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] pre alpha valentine (secret love declaration)
On Sat, Feb 14, 2015 at 09:36:00PM +, Jaromil wrote: > > re all, > > Here is a pre-alpha sneak preview of Devuan at the current state of > affairs. It is my valentine to Franco: despite we probably never met in > person, I love him. He is really dedicated to this project and putting > hard work in it. I also fell in love with another VUA, whose name I > won't tell, but he is the one hosting the gitlab, running very well. > > > http://mirror.debianfork.org/devuan-jessie-i386-xfce-prealpha-valentine.iso > > http://mirror.debianfork.org/devuan-jessie-i386-xfce-prealpha-valentine.iso.asc > > http://mirror.debianfork.org/devuan-jessie-i386-xfce-prealpha-valentine.iso.sha > > do not use this in production, this is an internal preview (not even an > alpha) for the Devuan enthusiastic community and for those wondering if > we'll really make it: yes we will. I'm wondering what /etc/apt/sources.list looks like; I've tried pointing mine at deb http://packages.devuan.org/devuan jessie main but get: W: Failed to fetch http://packages.devuan.org/devuan/dists/jessie/InRelease Unable to find expected entry 'main/binary-i386/Packages' in Release file (Wrong sources.list entry or malformed file) W: Failed to fetch http:/packages.devuan.org/devuan/dists/jessie/Release.gpg Unable to connect to :http: W: Failed to fetch http:/packages.devuan.org/devuan/dists/jessie/main/source/Sources Unable to connect to :http: Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] successfully manually removing systemd and libsystemd0 from debian and still maintaining a working desktop
On Sun, Feb 15, 2015 at 05:49:54PM +, Luke Kenneth Casson Leighton wrote: > http://slashdot.org/submission/4203115/removing-libsystemd0-from-a-live-running-debian-system > > if anyone would like to help get the word out, as a way to actively > engage more developers and end-users to give them their right to > choose what software to run, please do consider hitting the "+" button > on the above submission. Done, I think. (I use NoScript, so...I guess the "+" button sticking means it worked...) Reading it I noticed "dbus, pulseaudio, policykit-1" - I only recompiled util-linux. Checked in Aptitude, and I don't have dbus installed. (I have libdbus installed, but not the dbus daemon, pulse, or policykit.) ... boot system into non-functional state due to udev not working? Huh? udev works fine for me (Debian Jessie). And I've rebuilt util-linux and removed libsystemd0 already. Or are you trying to remove udev as well? I start X manually, as you do. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] successfully manually removing systemd and libsystemd0 from debian and still maintaining a working desktop
On Sun, Feb 15, 2015 at 11:28:38PM +, Luke Kenneth Casson Leighton wrote: > On Sun, Feb 15, 2015 at 11:07 PM, Isaac Dunham wrote: > > On Sun, Feb 15, 2015 at 05:49:54PM +, Luke Kenneth Casson Leighton > > wrote: > >> http://slashdot.org/submission/4203115/removing-libsystemd0-from-a-live-running-debian-system > >> > >> if anyone would like to help get the word out, as a way to actively > >> engage more developers and end-users to give them their right to > >> choose what software to run, please do consider hitting the "+" button > >> on the above submission. > > > > Done, I think. (I use NoScript, so...I guess the "+" button sticking > > means it worked...) > > it's up and happily collecting comments. > > > Reading it I noticed "dbus, pulseaudio, policykit-1" - I only recompiled > > util-linux. Checked in Aptitude, and I don't have dbus installed. > > (I have libdbus installed, but not the dbus daemon, pulse, or policykit.) > .. > you are lucky :) i run a wide range of software as part of my > business so i have quite a bit more around. > > > boot system into non-functional state due to udev not working? > > Huh? udev works fine for me (Debian Jessie). > > bizarre! can you remember if, as a result of recompiling and > installing the util-linux packages, initrds were regenerated at all? > (it's done in a postinst hook somewhere) I don't remember. Actually...grepping /root/.bash_history, I see I only installed the bsdutils package (which is the only one depending on libsystemd). I would assume that means there was not regeneration at that point, but I've updated the other util-linux packages, udev, and the kernel since. I've also gotten my system to boot using mdev, but not to udev-less X. So I disabled mdev. The system in question is Jessie, downgraded from sid a couple months ago. (I enabled Jessie repos, apt-pinned at much higher priority, updated, let apt downgrade everything it wanted to, and disabled sid repos and the apt pinning.) It's new enough that I don't have an Xorg.conf. > > And I've rebuilt > > util-linux and removed libsystemd0 already. > > ohh, you are so lucky! can i add you to the list of successes? Sure, if you want to keep count. > > Or are you trying to remove udev as well? > > no i'm not - it just... the entire system froze on me at checking the > udev entries. but, at the time, i didn't have makedev installed. > > well... there may be hope then that i can actually get udev back up > and running. this would be good as sound is not coming out of the > speakers at the moment. volume's set, etc. etc. - just no sound. Does "alsactl init" do anything for you, by some chance? I just spent a day figuring out that that was what I needed to do, after I realized I didn't have sound on a several month old system. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] successfully manually removing systemd and libsystemd0 from debian and still maintaining a working desktop
On Sun, Feb 15, 2015 at 08:44:22PM +, Luke Leighton wrote:
> Gravis adaptivetime.com> writes:
>
> >
> > > * returning to manual keyboard and mouse configuration in Xorg
> >
> > where did it move to before?
>
> i never removed the manual keyboard and mouse configuration
> options that i had installed years back. however as xorg has
> grown more features, one of them included "automatic udev
> device detection", meaning that you *could* run with a
> completely blank (or even missing) xorg.conf.
>
> however, many people did not remove their old (manual) keyboard
> and mouse configuration sections, so what the xorg team did was
> to add an entry (which defaults to "on") "Use auto configuration".
>
> when this flag is set, any entries which use kbd or mouse drivers
> are COMPLETELY IGNORED.
>
> unfortunately, then, if you disable udev (which i did), xorg
> doesn't detect a mouse or keyboard - or in fact *ANY* input
> device - AT ALL.
>
> so, as documented in the document i wrote, you have to (a)
> set a flag to tell xorg to stop using auto-device detection
> and (b) return to the situation that everyone put up with
> before auto-device detection support was added.
Thanks to your write-up, I've gotten Xorg working sans udev
(actually, simulated via overmounting with tmpfs and running mdev).
FYI, *this* was why I included "devinfo" in libsysdev:
for d in /dev/input/*; do DEV="`devinfo $d`"; [ -e "$DEV/name" ] && { echo $d;
cat $DEV/name; } ; done
/dev/input/event0
AT Translated Set 2 keyboard
/dev/input/event1
Video Bus
/dev/input/event10
SynPS/2 Synaptics TouchPad
/dev/input/event2
Power Button
/dev/input/event3
Lid Switch
/dev/input/event4
Sleep Button
/dev/input/event5
Power Button
/dev/input/event6
HDA Digital PCBeep
/dev/input/event7
HDA Intel Mic
/dev/input/event8
HDA Intel Headphone
/dev/input/event9
Acer Crystal Eye webcam
/dev/input/mouse0
SynPS/2 Synaptics TouchPad
It makes it a whole lot simpler when you don't have to guess what a
device is.
The trick is that input devices have a description at
/sys/dev/char/:/device/name
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] About Devuan's audience
On Mon, Feb 16, 2015 at 02:44:04PM +0100, Didier Kryn wrote: > > 1) It is clear, by reading this list that part of us are mostly > concerned with servers. > > 2) I also read that there are people who want to truely own their > desktop. Some call them sentimentalists, but they are the people from and > for wich free software arised. > > To summarize, I see two populations in the audience of Devuan, with > slightly different motivations (I find myself in both): > 1) Servers' admins, who have professionnal concerns about security > and productivity and don't necessary care of the desktop, > 2) DIY (and FIY ;-) ) addicts who want whole control on their > desktop. I suppose I fit in #2; I've used Linux since 2006, which is by now over a third of my life, with my first Linux system being a secondhand Thinkpad running Ubuntu 6.06 Dapper Drake. Getting that to work nicely in 64 megabytes of RAM took a bit of work, but it paid off: it ran more nicely than the DEs I've tried on my current netbook. Since that point, I've built an LFS-ish system with an alternate libc. I can knock out a sysv-style init script (apart from the LSB headers) in a matter of minutes, without looking at the documentation. Yes, I know C well enough to write smallish tools, and if I wanted to I could probably get an overview of how systemd works internally-- after spending several weeks reading through it. ;) But shell scripts can be written well, and writing a shell script to solve a problem beats writing a custom config to handle how one tool does it, and then not being able to apply that to another platform... or an older version of the same distro. And so I would rather use something that *expects* shell scripts than something that tolerates them for "backwards compatability". And I'm certainly not interested in using a custom config because RedHat's employees can't understand how to write fast shell scripts. Why should I expect them to write efficient and safe C if they can't manage efficient and safe sh? "The price of reliability is the pursuit of the utmost simplicity." Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Question about properly splitting packages
Hello, I've got a question about how to split a library package so it works well with multiarch. The source package in question is libsysdev. When properly configured, it installs roughly the following files: /usr/lib/*/libsysdev.so.0.0 (and symlinks) /usr/lib/*/libsysdev.a /usr/lib/*/pkgconfig/libsysdev.pc /usr/bin/devinfo /usr/include/sysdev/libsysdev.h (this is not per-arch) /usr/share/doc/libsysdev/README /usr/share/doc/libsysdev/LICENSE /usr/share/man/man1/devinfo.1 /usr/share/man/man3/libsysdev.3 I'm guessing that it should be split so there are 5 packages (2 arch=all, 3 arch=any): arch=any: libsysdev depends: libsysdev-common (*.so.*) libsysdev-dev depends: libsysdev, libsysdev-common-dev (*.pc, *.a, *.so ->*.so.*) libsysdev-tools depends: libsysdev (/usr/bin, /usr/share/man/man1) arch=all: libsysdev-common (/usr/share/doc) libsysdev-common-dev (/usr/include, /usr/share/man/man3) In theory, this allows libsysdev-dev:i386 and libsysdev-dev:amd64 to be installed in parallel. Is this the proper way of splitting it? Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] pre alpha valentine (secret love declaration)
On Wed, Feb 18, 2015 at 12:06:58PM +0100, Svante Signell wrote: > Hi, anybody has an idea on how to fix this? > > On Mon, 2015-02-16 at 19:56 +0100, Svante Signell wrote: > > On Sun, 2015-02-15 at 00:17 +0100, Jaromil wrote: > > > On Sat, 14 Feb 2015, Isaac Dunham wrote: > > > > > > > I'm wondering what /etc/apt/sources.list looks like; I've tried pointing > > > > mine at > > > > deb http://packages.devuan.org/devuan jessie main > > > > > > that is not yet ready, thats why is called pre-alpha : ) > > > If I understand correctly, this ^^ means the repository indexes aren't being generated yet. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] WIP: mdev packaging
On Sun, Feb 15, 2015 at 04:27:55PM +, Luke Kenneth Casson Leighton wrote:
> http://lkcl.net/reports/removing_systemd_from_debian/
Somehow, this inspired me to poke at packaging mdev.
I don't have a website or apt repository atm, so I can't provide a deb.
But here's the source in git:
https://github.com/idunham/mdev
To build it, use "dpkg-buildpackage -b".
STATUS:
This provides hooks for mkinitramfs, and *can* create a working initrd.
There's an init script that's shipped along with it, and a fairly close
to standard Debian layout for /dev.
...At least, the result allows *me* to boot (/ on a SATA partition, no
separate mountpoints). Your mileage may vary; I would suggest *not* trying
this on your main install.
I have not tested this with dracut; it may well not work
There are helpers to create /dev/disk/by-{label,uuid}/ and other symlinks,
already set up.
It provides udev, because that was the only way to defeat the dependency
chain and make it work.
How to use:
If you don't have / on an unencrypted local partition, this may not work.
Also, *don't* do this on a production system!
Conventions: Lines that begin with a non-'#' should be done as non-root;
'^# ' should be done as root, '^##' are comments.
If you have X, you need to follow lkcl's guide to setting X up to work
without udev; then disable any scripts/configuration that autostarts
X11 for the first boot.
Re-enable it once you know it works.
git clone git://github.com/idunham/mdev
cd mdev
dpkg-buildpackage -b
cd ..
## busybox or busybox-static should work.
# apt-get install busybox
# dpkg -i mdev_0.6-1_all.deb
# apt-get purge udev
## this may not be needed (do it if you didn't get a new initramfs
## after purging udev)
# update-initramfs -u
And reboot.
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] WIP: mdev packaging
On Fri, Feb 20, 2015 at 04:30:17PM +, Luke Kenneth Casson Leighton wrote:
> On Fri, Feb 20, 2015 at 3:57 PM, Isaac Dunham wrote:
> > On Sun, Feb 15, 2015 at 04:27:55PM +, Luke Kenneth Casson Leighton
> > wrote:
> >> http://lkcl.net/reports/removing_systemd_from_debian/
> >
> > Somehow, this inspired me to poke at packaging mdev.
> > I don't have a website or apt repository atm, so I can't provide a deb.
>
> http://hands.com/~lkcl/mdev/
>
> unsigned.
Thanks!
> > But here's the source in git:
> >
> > https://github.com/idunham/mdev
> >
> > To build it, use "dpkg-buildpackage -b".
> >
> > STATUS:
> > This provides hooks for mkinitramfs, and *can* create a working initrd.
> > There's an init script that's shipped along with it, and a fairly close
> > to standard Debian layout for /dev.
>
> great!
>
> > It provides udev, because that was the only way to defeat the dependency
> > chain and make it work.
>
> i have no idea how to do that properly but... yeah "Provides: udev"
> sounds about right.
>
> the only thing i spotted is that the package built has "_all" in it -
> my understanding is that that's reserved for things that are
> architecture-independent. is mdev _definitely_
> architecture-independent?
This is along the same lines as udhcpc: it is a configuration package
for code that comes in busybox.
So this package is architecture-independent.
>>isaac i get "cannot stat /etc/modprobe.d/*" when doing
>>the update-initramfs -u, hope that's ok...
>>
>>SPLAT :) dozens of "unknown user/group root:root on line 20 ... about
>>100 of those...
Thanks for mentioning that error in update-initramfs, otherwise I'd have
no idea what's going on.
Obviously I need to include /etc/modprobe.d/something.conf, and change
move the "don't run with udev" logic from mdev-hook to mdev-{top,bottom}.
For those who want to try with the existing deb:
* remove not purge udev, or touch /etc/modprobe.d/empty.conf before
running update-initramfs.
Evidently, /etc/group and /etc/passwd did not get created.
This means that mdev-hook never finished, which means that udev was
still installed. In turn, that means that purging udev breaks
update-initramfs, presumably because /etc/modprobe.d/* goes away.
I should have a fix soon.
Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: Linux kernel and the force behind it
On Fri, Feb 20, 2015 at 12:42:43PM -0500, Gravis wrote: > > > CDE (common desktop environment) > > Not familiar with that. Is it related to Inferno? > > https://en.wikipedia.org/wiki/Common_Desktop_Environment That's it. By the way, it does work on Debian (though I'm not sure if the sysvinit script for dtlogin ever got fixed - I sent a replacement once, and someone else mentioned the bug at one point). The build/install process is rather convoluted, since make install doesn't work right. CDE was an Open Group project from about the time Novell gave them the UNIX trademark. Inferno has the most tenuous of connections to it, being a later Bell Labs project. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] WIP: mdev packaging
On Fri, Feb 20, 2015 at 06:21:27PM +, Luke Kenneth Casson Leighton wrote: > On Fri, Feb 20, 2015 at 6:04 PM, Isaac Dunham wrote: > > On Fri, Feb 20, 2015 at 04:30:17PM +, Luke Kenneth Casson Leighton > > wrote: > > > I should have a fix soon. > > awesome. And pushed. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] about mdev and udev
On Fri, Feb 20, 2015 at 09:08:56PM +0100, Godefridus Daalmans wrote: > About that error with the mdev packaging: > > if you purge udev, does that mean you need the old-fashioned /dev/MAKEDEV > script back to create the device nodes? > > it's in Debian package makedev. and it says Conflicts: udev, but that > doesn't mean it gets re-installed automagically after udev is purged, > unfortunately :-( mdev does not depend on makedev; it creates devices itself. HTH Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] WIP: mdev packaging
On Fri, Feb 20, 2015 at 07:09:28PM +, Luke Kenneth Casson Leighton wrote: > On Fri, Feb 20, 2015 at 7:02 PM, Isaac Dunham wrote: > > On Fri, Feb 20, 2015 at 06:21:27PM +, Luke Kenneth Casson Leighton > > wrote: > >> On Fri, Feb 20, 2015 at 6:04 PM, Isaac Dunham wrote: > >> > On Fri, Feb 20, 2015 at 04:30:17PM +, Luke Kenneth Casson Leighton > >> > wrote: > >> > >> > I should have a fix soon. > >> > >> awesome. > > > > And pushed. > > interesting... /etc/modules.d/* error goes away but still no > /etc/passwd or /etc/group file so still the same errors. both times i > had done an apt-purge udev followed by update-initramfs -u Now I'm lost. update-initramfs calls mkinitramfs which refreshes the initramfs, calling /usr/share/initramfs-tools/hooks/* . And /usr/share/initramfs-tools/hooks/mdev makes a stub /etc/passwd and copies /etc/group almost first thing. So in theory, that should not happen. I'm wondering what 'lsinitramfs /initrd.img' says is there--especially the contents of /etc, /sbin, and /scripts/, and what you get if you add a "mkinitramfs was here" type message to both ends of the mdev hook. I seem to recall there's some shell option you can set that shows the commands being run a la DOS ECHO on, but don't remember what it is. Setting that in the mdev hook then running update-initramfs -u may be the most useful approach. Also, is this Jessie or Sid (I used Jessie)? And does it work if you uninstall udev but don't purge it (which I believe is what I did)? Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] vdev status update
On Sun, Feb 22, 2015 at 08:00:58PM -0500, Jude Nelson wrote: > I consider vdev closer to being done than closer to having been just > started, and it's mature enough that early testers can start experimenting > with using it to boot Devuan in a VM (maybe even on real hardware, if > you're the adventurous type). Not only does it create all device files in > /dev that you'd expect, but also it set up and maintains the directories > and symlinks for: > * /dev/block > * /dev/char > * /dev/bus > * /dev/bsg > * /dev/cpu > * /dev/disk/by-id > * /dev/disk/by-uuid > * /dev/dri > * /dev/cdrom, /dev/cdrw, /dev/dvd, /dev/dvdrw > * /dev/input/by-path > * /dev/mapper > * /dev/net > * /dev/rtc > * /dev/snd/by-path > * /dev/v4l I had just been wondering how to set up /dev/disk/by-id; I have a helper for mdev that will set up /dev/disk/by-uuid/ and /dev/disk/by-label/ symlinks (by parsing the output of 'blkid'): https://github.com/idunham/mdev/blob/master/helpers/disk_link.sh It's released into the public domain via the unlicense. > === TODO === > There's still a few major shortcomings before I'm comfortable tagging an > alpha release, which I list below: > * vdevd needs an accompanying init script to mount devtmpfs and set up: > -- /dev/stdout > -- /dev/stderr > -- /dev/stdin > -- /dev/core > -- /dev/shm > -- /dev/MAKEDEV > -- /dev/fd > -- /dev/log > -- /dev/xconsole > -- and probably others ln -s /proc/kcore /dev/core ln -s /proc/self/fd /dev/fd ln -s /proc/self/fd/0 /dev/stdin ln -s /proc/self/fd/1 /dev/stdout ln -s /proc/self/fd/2 /dev/stderr # MAKEDEV is part of package makedevs; # it should be copied to /dev if it exists [ -x /sbin/MAKEDEV ] && cp /sbin/MAKEDEV /dev/MAKEDEV || \ ln -s /bin/true /dev/MAKEDEV /dev/log is the responsibity of the syslog implementation, which is not started by the device manager. /dev/xconsole is not something I have on my main (udev-based) partition - I think it's the result of running xconsole? /dev/shm is either a mountpoint for a tmpfs filesystem or a link to one. An old FHS-style system will do: mkdir /dev/shm && mount -t tmpfs shm /dev/shm On systemd-influenced systems, it's instead roughly: # in mountdevsubfs.sh, from initscripts mount -t tmpfs tmpfs /run mkdir -p /run/lock /run/shm mount -t tmpfs tmpfs /run/lock mount -t tmpfs tmpfs /run/shm #in udev, which runs before mountdevsubfs.sh mountpoint -q /dev/shm/ && umount /dev/shm/ mountpoint -q /dev/pts/ && umount /dev/pts/ #(re)mount /dev and populate it mkdir -p /dev/pts && mount -t devpts devpts /dev/pts #I'm not sure where this is. ln -s /run/shm /dev/shm HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] WIP: mdev packaging
On Fri, Feb 20, 2015 at 06:12:11PM +0100, Jaromil wrote: > > dear Isaac, > > On Fri, 20 Feb 2015, Isaac Dunham wrote: > > > On Sun, Feb 15, 2015 at 04:27:55PM +, Luke Kenneth Casson Leighton > > wrote: > > > http://lkcl.net/reports/removing_systemd_from_debian/ > > > > Somehow, this inspired me to poke at packaging mdev. > > I don't have a website or apt repository atm, so I can't provide a deb. > > But here's the source in git: > > > > https://github.com/idunham/mdev > > > > To build it, use "dpkg-buildpackage -b". > > if you like to use our CI system and apt repository, you are welcome. > > we can open an mdev project on our gitlab inside a new group for the > sort of projects like vdev and mdev, something called packages-nextgen, > there you'd be able to push mdev as a mirror in addition to your github > > the advantages for this would be multiple: you'd have continuous > integration on mdev and the correctly built packages would be ready to > use from the Devuan repository, making it much easier for people to test > and give you feedback. Thank you very much. That sounds nice. I'm curious whether this works nicely with debian-source-native packaging, like I'm using for mdev (everything including the packaging and source is in git master). I suppose I should also package libsysdev, since Jude was talking about using it for parts of libudev-compat. If you're wondering why I didn't respond sooner: lkcl and I were chasing down a bug, which turned out to be breakage with initramfs-tools from wheezy. I also didn't want the mdev package to be something that someone *could* install easily at that stage, since the only other person to try it got a boot failure; at a certain point, someone who isn't ready to build the package probably isn't ready to help test it. But now that lkcl has figured out how to fix the bug, I suppose it's ready for putting into an experimental repository. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] WIP: mdev packaging
On Tue, Feb 24, 2015 at 12:34:58AM +, Luke Kenneth Casson Leighton wrote: > dpkg-buildpackage -rfakeroot > ... > dpkg-source: error: can't build with source format '3.0 (native)': > native package version may not have a revision > > dpkg-buildpackage -rfakeroot -nc problem "goes away" > Just pushed 0.6.1; this is a native package, and I shouldn't have used 0.6-* (a/k/a "don't trust dch"). This update also adds several compat symlinks (/dev/std*, /dev/fd, /dev/core), a "Breaks:" for old initramfs-tools, and some fixes for disk_link.sh. Special thanks to lkcl for testing mdev so persistently. Thanks to Jude for reminding me about the symlinks. Thank you, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Important changes in Linux 3.20 (4.0?)
On Sun, Feb 15, 2015 at 11:40:06AM -0500, Hendrik Boom wrote: > On Sun, Feb 15, 2015 at 10:26:01AM -0500, Gravis wrote: > > > Kernel live patching makes KDBUS and systemD support mandatory! > > > > i'm weary of KDBUS but live patching is something i consider too dangerous. > > --Gravis > > But why would it have to depend on systemd? Erm...I'm reading that kdbus was *not* merged. FWIW, kdbus was specifically mentioned when Linus blacklisted Kay Sievers. V3 seems to have gotten a lot of "This needs a *lot* more documentation". Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] wicd & wpasupplicant (WAS: Re: three important UI features
On Tue, Feb 24, 2015 at 12:31:54PM -0500, Hendrik Boom wrote: > On Tue, Feb 24, 2015 at 05:06:47PM +0100, Didier Kryn wrote: > > > > > > I discovered the name of wicd on this list recently. I didn't > > try it, therefore I can't compare, but it looks that it has more > > diverse interfaces than wpasupplicant, CLI, GUI and even Curses. I > > will probably try it the first time I install Devuan on a laptop. > > > > I imagine neither wpasupplicant nor wicd will be infected by > > Systemd, and you'll have the choice between them. > > It's not entirely a choice. wicd depends on wicd-daemon, which depends > on wpa-supplicant. > > It looks as if, to some extent, wicd may constiture still more > interfaces to wpasupplicant, possibly with some state or smarts of its > own. AFAICT, anything that can connect to a WPA network on Linux depends on wpa_supplicant to do so. iwconfig can only handle open or WEP networks; I haven't been able to find out if iw can do WPA. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [philosophy] KISS, roots linux and the logo WAS Re: Dng Digest, Vol 5, Issue 11
On Tue, Feb 24, 2015 at 07:10:59PM -0500, Steve Litt wrote: > On Tue, 24 Feb 2015 10:27:23 -0500 > Hendrik Boom wrote: > > > On Tue, Feb 24, 2015 at 09:57:29AM -0500, Steve Litt wrote: > > > > > > If you're talking about Devuan, yes, it is! I got on the Devuan > > > mailing list just to escape systemd, and have been pleasantly > > > surprised by how Devuan is re-architecting everything. > > > > Does that meerly reflect how systemd is dearchitecting everything? > > Or are there things being rearchitected that aren't systemd issues? > > > > -- hendrik > > Well, first of all, understand the only Devuan I've run is Valentines, > and I didn't peer too deeply under the hood. My opinions come from > things the Devuan Developers say on this list. I've seen a replacement > for udev which, if I'm not mistaken, can simply be substituted for udev > or eudev. As far as I can tell, nothing's available *yet* that can *simply* be substituted for (e)udev. vdev is available and from what I understand should be able to provide what udev provides, but (a) I'm not sure what the status of libudev-compat is; (b) vdev doesn't have an init script or mkinitramfs integration yet; and (c) not all the compatability links are provided. As far as I know, that means that mount by label wouldn't work. mdev is available, but it has nothing available to provide libudev compatability at present; compatability links, an init script, and minimal mkinitramfs integration are provided, but you may need some hackery (equivs or repacking, plus manual configuration at a minimum) to replace udev with mdev if you have Xorg installed. Right now, I'm working on a redo of the /dev/disk/by-label links for mdev. (Parsing the default output of blkid safely is not trivial and obvious.) Once I test that, I plan to push it and modify vdev's disk.sh to handle /dev/disk/by-label/. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan Logo survey
On Thu, Feb 26, 2015 at 10:22:28PM +, Nuno Magalh??es wrote: > Prior to recent (at least in Debian) releases, Xorg came with the > classic checkered monochrome pattern, i'm cool with that :) > (Now it comes with a black background which is really moronic 'cos it > leaves me wondering "Did --configure barf or is this the root > window?"). I like the root weave too. If you want it back, use Xorg -retro or xsetroot -def. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] simple backgrounds
On Fri, Feb 27, 2015 at 06:13:24PM +, KatolaZ wrote: > On Fri, Feb 27, 2015 at 01:56:56PM +, Matthew Melton wrote: > > [cut] > > > > > > > Just to support my point, Debian has a great logo, but this is what is > > > currently happening to the users of Jessie, thanks to the > > > systemd-nonsense: > > > > > > https://lists.debian.org/debian-user/2015/02/msg00013.html > > > > Think they have found a solution after reading the followups. Reminds me > > that someone complained they couldn't terminate fdisk if started by systemd > > during boot. > > Might offer to help them...once I have stopped laughing of course. Ha ha. > > > > > > Well, I still find it hard to believe that a modern Unix OS might be > stuck at boot because I forgot to connect an ethernet cable... This is > the essence of the systemd-nonsense. In that case it was "just" a What baffles me is that Lennart *has* written a daemon specifically to *avoid* hung boots due to networks being down. It's called ifplugd. (And yes, if I used my ethernet port more often than the twice a year I now use it, I might want to use ifplugd. Unlike systemd, it's a single small daemon that just checks interface state and runs a script if it's connected.) Or, that might be the way Debian sets up networking as a dependency of remote-fs which is a dependency of the late-boot programs in /usr. I used to encounter similar problems when I had no wireless; fortunately, sysvinit proceeds after a timeout. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan Weekly News XI
On Fri, Feb 27, 2015 at 03:12:54PM -0500, Hendrik Boom wrote: > On Mon, Feb 23, 2015 at 07:22:26PM +0300, Jack L. Frost wrote: > > > Could you please cease ??kickass?? here -- for people read your news > > > also, but such rudness leaves them nothing but to shrink from your > > > writing. Thanks again for the news though. > > > > ???kickass??? is not even a swear word. > > I think we're seeing cultural differences here. What may not be a > swearword in one community may be in another. Over here, those who are more particular about such things consider "ass" to be a somewhat vulgar term when referring to the posterior rather than a male donkey (and "kick ass" refers to the aforesaid pportion of the anatomy). Not quite a swear word, but something to be avoided. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Init Freedom badges
On Wed, Mar 04, 2015 at 04:22:55AM +0700, ?? wrote: > ?? Fri, 27 Feb 2015 17:30:22 -0300 > hellekin ??: > > > > Awesome! As it is the planet-wide project, why make it necessary to > > > translate even logo into languages? - Let it be just graphical > > > stuff. > > > *** Why is everybody looking for the One Ring to Rule Them All? Can't > > we have unity through diversity? Are we all subject of Mordor's > > torpor and subjugation? > > Do not know what's Mordor is, but i think it will be hard to translate (Context for those who haven't read Tolkien; if you have, feel free to ignore.) In "The Lord of the Rings" (J.R.R. Tolkien), Mordor was the realm of Sauron, the lord of all the forces of evil. Sauron created a ring to enslave all the world, on which was engraved this verse/enchantment (actually a portion of a larger verse): One Ring to rule them all, one Ring to find them, One Ring to bring them all, and in the darkness bind them. If I understand correctly, the point of the allusion is that the quest for *one and only one* solution is not desireable. Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Tue, Mar 03, 2015 at 07:25:23AM +, KatolaZ wrote: > On Mon, Mar 02, 2015 at 04:35:24PM -0600, T.J. Duchene wrote: > > When you code in Perl, you are using subroutines and libraries that > > were incorporated into Perl core.The fact you are calling an > > entire subroutine when you "split" strings in Perl is no different > > than having a C string library. You call the library to do the > > work. You don't care how it does it, only that you get the results. > > C gets a bad reputation because a percentage of programmers never > > learned how to prevent buffer overflows or leaks is all. That is > > certainly not C's fault. > > > > And I can mantion dozens of counterexamples in which Perl or Python > would solve the task more easily than C. Just to give you an idea, I > have been doing quite a bit of XML parsing, mainly to convert data > sets of all sorts in a reasonable (ASCII) format. Well, I have done it > both in C and Python, so I think I can make a fair comparison between > the two *for this particular task* and for *my specific needs*. > > Usually the C implementation of a non-trivial XML parser might require > a couple of days to be finished and be able to digest the whole schema > (you have to construct the data structure piece by piece, and to pass > around a lot of garbage, and to be sure that you don't have leaks > anywhere, and to catch and handle errors by hand...). Conversely, the > Python implementation is usually ready in less than two hours, Are you using expat for the C implementation, like you are for Python behind the scenes? python-stdlib requires expat, BDB 5.3, bz2, ncurses, readline, sqlite, and openssl, along with FFI, terminfo, and mime-support. However, I recognize you probably won't get C done in less than 2 hours like you do with Python. I will say that it sometimes seems like the reason leaks are a problem in C specifically is that leaks aren't considered a problem in other languages. Sure, gc-based languages eventually collect the garbage. But they seem to take a long time to do it. And they encourage a sloppy approach where acquiring a resource is not habitually matched with releasing it. And exceptions can at times be more obscure and verbose than checking return values: something three imports deep could throw an exception you never thought about, and it may propagate. Now, I've used Python a little bit, and I've used C a little bit. I won't say that Python/$scripting_language "should not be used, period". But there are a lot of the features that come at costs that sometimes seem to be ignored. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Plan for Devuan to use Mozilla products as is
On Fri, Mar 06, 2015 at 08:44:31PM +0100, Stefan Ott wrote: > On 03/06/2015 08:06 PM, T.J. Duchene wrote: > > > > That said, the reason I suggested Chromium as an alternative to > > Firefox is that essentially a better piece of software. It has > > better features, better support for Web standards, and it is more > > actively maintained. > And then there is the thing where Debian had to EOL chromium early > because there is no security support and the latest version cannot be > built on Debian stable anymore [1], recommending their users "to > switch to the iceweasel web browser". > > Personally I think the last point alone makes Firefox the better > choice for a default browser -- we wouldn't want our users to suddenly > find themselves without security updates... > > [1] https://lists.debian.org/debian-security-announce/2015/msg00031.html I think ^THIS is probably the biggest reason not to use Chromium. Never mind whether it's affiliated with Google or whether that makes it untrustworthy. If you can't keep it updated for the full lifetime of the release, it could be written by the most trustworthy vendor on Earth and it still wouldn't qualify for a good default. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Plan for Devuan to use Mozilla products as is
On Sat, Mar 07, 2015 at 02:19:43PM -0600, T.J. Duchene wrote: > > > >> https://lists.debian.org/debian-security-announce/2015/msg00031.html > > >I think ^THIS is probably the biggest reason not to use Chromium. > > >Never mind whether it's affiliated with Google or whether that makes it > untrustworthy. > >If you can't keep it updated for the full lifetime of the release, it could > be written by the most trustworthy vendor on Earth and it still wouldn't > qualify for a good default. > > Hi, Isaac! > > That seems very strange to me. I see no reason why they cannot backport > patches to the Wheezy version of Chromium. Debian has been doing that since > day one on other packages. Any upstream project could change the build > environment could happen to any project, at any time. > > Debian has never demanded that an upstream project stay the same for their > convenience before now. The fact that Debian chose to stop building updates > for that reason shows a lack of commitment to Wheezy. Unless there is > something I don't know about - It's not that they can't use or generate a > patch. They simply won't. > > t.j. Iceweasel and Chromium are both updated to the upstream-supported version periodically (when the current version is no longer supported). The amount of churn between versions and the number of versions means that it would be very difficult to backport patches. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] The quote of the year
On Thu, Mar 12, 2015 at 06:01:41PM -0400, Steve Litt wrote: > Hi all, > > I just ran across the following quote, which I think the dng people > will appreciate: > > > I'm done with my desktop being someone else's research project. > > > http://www.jwz.org/blog/2011/10/has-gnome-3-decided-that-people-shouldnt-want-screen-savers/ Over three years old, and so much of it is still true. The window managers I use I don't expect to change that much (I'm using icewm, fvwm1, and mwm), and the one desktop environment I use is certainly not going to go for the "rewrite it for fun, and what can we break today?" approach. After all, I use CDE. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Fri, Mar 20, 2015 at 04:01:28PM -0400, Steve Litt wrote: > On Fri, 20 Mar 2015 09:40:43 -1000 > Joel Roth wrote: > > > Steve Litt wrote: > > > What would especially float my boat, once there's a truly > > > depoetterized Devuan, is to have the package manager warn me at 160 > > > decibles if I decide to install something that pulls in any systemd > > > code, because if there's a way to run without systemd code, that's > > > how I want to run, even if it means someday I can no longer use > > > Gnumeric or Gimp. > > > > > > Let me give an analogy that's absolutely offtopic here, I use it > > > only as an analogy. Three years ago, I made a policy that no KDE > > > library or software would ever exist on any of Troubleshooters.Com > > > computers, any computers owned by Steve Litt, or any computers > > > owned by family members who expected me to be their IT department. > > > For the most part, I simply never install a package beginning with > > > "k". But once in a while I install an excellent sounding package, > > > only to see it starting to pull in KDE Krap, have to Ctrl+C out of > > > it, and then go back and painstakingly remove everything my install > > > put there. My life would have been easier if the package manager > > > told me THIS PACKAGE HAS KDE REQUIREMENTS, PROCEED N/y. > In the case of Devuan, systemd is a special case, indeed, the reason > for Devuan's existance, so I think a no brainer, idiot lite solution > would be appropriate for systemd, so that even those, like me, who know > nothing but "apt-get install great_sounding_app" get warned. printf '\n\nPackage: libsystemd*\nPin: origin *\nPin-Priority: -1\n' \ >> /etc/apt/preferences printf '\n\nPackage: systemd\nPin: origin *\nPin-Priority: -1\n' \ >> /etc/apt/preferences You're welcome. Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Puppy Linux-related thoughts
On Sun, Mar 22, 2015 at 11:24:03PM -0400, Apollia wrote: > > Regarding desktops - perhaps Puppy Linux might be a good place to look for > some inspiration? http://en.wikipedia.org/wiki/Puppy_Linux > > So small, light, fast, and relatively easy to use, even for total Linux > newbies. Ah yes, Puppy Linux. I've used that a lot. (Most of) the standard ingredients are an apt-get away; it's usually jwm, rxvt-unicode, mhwaveedit, geany, abiword, gnumeric, ... Partly it's looking for lightweight applications, partly it's avoiding duplicates (though there are a few of those!), and partly it's the window manager and related details. In a standard Puppy, there is no Python; I'm not sure if Perl is stock, either. > I have to admit, some of the default out-of-the-box settings of most any > Puppy Linux I've tried annoy the heck out of me, like having to > single-click instead of double-click to open things. > > But the software preinstalled in them is often quite nice and well-chosen, > and many quickly became favorites of mine. (Geany, NoteCase, mtPaint, > Viewnior, etc...) > > And most Puppy Linuxes I've tried make it very easy to get on the internet, > something I recall usually being difficult to do back in 2011 when I was a > Windows XP user trying various Linux live discs. Last I knew, there were at least 3 network managers that were puppy-specific (Simple Network Scanner, Frisbee, PeasyWifi...and maybe clinet from pupngo counts also). All the standard ones are written in shellscript + gtkdialog. Even though there's an icon for the terminal right on the desktop, the Puppy Linux developers work on the assumption that you should never *need* to open it to get things working. > I've also increasingly been considering trying to build my own Linux from > scratch, probably using this website as a guide: > http://www.linuxfromscratch.org/ If you want a short build, look at Bootstrap Linux or ELFS: https://github.com/pikhq/bootstrap-linux http://kanj.github.io/elfs/book/ (and clfs-embedded is simple too, but it's harder to get.) As a rule of thumb, before you try building a Linux system from scratch you should make sure you can configure a kernel that works for your hardware. Spoiler: "make localmodconfig" and "make localyesconfig" are your friends. > Another good thing about Puppy Linux is that it's one of the major holdouts > against adopting systemd, according to this blog post by Barry Kauler, the > creator of Puppy Linux: > > http://bkhome.org/news/?viewDetailed=00114 > > > One of my favorite things about Puppy Linux is the fact that the entire > operating system can be loaded into RAM, which helps make things very fast. This requires stripping everything down as small as possible, choosing small programs, and so on. > Another of my favorite things is that I don't have to even have the OS > installed on my hard disk, and thus I don't have to worry that I might > accidentally break my entire system and have to reinstall everything from > scratch just because of installing (or doing) the wrong thing. This is due to the use of squashfs and aufs (Another Union Filesystem). squashfs is a compressed archive with a readonly "driver" in the kernel. Union filesystems, in general, create a "filesystem" by layering multiple mounts. A Pupsave file is a file containing a ext* filesystem that gets mounted as the top layer of a union filesystem, over an SFS layer. > Another type of Puppy installation is a "full installation". If I'm not > mistaken, the difference between a Puppy full installation and a Puppy > frugal installation (with a Pupsave file) is, I think a full installation > isn't loaded into RAM, and changed files get saved to disk immediately, > rather than being saved to a Pupsave file after a delay and either > automatically and periodically, or upon the user's request. A full install is a classic Linux install, with no layers and no SFS. > (With a frugal installation without a Pupsave file, nothing gets saved, and > you just get asked at shutdown whether you want to create a Pupsave file, > and you're able to refuse to create one.) > > I believe a frugal installation + a Pupsave file is probably the most > frequently recommended way of doing things - but a full installation might > in some circumstances be better, such as on a system with too little RAM to > comfortably load the entire operating system into RAM. > > > Anyway, I haven't yet heard of anyone else using a similar approach to the > way I run Linux - always booting my system from scratch with a default > Puppy Linux frugal installation with no Pupsave file, and then running my > Puppy Linux Setup Kit to install all of my
Re: [Dng] Puppy Linux, AntiX - was Re: Puppy Linux-related thoughts
On Wed, Mar 25, 2015 at 09:20:53AM -0400, Hendrik Boom wrote: > On Wed, Mar 25, 2015 at 05:56:34AM +0200, Martijn Dekkers wrote: > > There are no significant *security* implications when running as root if > > you mostly use linux as a server OS. Simply banging "sudo" in from of most > > of your commands doesn't help you at all when it comes to security. There > > is a small benefit in not having the root account having a password, in the > > sense that everybody knows that there must be a root account on your > > machine, so that becomes an immediate target for every cracker with a > > rainbow table and some sort of shell access. > > Are there any drawbacks to naming the root account something other > than 'root'? Perhaps by editing /etc/password and /etc/shadow? And, of > course, renaming /root correspondingly? Mainly that some software (a few shell scripts for the most part) checks for root via a string comparison of "$USER" with "root", which is of course utterly wrong. And some scripts or such might use "su root" or similar things that explicitly use the root account. But on the whole it "Should Work Fine" (TM); no warranty provided and if you do it, you're on your own. ;-) HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Fri, Mar 27, 2015 at 11:29:53PM +0100, marc wrote:
> And maybe even:
>
> - minimising the size and dependency graph of the essential
> system. I have had friends worry that the base Debian seems
> to have been growing each year so that it doesn't fit onto
> small/embedded systems anymore. For anybody who has tried
> to build a distribution from scratch particularly for a
> new architecture or just platform (a really instructive
> exercise), a small core lets one get to a running system
> quickly (the first big win), and then a self-hosting system
> (the real win). Beyond these points the nonessential stuff
> can depend on arbitrary things, but getting the core up
> and running is critical for a free distribution to support
> new/unconventional platforms, or to serve as base for other
> distributions or appliances. The downside is that somebody's
> favourite scripting language isn't essential - but it is
> still there ... it just not used in the core.
>
> Maybe visualise this as a well-formed tree, with the kernel, libc,
> compiler, shell and shell utilities forming the trunk and then only
> at some meters above ground things branching into complex
> dependencies ...
The core of the command-line tools can be found thus:
dpkg-query -W --showformat='${Package}\t${Essential}\n'|grep yes
And here that's 25 lines long.
But it includes 2 shells, Perl, util-linux and a host of GNU utilities,
and requires at least 25 libraries.
util-linux builds some dozen packages) and pam seem to be the biggest
sources of proliferation in the base system.
But this comment reminds me of Aboriginal Linux:
http://landley.net/aboriginal/
and Bootstrap Linux:
https://github.com/pikhq/bootstrap-linux
(You can build a self-hosting system in six packages, if you choose the
right ones.)
Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Why daemontools is so cool
On Sat, Mar 28, 2015 at 02:52:47PM +0100, poitr pogo wrote: (in response to the question of why s6 "prevents daemonizing") > Cannot. This is from the s6 docs. I'm not using s6. Just heard about it today. If you want to *manage* a daemon (ie, do something when it stops, like restarting it), it's very tricky to do it reliably without having a fixed PID; "daemonizing" means close stdin/stdout/stderr, then if (fork()) exit(0); or some such thing (in other words, create a new process and exit the old one), so you do not have a fixed PID. On Linux, BSD, and older UNIX versions, this can be done thus: daemon(0,0); > Another s6 limitation - finish script must end in 3 seconds. or will be > killed. > Nice for desktop, not a server. sysvinit /etc/init.d/sendsigs actually only allows 1 second. > It used to be that an application is responsible for proper start > up/shutdown procedure, as application knows the proper way how to do > it. Init script is just a place where to hook a startup/shutdown > script to be executed when system needs to start/stop application in > some automatic way. > Now there are tools which help deamonize things. > Depending how portable they are it make the price one has to pay when > decides to use them instead of handling this yourself in the > application. My understanding is that s6 and some of the equivalent packages, such as daemontools, are fairly portable. They are generally not used as a way to offload daemonizing, but as a way to ensure that a service stays started. If you don't need that, you don't need them. > Regards > piotr Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Any plans to provide xinit without the systemd hacks?
startx always used to start a new X server on a new TTY; now it starts on the current vt. This is the result of a block of code in startx that forces "vtarg" to the equivalent of `tty`. The sole reason for this is that logind gets confused when something opens on a new vt. Will Devuan include an xinit package that doesn't do this? Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Why daemontools is so cool
On Mon, Mar 30, 2015 at 08:54:42PM +0200, devuan...@spamgourmet.net wrote: > Hi Steve, > > On Mon, Mar 30, 2015 at 7:24 PM, Steve Litt - > sl...@troubleshooters.com > wrote: > > Hi Didier, > > > > If your post says what I think it says, you're saying that modern init > > systems should always start services concurrently, not consecutively. > > > > Certainly that's a good thing, and we're working toward it, but it's > > important to keep some perspective on the matter and do a cost/benefit > > analysis on the alternatives. > > > > On my experimental Manjaro machine, systemd, which most would agree is > > very concurrent, booted in 4 seconds. Epoch, which has absolutely no > > concurrency at all and boots completely consecutively, booted in 8 > > seconds. How much complexity, how much indeterminacy, are we willing to > > put up with to get A) 4 more seconds in our life every time we reboot, > > and B) do it the more "modern" way? > > How fast is epoch when you throw it at a generic piece of hardware > that you did not hand-tune it for? > > The problem there is that a consecutive boot system needs to probe for > hardware and give that hardware time to show up, blocking the boot > process in the meantime. If you have lots of hardware you need to > probe for (as e.g. Devuan would need to out-of-the-box), then those > wait-times can sum up really fast. And some hardware can take a very > long time to register, so you need to be generous with those > time-outs. On the other hand anybody without the hardware will stuck > for the entire timeout, so you need to keep them as short as possible. Probing for hardware is not done how you seem to think it is. There isn't some "magic list" that you go down and blindly check if it's there. Instead, there's a process where the kernel discovers the hardware, saves a record of each piece in /sys (the "uevent" and "modalias" files), and starts the hotplug helper or sends a message via netlink. Then, the hotplug helper/netlink daemon (hotplug, mdev, or udev) will parse that information and load firmware/modules or create a device. Practically speaking, I think the only person on the list who doesn't have their initscripts probe for new hardware every boot is the other Karl (the one who uses a static /dev). udev and mdev probe for new hardware every boot. And it takes a couple seconds *here*, on an Atom N270-based system. I've heard of people trying to make that parallel, but it typically resulted in slower boots or unusable systems. > > By the way, one excellent thing about the Epoch init system is that, > > because it's completely consecutive, you can get a close look at which > > services are taking too long to start, troubleshoot them to find the > > bottleneck, and fix them, so that they'll start efficiently in your > > concurrent init. The quicker everything starts in a concurrent init, the > > less chance for race conditions. > > Yes and no. > > What happens if your filesystem has a slow day (e.g. due to some f*ing > RAID controller deciding that it needs to do some extra sanity > checks)? That will lead to the consecutive boot system panicking since > its root device is not there (after some timeout), which in turn will > lead to some poor admin having to investigate and nudge the server to > try once more. If your root filesystem has a slow day, you won't have /sbin/init running: that happens after initramfs has finished (and initramfs is fairly serial). Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Any plans to provide xinit without the systemd hacks?
On Tue, Mar 31, 2015 at 10:14:17AM +0200, Jaromil wrote:
> On Tue, 31 Mar 2015, Jude Nelson wrote:
>
> >Hey Isaac,
> >So, I'm looking at startx here:
> >*[1]http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp
> >Where's the offending block of code?* Is it lines 191-200?
>
> Looks like it.
>
Yes.
Debian packaging is at:
git://anonscm.debian.org/pkg-xorg/app/xinit
Maybe
---a/startx.cpp
+++b/startx.cpp
-#ifdef __linux__
+#if defined(__linux__) && defined(HAVE_SYSTEMD)
and add a stanza to configure.ac that will check for presence of the
systemd development stuff OR --with-systemd, and if detected will add
-DHAVE_SYSTEMD to CPP_FILES_FLAGS.
(I could probably add that and see if upstream will take it...)
Or, perhaps it would be better to add a runtime check such that if logind
is running, that stuff happens.
> >Looking at the commit history
> >([2]http://cgit.freedesktop.org/xorg/app/xinit/log/), it doesn't
> >look like startx sees many changes these days.* It should be easy
> >to keep a separate startx script around, if you don't want it
> >starting X on your current tty.
>
> I think we should satisfy Isaac's request. I stopped using startx long
> ago, but I'd be also annoyed to have it starting on the launched tty,
> clearly recalling I did use startx in place of xinit mostly to not have
> it polluted.
>
> I also cannot understand the sense of this somewhat insane thing
> http://cgit.freedesktop.org/xorg/app/xinit/tree/cpprules.in
> And would feel much better to know that we maintain such a script, or
> even rewrite it.
It's a snippet of makefile, presumably included somehow or other. The
logic there seems obvious to me:
sed rules: delete lines begining with "# " and a number, or "#line"
directives; change XCOMM/XHASH to # (as imake does); and apparently
change "@@$$" to "\".
SUFFIXES and below:
let "make filename" create filename from filename.cpp by running this:
cpp ${TRADITIONALCPPFLAGS} ${CPP_FILES_FLAGS} filename.cpp | \
sed -e >filename
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan Weekly News XVII - Where no toy has gone before
On Tue, Mar 31, 2015 at 09:15:23AM -0400, etech3 wrote: > # Devuan Weekly News Issue XVII > > __Volume 02, Week 12, Devuan Week 17__ > ### [Puppy Linux-related thoughts...][4] > > Isaac Dunham started a post that there may be some guidelines from Puppy > Linux for building a small, lightweight, fast, and relatively easy to use > system, even for total Linux newbies. Includes a link to distrowatch.com on > an antiX Jessie beta without systemd. > > Apollia had a related post about Gobo Linux, Puppy [Linux.][5] Correction: Apollia was the first one to mention Puppy Linux; I replied to Apollia's email. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Freedom Logo
On Tue, Mar 31, 2015 at 10:38:59PM +0200, Svarog wrote: > Hi all, > I uploaded a different version: > http://without-systemd.org/wiki/index.php/File:Devuan_Freedom_blue1.png > > Kind Regards, > kvasny That looks nice! (yes, that's including the color) Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What about pulseaudio, avahi, ... ?
On Wed, Apr 01, 2015 at 10:06:13PM +0200, Patrick Erdmann wrote: > In my experience pulse should be optional. It works. Not good but it > does what its made for (after years of development). But avahi is > unstable... Does not work for me. I often had this problem: Network was > not reachable, because of avahi. I've never had that experience myself. I've had a (DHCP-connected) network printer that I had to specify the IP for manually when I removed avahi (yes, that's a dangerous thing to do; but we had all of 192.168.*.* and maybe six network devices connected to a WRT54G router, so there wasn't a collision). On the other hand, I've also had avahi cause a kernel panic, apparently triggered by a printer. That was with Ubuntu "Lucid", right around release (it could have been before release, since I tested that one). Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] What about pulseaudio, avahi, ... ?
On Thu, Apr 02, 2015 at 09:27:36AM -1000, Joel Roth wrote: > On Thu, Apr 02, 2015 at 07:28:27PM +0200, Stephan Seitz wrote: > > On Thu, Apr 02, 2015 at 07:15:38AM -1000, Joel Roth wrote: > > >On my system, reverse depends for pulseaudio shows such > > >packages as mpg123, which shouldn't have an opinion about > > > > But mpg123 neither depends on nor recommends pulseaudio. It only suggests > > pulseaudio together with jackd, alsa-utils and other packages. > > Yes that is only a "suggests" relationship, so not a > good example. Funny tho, it shows up as a reverse depends > listed by apt-cache showpkg. > > initramfs-tools-tcos, OTOH, recommends pulseaudio. For what it's worth, this makes sense to me. (Not that I like Pulse!) initramfs-tools-tcos is about setting up an initramfs for a thin client... which means that any audio programs will be running on the server, while the user is at the thinclient. In order for the user to get sound, they will need to have pulseaudio or another network sound daemon running, and NAS isn't really active anymore. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan's release date ?
On Sun, Apr 05, 2015 at 06:41:48PM +, Arnt Gulbrandsen wrote: > When I looked, devuan.org said neither that there are ISOs or that there are > apt-get repos. Admittedly that was not exactly this week. I need > documentation for... well, finding and using those two. Minimal network > install preferred. > > Arnt On one of my installs I included this in sources.list: deb http://packages.devuan.org/devuan jessie main deb-src http://packages.devuan.org/devuan jessie main I'm not sure what other dists actually work. but you can look here for examples: http://packages.devuan.org/devuan/dists/ HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Too many man pages, too much complicated : systemd
On Sun, Apr 05, 2015 at 07:52:32PM -0400, Jude Nelson wrote: > If I ever write a desktop suite, it will store settings as a well-defined > directory tree with human-meaningful file names and contents instead of a > MySQL database or a large flat opaque file. The only desktop I use does. Yes, I use CDE. Thanks, Isaac ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Too many man pages, too much complicated : systemd
On Mon, Apr 06, 2015 at 09:38:06AM +0100, KatolaZ wrote: > What really puzzles me is why if you love systemd that much you just > continue arguing about systemd on the ML of a Debian fork specifically > born to throw systemd away. Do you think you might be able to convince > us that systemd is *good* and *beautiful* and *necessary*? I don't > want to be saved, thanks ;) All I see T.J. saying is that systemd (1) implements some good ideas and (2) has done so in a way that is flawed in *certain* aspects, but (3) not in *other* aspects. And I suppose I agree with that. An init system that can collect *all* the descendents of a service is a nice concept. So is having a dependency-based boot that can respond to events, without treating "this dependency became available" as an event in its own right. And I suppose that knowing when service x becomes available, and when it goes away, can be nice...as is knowing that service x will keep running until the sysadmin stops it. But does that entail a release schedule such that the version number has increased by nearly 200 in 5 years, or a library to interface with that same package? Does it call for writing a new service to handle fdisk, another one to handle networking, another to handle the boot splash, and so on? Why should an init system implement an SNTP daemon, or its own DNS server, and what excuse is there for reinventing cache poisoning? I've heard comments about systemd being spaghetti-code. No, it's not: it's spaghetti-architecture, but the bits and pieces looked fairly clear. I *wish* busybox were that well-written. It's what they require and how they're combined that's problematic. I use musl libc on many of my installs, because I like having a libc that's simple to read, to enhance, to fix, to build, and to install, and that respects the bounds of its scope and keeps code and binary size down. systemd doesn't complement that, because it's an *boot* system that takes half a million lines of code to cover "booting the system". Note that I didn't call it an *init* system, because that is obviously not the scope that they accept. It doesn't work with musl, in small part because they decided to require secure_getenv() which is synonymous with if (issetugid()) getenv(var); but also because of extensive reliance on "how glibc does it"-- which may actually be undefined or nonstandard behavior that could change (for examples, note the flash breakage thanks to the memcpy() rewrite, and check the history of glibc getenv()). When people have enquired about making it work with uclibc, the developers responded with something that sounded a lot like "maybe, *if* it's not much different and you do the work". It requires util-linux and its libraries, and libkmod, and its own device manager, and libraries for crypto and compression, and it tries to provide a boot manager that's worthless for me (I use BIOS-based systems). Here, I use toybox/busybox because it covers all the functionality needed to boot and use a command-line Linux system; xz rather than lzma is my preferred compression tool; and I use grub4dos, currently the chenall fork, as a bootloader because I understand grub1, it can boot from NTFS, it can easily be set up from Windows, and it can boot FreeDOS. So my objection to systemd mostly comes down to this question: why should I have *any* interest in a project that averages ~3 releases a month to add features I don't want, that depends on packages I don't use, and would expect *me* to support *their* design? I have things I'd rather be working on than understanding half a million lines of boot system, and I can build one that I understand and that meets my own needs in under a thousand. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Contact
On Mon, Apr 06, 2015 at 10:36:56PM +0100, KatolaZ wrote: > I simply think that at the moment energies could be spent in a more > productive way than in trying to identify all the good technical > aspects of systemd (which might indeed be numerous). We still don't > have a systemd-free distribution, so I am sorry but I don't see the > point of discussing about which aspect of systemd one would like to > have in an otherwise systemd-free distribution To know the next project we need. And to figure out how much of it needs to be a dropin ABI-compatible replacement, how much should be conceptually similar, where we can reuse something else, and how much serves as a warning to all comers not to go that way. We need to understand the strengths and caveats, the failings and the bright spots. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update
On Tue, Apr 07, 2015 at 02:04:36PM -0400, Jude Nelson wrote: > Hi Scooby, > > >> My tentative solution is to require the device manager (whatever it > >> happens to be) to take one extra step in addition to adding/removing device > >> files: record driver core uevents in a well-defined location in /dev (let's > >> say /dev/uevents/), so libudev clients can discover them (with inotify(2)), > >> read them, and send them off to their applications. This can be done > >> without loss of generality in udev, vdev, and mdev, and I can make a script > >> that takes the appropriate action with mknod (so those with a static /dev > >> can alias "mknod" to the script, if desired). > >> > > > > So you want to split up the "listen to kernel driver core uevents" part > > and vdev right? > > > > I saw you mentioning Isaac Dunham's libsysdev in another message. > > It is a replacement for libudev, right? > > > > libsysdev is meant to help clients pull information from sysfs. I don't > think it is supposed to help clients run privileged ioctls (Isaac, please > correct me if I'm wrong!). Not at present. It basically maps a device to a sysfs directory and possibly gets a *little* more info from that (currently just PCI IDs). You cannot make a library do anything privileged without either helper programs or a helper daemon. Personally, I'm inclined to think it would be nicer to use helpers... but there are limitations to both approaches. I suppose it would be *possible* to make it configureable which it does. > > Can libsysdev do this part quoted below? > > > > "report every kind of device, since it listens to the kernel's driver core > > (i.e. libudev learns about network interfaces, buses, power supplies, > > etc.--stuff for which there are no device files" Currently, it doesn't *report* devices; that takes something longer term, like inotify, polling a netlink socket, or listening to a daemon. It also has no clue about events or hardware that could not have a corresponding device, since it uses block/char and major:minor to find the hardware. I have a general idea of how to get information like this, by recursing through /sys or /dev, and I know of some code I could use as a starting point, but I don't know what the ideal format is. If someone points me at a program they'd like to use without libudev (preferably C with minimal dependencies) that doesn't cover a lot of ground (ie, it's clear what functionality udev provides, and I wouldn't need to duplicate much of libudev to get it working), that would be a good starting point for expanding libsysdev. > > Is vdev and libsysdev tested together? > > > > They're currently not used together. Libsysdev is meant to help programs > that only need libudev for a few things (like querying sysfs) do so without > linking against libudev. > > > To avoid the troublesome corner case where a libudev client crashes and > >> potentially leaves behind a directory in /dev/uevents/, I would recommend > >> mounting runfs [1] on /dev/uevents. Runfs is a special FUSE filesystem I > >> wrote a while back that ensures that the files created in it by a > >> particular process get automatically unlinked when that process dies (it > >> was originally meant for holding PID files). Hmm... Do we need to have a subdirectory of the mountpoint? Could you just use ACLs if you need to make a limited subset available? I get the impression that we can do this for mdev via a script along these lines: FILENAME=`env | sha512sum | cut -d' ' -f1` for f in /dev/uevents/* do env >"$f"/$FILENAME done but it would be *nicer* if we only needed to write one file. Also, wouldn't mounting that with runfs result in records of uevents getting erased if they're written by a helper rather than a daemon? Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update
On Tue, Apr 07, 2015 at 05:22:55PM -0400, Jude Nelson wrote: > > > > "report every kind of device, since it listens to the kernel's driver > > core > > > > (i.e. libudev learns about network interfaces, buses, power supplies, > > > > etc.--stuff for which there are no device files" > > > > Currently, it doesn't *report* devices; that takes something longer term, > > like inotify, polling a netlink socket, or listening to a daemon. > > > > It also has no clue about events or hardware that could not have a > > corresponding device, since it uses block/char and major:minor to find > > the hardware. > > > > I have a general idea of how to get information like this, by recursing > > through /sys or /dev, and I know of some code I could use as a starting > > point, but I don't know what the ideal format is. > > If someone points me at a program they'd like to use without libudev > > (preferably C with minimal dependencies) that doesn't cover a lot of > > ground (ie, it's clear what functionality udev provides, and I wouldn't > > need to duplicate much of libudev to get it working), that would be a > > good starting point for expanding libsysdev. > > > > You might find something useful in vdev_linux_sysfs_register_devices() and > vdev_linux_sysfs_find_devices() functions in vdevd/os/linux.c. They're > both involved in generating the initial coldplug device listing. They only > need libc to work, and libvdev/sglib.h for basic data structures. I know how to get the devices that show up in /dev; I'm not sure about getting the sysfs entries that *don't* show up there. I'm also not sure how anything beyond this is used. > > > > To avoid the troublesome corner case where a libudev client crashes and > > > >> potentially leaves behind a directory in /dev/uevents/, I would > > recommend > > > >> mounting runfs [1] on /dev/uevents. Runfs is a special FUSE > > filesystem I > > > >> wrote a while back that ensures that the files created in it by a > > > >> particular process get automatically unlinked when that process dies > > (it > > > >> was originally meant for holding PID files). > > Hmm... > > Do we need to have a subdirectory of the mountpoint? > > Could you just use ACLs if you need to make a limited subset available? > > I get the impression that we can do this for mdev via a script along > > these lines: > > > > FILENAME=`env | sha512sum | cut -d' ' -f1` > > for f in /dev/uevents/* > > do env >"$f"/$FILENAME > > done > > > > but it would be *nicer* if we only needed to write one file. > > > > I agree that one file per event is ideal (or even a circular logfile of > events, if we could guarantee only one writer). However, I'm not sure yet > what a fine-grained ACL for device events would look like. My motivation > for per-client directories is that unprivileged clients can be made to see > only its own events and no one else's by default (i.e. by chmod'ing the > directory to 0700), and that they make it easy reason about sending > post-processed events only to the clients you want--just change the list of > directories to iterate over in that for-loop :) Which is not trivial in shell, unless you have a special command to do the work of figuring out which which directories get what. ...which seems to make doing this in shell pointless, since the corresponding C is nearly as trivial. > > Also, wouldn't mounting that with runfs result in records of uevents > > getting erased if they're written by a helper rather than a daemon? > > > > Yes; good catch. There are a couple straightforward ways to address this: > (1) have a separate, unprivileged device-event-log daemon curate > /dev/uevents/ and have the helper scripts forward device events to it, or > (2) fork and/or patch runfs to allow files to persist if they're generated > by a certain whitelist of programs (i.e. all programs in a particular set > of directories, like /lib/vdev/), but disappear otherwise once the creating > process dies. What about (3) having an option for runfs that lets it erase directories (with their subentries) on process termination, but lets regular files persist until then? > Thanks for your feedback! > -Jude You're welcome. Thanks, Isaac ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update
On Tue, Apr 14, 2015 at 07:40:41PM +0200, Anto wrote:
> On 14/04/15 17:48, Jude Nelson wrote:
> >I'm using it as the device manager in my copy of the alpha Vagrant image,
> >and others have tested it locally (but not for booting, AFAIK).?? I'm
> >working on getting it to boot the the qcow2 image, which boots from LVM.
> >
> >Thanks,
> >-Jude
> >
>
> Thanks Jude,
>
> I am not sure if at this stage, it is worth it to report the problems that I
> have just experienced.
>
> I followed your 3 steps instruction to have vdev on the PC that I am
> currently using for writing this email (HP EliteBook 8530w), and
> surprisingly it does not work (yet) :)
>
> Before anyone ask: no, this is not a "production" PC as I have been beating
> it up so bad in the last 3 years since I got it used from the company I work
> for.
>
> In the grub.cfg, I used the same set of files as the ones from the running
> kernel generated by update-initramfs, except the initrd that I took from the
> "example" directory under vdev source directory.
>
> It booted the initrd, but just ended up on the (initramfs) prompt. It is
> hard to get the error messages during boot. I tried to record them using my
> mobile phone and the messages at the beginning are the following:
>
> Loading, please wait...
> /init: line 175: resolve_device: not found
> 00071:859055872: [ vdev.c:0425] vdev_init: ERROR:
> vdev_config_load('/etc/vdev/vdevd.conf') rc = -2
> 00071:859055872: [ main.c:0042] main: ERROR: vdev_init rc = -2
>
>
Not being very familiar with vdev, I can't tell you what this means beyond
that something didn't get copied or ended up in the wrong place.
> The last messages that I could see on the screen are about "modprobe:
> modules not found in modules.dep".
>
> If you needed more information, I am quite happy to provide them.
This sounds like what I ran into with mdev.
https://github.com/idunham/mdev/blob/master/hooks/mdev-hook, last two lines:
# Apparently, this somehow only gets copied if udev is installed.
copy_modules_dir kernel/drivers/scsi
The directory where that is would probably be helpful for integration
with initramfs-tools; it's what I worked out for making mdev replace
udev.
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Fwd: [dng] vdev status update
On Fri, Apr 17, 2015 at 08:03:36PM +0200, Anto wrote: > After I pulled your commit from github.com, I have done the following: > > 1. compile and install vdev > 2. copy vdev's initrd into /boot > 3. rename /sbin/init to /sbin/init.novdev > 4. copy vdev's init file into /sbin > 5. manually set the vdev's initrd and init.vdev in grub.cfg > 6. manually add /etc/init.d/vdev into runlevel.conf (and keep > /etc/init.d/udev) > first, I tried to put vdev before udev, then the other way around > 7. reboot my PC using vdev's initrd and init > > There are some progress on the boot messages, but I still ended up on > (initramfs) prompt. As before, I can only use my keyboard using kernel > 3.2.0, so I could capture the vdev_debugging that you asked before. Please > download that from > https://minifora.eu/public/devuan/vdev/vdev_debug_logs.tar.gz. That file > also contain the copy of /var/log/messages, but I just took the messages > since I started to keep rebooting my PC. > Since I've dealt with things similar to this when debugging mdev, I've got a few suggestions: * Check what drivers you are currently using: lsmod * Check if they are in your initrd: lsinitramfs ./initrd.vdev |grep $MODNAME.ko In particular, look for "hid" (hid_generic, usbhid, hid), evdev, ahci/ata_piix (if applicable), and sd_mod. * If they are present, try to inject a line that will load usbhid and evdev into the initramfs scripts. That should provide keyboard support so you can investigate. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Fwd: [dng] vdev status update
On Sat, Apr 18, 2015 at 12:08:54AM -0400, Jude Nelson wrote: [snip] > > I am still using file-rc instead of sysv-rc, but I didn't clean up > > /etc/rc?.d directories. I tried to use sysv-rc, but my mouse and keyboard > > are not being detected when using kernel 3.18.11. They are only being > > detected on kernel 3.2.0 from wheezy repository. I think there is something > > wrong with my kernel config but I will investigate that later. > > > > Not sure yet what could be the cause of your keyboard and mouse not > working. Let's see what happens after you fix steps 3 and 4--it could be a > side-effect of the init program being broken, since the init program should > also run the console setup scripts. To spare you a bit of experimentation: The only thing that needs to happen for a standard keyboard or mouse to work on a VT is the driver loading. The driver for USB keyboards (and USB mice) is usbhid; I think 'hid' is the driver for non-usb keyboards. 'evdev' is needed for some X drivers to work right. ... However, this reminds me: Busybox 1.23.0 and 1.23.1 had a bunch of different issues with modprobe/depmod, and should not be used. If you want to use a non-standard keyboard layout or a different font or resolution, then you need a script for console settings (and a framebuffer driver and fbcon). HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Boot sequence: was vdev status update
On Sat, Apr 18, 2015 at 12:02:23PM -0400, Steve Litt wrote: > On Sat, 18 Apr 2015 00:08:54 -0400 > Jude Nelson wrote: > > > > The init program in example/initramfs/init goes into > > /usr/share/initramfs-tools/init, not /sbin/init :) The initramfs's > > init script is fundamentally different from the init program > > in /sbin. That also explains your inability to reboot. > > > > Basically, when the bootloader loads the initramfs, the kernel mounts > > it as the root device and starts /sbin/init. /sbin/init, in turn, > > runs the script at /init (which you can see from the initramfs shell > > with "ls /"), which is copied into the initramfs image by the > > update-initramfs and mkinitramfs tools from the > > file /usr/share/initramfs-tools/init. > > Hi Jude, > > Your description above differs from what I thought happens at boot. > Until reading your description, I had thought: > > 1) Boot loader runs kernel via the kernel device/path/name, passing it >the root partition device, and device/path/name locations of the >init program and the initramfs (if any). This is incorrect; the bootloader loads kernel and initrd/initramfs into memory, passing along any extra kernel options and a pointer to the initrd/initramfs. For initramfs, the kernel mounts a ramfs or tmpfs filesystem on /, decompresses and extracts the initramfs onto it (which *apparently* involves a loop so that multiple initramfs archives can be concatenated). The initramfs archive is a cpio 'newc' archive, typically compressed with gzip (though the kernel supports xz, bzip2, and I think a couple other formats). For initrd, what was loaded was a raw ext2 filesystem, set up as a ramdrive, so the kernel need not do anything. > 2) Using the passed info, the kernel mounts the initramfs (if any) as >/, and then runs the initramfs' /sbin/init. Any processes started by >the initramfs init program are kernel process surrounded by square >brackets in the ps command. No, they are regular processes. Kernel processes are *part* of the kernel, not userland processes that got started at the right time. I'm not sure exactly what the priority is, but the kernel searches /sbin/init, /init, and /linuxrc at least. /init is tried *before* /sbin/init, a fact which I know due to some experiments with toybox. I've seen a reference to a kernel option that changes the "init" on the initramfs recently on this list; I'm not positive what it is, but it may be rdinit. > 3) If the initramfs init program completes, the kernel runs the init >program whose location was passed to it by the bootloader. However, >in Manjaro's initramfs init, the last line of the initramfs' init >program runs the on-disk init program whose location was passed to >the kernel by the bootloader. When the init program whose location >was passed to the kernel runs, it runs as PID 1, and can spawn (or >manage if desired) other programs. As far as I know, if the initramfs init program completes, the kernel panics. It needs to mount the new / on a mountpoint (traditionally /mnt), move /dev to /mnt/dev if using a dynamic /dev, change the root (pivot_root() is the typical syscall, usually used via switch_root or pivot_root commands), and exec the new init. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Story: Debian Jessie laptop without systemd
On Sun, Apr 26, 2015 at 11:03:07AM -0400, Steve Litt wrote: > The route I've taken, so far, with experimental machines initting with > sysvinit, OpenRC, Epoch and Runit, was to remove as much "desktopism" > as possible. This isn't for everybody, but it works for me because I > never did like the high degree of "desktopism" that Xfce delivers. Desktops seem to aggregate a bundle of software that attempts to meet most of the major needs of most users, of necessity implying bloat (because it isn't tuned to what *a* user needs, it has features that each user will find useless). But generally the desktop-specific tools I've used seem to lack features I want. For a while, I used bits of LXDE, and that worked. But the most useful tools I've found are almost all independent projects: icewm, vim, nedit, xterm/urxvt, worker, mc, mtpaint/pixmap, links2, Ted, magicpoint... In contrast to that I have only gnumeric. > My experience is that, on systemd-equipped distros on which you've > installed an alternate init, NetworkManager isn't worth the heartache > it takes to set up. Running the Wicd daemon and using the Wicd-gtk > client is an alternative that takes more keystrokes. Alternatively, > some day I'm going to create an nCurses equivalent of NetworkManager, > but not any time soon. Some you might be interested in: wicd-curses, ceni, or my own lame wpanet (github.com/idunham/wpanet; it's got a rudimentary dialog interface for generating and extending wpa_supplicant.conf that should be able to use xdialog or whiptail). The configuration part was not the point of wpanet; it was about starting wpa_supplicant and a dhcp client without relying on sleep, but there is an interface that I hope is fairly clear. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
; * disables the udev versions, but does not uninstall them It will be non-trivial to disable another package's scripts while leaving them installed, unless you divert them. What I did was install scripts that would become a no-op if udev was still installed. > * safely builds the initramfs from our scripts. See my mdev repo, especially debian/postinst and hooks/. > * (long-term) does the above in a way that is agnostic to the device > manager, since there are real-world use-cases for selecting mdev or a > static /dev/ over udev or vdev. > > (That last point is why I'd like to work on making it possible to select a > device manager via the alternatives system--the user should be able to pick > whatever device manager they need, but without having to jump through all > these hoops). I doubt that you could make the device manager safely selectable via alternatives, unless you install the interchangeable files in /lib//, have that selectable via alternatives, and have everything that can conflict symlink into /etc/alternatives/device-manager/ or a directory that symlinks to that. This is needed because otherwise, you are inviting an inconsistent state that can render a system unbootable. For example, this might be udev/mdev/initramfs-tools: /lib/udev-rd: devmanager-hook devmanager-top devmanager-bottom /lib/mdev-rd: devmanager-hook devmanager-top devmanager-bottom /etc/init.d: udev mdev /usr/share/initramfs-tools/hooks/devmanager -> /etc/alternatives/rd-dev-manager/devmanger-hook /usr/share/initramfs-tools/scripts/init-top/devmanager -> /etc/alternatives/rd-dev-manager/devmanager-top /usr/share/initramfs-tools/scripts/init-bottom/devmanager -> /etc/alternatives/rd-dev-manager/devmanager-bottom An alternative is just have udev/vdev/mdev all Provide:/Conflict: device-manager, and initramfs-tools can depend on that; but this is clumsy. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
On Wed, Apr 29, 2015 at 12:33:52AM -0400, Jude Nelson wrote:
> Hi Isaac,
>
> [Snip]
>
> >
> > Theoretically, it *should* work if /etc/{passwd,group} are present in the
> > initramfs, with those paths. It's possible to mistakenly copy them to /
> > instead of /etc, but I assume that you've already checked that.
> >
> > Detail that shouldn't make a difference but might:
> > static or non-static busybox?
>
> Not sure; will find out and let you know if it makes a difference.
If you installed "busybox" and not "busybox-static", it's dynamically linked.
[snip]
> > -double-check that you have a non-empty passwd/groups file, containing
> > the same users/groups and world-readable.
> Does it have to be world-readable even if the chown(2) happens from a
> process with uid=0? I verified that they're non-empty, and verified that I
> was unable to (as root) use busybox chown from the initramfs shell.
In theory, you only need the process to be able to read /etc/passwd and
/etc/group, which should be enough for getpwent()/getgrent() to succeed.
Standard is chmod 0644, since every user and program may lookup the
username.
I've tried replicating, and cannot; I use busybox-static.
Example (from memory):
cat /etc/group
# note that "netdev" is a valid group
cat /etc/passwd
# note that only "root" is a user now
touch /tmp/tbnetdev
ls -l /tmp/tbnedev
# note that this is root:root
chown root:netdev /tmp/tbnetdev
ls -l /tmp/tbnetdev
# note that it is now root:netdev
> > To debug it:
> > -Add ltrace (with dependencies) and a *non-static* busybox to your
> > initramfs and try running
> > ltrace busybox chown USER:GROUP FILE
> >
> > This shows you the functions that are called, so you can check if they
> > return success.
>
> I will add ltrace (and ldd) to my initramfs and try this out :)
OK, I'm curious to hear your results.
> > > * As Anto's experience shows, getting a working initramfs is tedious to
> > do
> > > and easy to get wrong. This is not only because there are multiple init
> > > systems that vdevd will need to work with (e.g. sysv-rc, file-rc, openrc,
> > > etc.), but also init scripts and initramfs scripts that come from
> > packages
> > > that depend on udev are (unsurprisingly) tightly coupled to udev. This
> > > makes it difficult to install vdevd on a running Debian system without
> > > removing udev (which is in itself undesirable, since it will take a large
> > > swath of packages out with it), since I have to pretty much fork both
> > sets
> > > of scripts and try to mash them up into a custom initramfs without
> > altering
> > > /usr/share/initramfs-tools. This is effectively what my (extremely
> > kludgy)
> > > initramfs Makefile does.
> >
> > Check what I did with mdev (in hooks/ directory of github.com/idunham/mdev
> > );
> > I did *not* find that initramfs-tools was at all tightly coupled with udev,
> > to the point that dropping the correct scripts into
> > /usr/share/initramfs-tools and convincing dpkg that it didn't need udev
> > was quite adequate.
> Thanks for the link! It's good to get feedback from someone who's packaged
> a device manager before :)
Glad to help.
Reading the mkinitramfs manpage, I see that "-d" looks like it would be
useful to you.
> Regarding setting up the initramfs, my experience is a bit more involved.
> I had to patch initramfs-tool's init script so it wouldn't try to mount
> devtmpfs, and wouldn't try to pull in udev config files or migrate udev's
> info from /run. This is because to the best of my knowledge, the only
> reason devtmpfs needs to be mounted at all is because udev no longer
> creates device files on its own (it only changes ownership and adds
> symlinks). However, using devtmpfs will be problematic for libudev-compat,
> which relies on inotify(2) to detect device changes (i.e. a device file
> that shows up in devtmpfs from the kernel does not generate an inotify
> event).
Rats.
Does mknod(...) = -1 EEXIST trigger an inotify event?
> > > What we'll need is a well-written .deb post-install script that:
> > > * sets up config files needed to generate persistent device names
> >
> > Install config files, marked as such.
>
> It's more involved than that--the /etc/vdev/ifnames.conf file needs to be
> generated from the host's network interfaces, for example (like the
> /etc/udev/rules.d directory). But obviously surmountable :)
Ah, yes. "*Persistent* device names".
Personally, I've never had an occasion to use them, and figure that
loading the drivers manually in order would be enough if I wanted that.
/sys/class/net// may have the information on Linux.
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Debian Dev: anti-systemd people hate women; thus respectable people should not support anti-systemd stance.
Well, I'll comment on a couple points, since the material you quoted is rather misleading at best. Full disclosure: My only associations with the VUA are (1) subscribing to this list; (2) using the devuan repositories, and (3) having an account on the devuan gitlab, which I have only used to mirror a single repository containing packaging for mdev. I have used Debian and Ubuntu in the past, but I was only active in the Debian User Forums, the Ubuntu Forums, and on Launchpad (I have not been involved in Debian development beyond commenting on/filing a very few bug reports, but would be technically capable, as I've had a couple PPAs). I am also involved in multiple unrelated projects where the community is decidedly opposed to systemd (musl, busybox, toybox, puppy), and in one where there are multiple technical barriers to using systemd (Alpine Linux: grsec is the default kernel, musl is the libc). * The laptop "for a developer" (pieced together from personal knowledge and comments here): Dima Krasner (Iguleder on the Puppy Linux forums) describes himself as an "independent R&D freelancer"; he has done a lot of work related to Puppy Linux, including Debian-based editions of Puppy. He was *not* one of the original "VUAs" or other participants in the fork process. His latest project before Devuan was announced was a vaguely Puppy-like independent distro, built from source for i486/32 megabyte systems (it may have been 20 megabytes minimum): in other words, aimed at *bare minimum* hardware. I can't tell for sure what hardware he had, but I would be rather surprised if it was significantly over 1.6 GHz (based on the minimal specs he was aiming at). As soon as the Devuan fork announcement was out, he started working on a stub library, then came up with a shim to use software compiled for logind with consolekit2 (loginkitd) The most productive approach for testing system software is to fire up a vm, which can be *extrememly* slow with limited hardware. Possibly for this reason, the VUAs agreed to get him a new laptop for testing and development of loginkitd. * MikeeeUSA: There have been occasional posts from some individuals which resembled MikeeeUSA's rants. Said individuals have been flamed, banned, or possibly ignored; the first such poster accused the list in general of being SJWs, and tried to flame me when I requested that he moderate his language, saying that the New Testament was feminist. (In case you don't see the irony, I'm a Pentecostal/Fundamentalist Christian, and am generally disgusted with most feminists...and all MRAs.) There have also been some posts in "technical" threads directing vulgarities at systemd and its supporters as such; the reaction to these has varied from ignoring or *lightly* criticizing them to full agreement. Personally, I wish that this would stop: obscenity says litle beyond who the speaker is, especially about the target, though perhaps it's excusable to acknowledge the stupidity that some code has. (Insult the *code* if needed; not the coder, and even more certainly not the users.) I try to delete mails and threads that end up like this. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote: > On Sun 03 May 2015 11:15:45 Laurent Bercot wrote: > > I remember 10ish years ago, mount was actually /sbin/mount. > > It migrated to /bin at some point, probably, as you say, when the > > "user" mount option was added. I personally think that moving > > executables between places is a bad thing, and one of the reasons > > why I'm not a fan of /sbin. > > Easy! > in your dream distro you have no directory tree at all and place *all* > files into root ;-) Never again you have to move a file to the place > it belongs to (just kidding). Unless you follow that radical approach, > any sort of meta info no matter which type attached to an item will > eventually need update when the semantics of the item changes. Strawman! (I suppose that you jest.) This *has* been done before, on a certain *very* minimalist system that was vaguely and indirectly inspired by *nix. You just had to make sure that you had the correct "root" filesystem in the floppy drive. QDOS/PC-DOS/MS-DOS 1.x is the system referred to. Now, regarding Laurent's argument that containers obsolete the concept of some utilities being useless for users: One of the major uses for containers is to isolate potentially vulnerable programs from the rest of the system. Now, suppose one has a possibly vulnerable webserver in a container with its own network configuration. Suppose that someone gets a shell (as whatever user the webserver is running as); would denying them the ability to modify network state be useful? This doesn't establish that /sbin is useful, but the concept of having a limited set of users be able to utilize a program is likely to remain relevant even with containers, unless you can set them up so that all administration takes place externally. A possible use for /sbin on a non-containerized system is to bind-mount an empty directory over /sbin/ in a private mount namespace for all non-administrative users. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Linux boot documentation
On Mon, May 04, 2015 at 10:48:06AM -0400, Steve Litt wrote:
> Hi all,
>
> I just documented the boot process, from Grub through init.
>
> See http://troubleshooters.com/linux/diy/howboot.htm
Comments/contributions for a few sections.
The Bootloader:
I can elaborate a little on grub stuff, though I'm most familiar with
grub4dos-chenall (a fork of a fork of "grub legacy") rather than grub2.
"set root=(hd2,msdos1)" or "root (hd0,8)" specify the filesystem that
all file paths are relative to.
So these stanzas are theoretically both ways of loading /boot/bzImage
and /boot/initrd.img from /dev/sda9 (grub legacy):
root (hd0,8)
kernel /boot/bzImage root=/dev/sda9
initrd /boot/initrd.img
kernel (hd0,8)/boot/bzImage root=/dev/sda9
initrd /boot/initrd.img
With "grub legacy" and derivatives, (hd0,0) is the first partition (",0")
of the first harddrive ("hd0").
Partitions are numbered in the same order as Linux orders them
(under most circumstances).
Grub2 has switched from a 0-based index to counting partitions, but
still counts hard drives from 0:
(hd0,msdos1) is the first partition on the first hard drive;
the "msdos" presumably indicates the partitioning scheme.
The Kernel's Role in Booting:
If you have a kernel with enough stuff builtin (drivers for your disk
controller like ata_piix, block device drivers like sd aka sd_mod,
*and* a filesystem driver for / like ext4 or xfs), you can boot without
an initramfs, by disabling initramfs support when you compile the kernel
or by booting with "noinitrd".
In this case, the kernel mounts the filesystem you specify with "root=...",
mounts devtmpfs on /dev (if you configured it to do so at compile time),
and executes /sbin/init* or the executeable specified with "init=..."
(must be an absolute path; symlinks work, as long as it's on the
same filesystem and resolves to an executable binary of ELF/A.OUT format,
or a script with a shebang line that resolves to such a binary).
*To be pedantic, the kernel actually executes the first init program
from a hardcoded list to be found; typically this is /sbin/init.
You can specify mount options for the root filesystem right after
"root=... " in the kernel commandline.
As far as programs the kernel launches directly other than init go, I'm
aware of two:
First, on hotplug events: if kernel.hotplug is set to the path of an
executable, the kernel will run that executable with an environment
describing the hotplug event.
If the USB subsystem was involved, the first argument will be "usb".
Second, on attempts to mount something with a specified filesystem type
or to access an OSS device when ALSA's OSS-compat layer has been
configured to "preclaim" them, the kernel will run
modprobe
where MODALIAS is some keyword generated from the device/filesystem/
underlying hardware (modinfo and /lib/modules/`uname -r`/modules.alias
are useful for finding out more about these).
The kernel also sends messages via the "netlink layer" to any service
that wants to listen.
The Role of the initramfs:
s/cnew/newc/
This is the SVR4 "new" ASCII-based format, commonly referred to as
"newc". Spelling that out might be helpful.
One important yet obscure detail for preparing an initramfs is that
cpio does *not* create the ancestors of a directory automatically, and
the kernel requires all ancestors to be created before extraction;
if you add
./lib
./lib/firmware
./lib/firmware/radeon/R100_cp.bin
to the input list of files, the initramfs will have /lib/firmware but
/lib/firmware/radeon will be missing so R100_cp.bin will not be
extracted.
The On-Disk Init System:
Another init system is toybox "oneit", which properly sets up a tty,
runs a process, and shuts down the system when said process exits.
busybox init is similar to sysvinit with the following exceptions:
-runlevels are not supported
-the "tag" in the first field is used as the name of a tty to run
a program on, so to set up a getty you usually do this:
tty1::respawn:/sbin/getty 38400 tty1
I would have described openrc differently:
OpenRC competes with the various rc packages as a way to run init
scripts (so sysv-rc, file-rc, and openrc are alternatives); it can
even be used with systemd or upstart if you want to do that.
Its main benefit is that you can write a basic script that acts
like a standard initscript in just a few lines.
Minimal Process Management:
I'd suggest a couple changes to the wording of the list:
1. *Mount* /proc and /sys
2. Populate /dev; initialize drivers and create devices in response
to hotplug events (typically via udev, eudev, vdev, mdev)
On the whole, it's a fairly good overview.
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Linux boot documentation
On Tue, May 05, 2015 at 12:29:59PM +0200, Jürgen Buchmüller wrote: > Am Dienstag, den 05.05.2015, 11:22 +0200 schrieb Didier Kryn: > > I'm not sure what happens if init crashes after other processes have > > been started, wether the kernel panics or other processes continue > > without init - not a very good situation. > > FWIW: I've seen this happening with a home grown jessie (RC2) for > Cubietruck (armv7hf) where a module was seriously broken and led to a > segfault. > > Since with systemd modules seem to be loaded by pid 1 itself, the crash > takes down systemd with it and the system reboots after exiting pid 1, > just crash again when trying to load the broken module the next time. No > chance to break out of this loop AFAIK. > > To me this looks like a fundamental design flaw. A crashing module > should never _ever_ take the whole system down. There has to be some > privilege separation and signal handling in place to prevent that. > > With SysV init this is no big problem, as usually some child process of > init (a shell script) loads the detected (udev rules) or defined > (/etc/modules) modules and if it crashes, init will still be alive. I presume "module" == "kernel module". A module is never run in the same context as the process that loads it. It is a part of the kernel, and thus runs in the kernel context. If it crashes, it crashes the kernel or the associated device disappears. By default, udev automatically loads non-blacklisted modules based on the hardware it detects. On a systemd-based system, udev is mandatory; it is not a part of pid 1, though it is built from the systemd source. If you can figure out what module is causing the crash, you can blacklist it. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?
On Tue, May 05, 2015 at 11:53:30AM -0400, Steve Litt wrote: > Before we get too deeply into this whole thing, what was the original > question? What exact thing are we arguing whether or not to include in > Devuan? Whether or not we need to rebuild packages that have .service files so they will not be installed. A .service file is a configuration file exactly analogous to an init script. I would argue that a configuration file is not enough justification for a rebuild in itself unless it trigggers harmful behavior, and the proper solution for those who want to be shed of them is to create a trigger for dpkg which will run "rm -rf /etc/systemd"... HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?
On Tue, May 05, 2015 at 08:44:22PM +0200, Anto wrote: > > On 05/05/15 18:52, Noel Torres wrote: > > > >As a resume: If you want a systemd-free system, Devuan is your > >distribution, and will always be. But if you want a system designed to be > >unable to run systemd, please leave us. This is not the place for such an > >anti-freedom POV. > Do you understand the impact on what you wrote? > > How much efforts will that be to support systemd *without* any locked-in? I > believe this is what you meant, because Devuan will be exactly the same as > Debian if the support for systemd would also force the locked-in of a lot of > packages. And unless the number of Devuan developers will be as many as > Debian developers, I think you are just dreaming. I think an overview of the different levels of systemd dependency is in order to clarify what's under discussion. Level 0: On paper, systemd can boot a system even if everything else is completely unaware of it. (This was an important part of how it got anywhere to begin with.) This gives almost exactly the same functionality as sysvinit, since it uses init scripts. Level 1: If someone wants to use the dependency resolution that systemd has, they need to have a configuration file for the software that specifies how to start it and what needs to happen first. Level 2: The systemd maintainers claim that writing applications to use systemd "gives the users a better experience" or some such garbage; this usually means a run-time dependency on libsystemd. Such software usually can still run if systemd is not PID 1. Level 3: A few programs require a DBUS method or similar thing tht must be provided by systemd at runtime. It's settled that we don't want *anything* to be at level 2 or higher integration. Now, what's under discussion is whether we are OK with *not* rebuilding packages that are at level 1. This does not mean adding systemd to the repository, it does not require supporting systemd, it does not mean that we add service files to anything: all that it means is we decide that we can ignore configuration files, when there's no dependency. Remember: a configuration file can be modified as the user wishes, or even deleted, and the package manager will respect the user changes. I read Noel's comments as being in favor of leaving whatever is at integration level 1 alone, so that *if* someone decides that *they* want to install systemd on their system, we don't make it harder than necessary. This does not require that *we* should test it, just let things remain (without any support from us). I'd think that this is OK, apart from the question of whether all packages can be rebuilt on a Devuan system. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] why someone might want systemd on devuan
On Tue, May 05, 2015 at 09:17:28PM +0100, David Harrison wrote: > On 05/05/2015 20:43, dng-requ...@lists.dyne.org wrote: > >Well, the problem here is that systemd is*not* hot-pluggable, at all, > >as we have recently learned the hard way. > > Here's a thought. Thrown to the list with no requisite knowledge to back it > up, so please don't bite! > > Is there any way of building a package or some other installable to create a > sandboxed/containerised/quarantined/VM'd minimal systemd? That's if minimal > isn't a contradiction in terms where systemd's concerned? Just complete > enough for a user to install and use contaminatedware within it, when they > really have no other choice, but designed not to leak out and infect their > otherwise clean system? I'd imagine this would be best done via debootstrap install of Debian and some script that can properly configure the result as a VM/container (if it's even possible to use systemd in a container). HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Which source version fo systemd are you stripping code from?
On Fri, May 08, 2015 at 11:40:28AM +1000, Alex 'AdUser' Z wrote: > > Netplug, NetworkManager, inetd, xinetd, dhcpcd, and dhcp(client) to name a > > few already did the same work. > > Netplug is possibly the lightest weight of them all and provides > > connectivity device management as well as net connectivity service. netplug and ifplugd provide essentially the same functionality; ifplugd (written by Lennart several years ago) is the more widely used one as far as I can tell, and there's a small version of it included in Busybox. I'd be unsurprised if Lennart started thinking in terms of all the projects he'd done and decided to roll everything that has some association with initscripts/sysvinit/the "minimal" boot profile into one package. > FYI, there is (was?) another alternative: > https://bugzilla.redhat.com/show_bug.cgi?id=195365 > > Known problems: > > * highly relies on initscripts package > * almost undocumented, official wiki page is compilation of comments > from sources. > * used in only one distro (AltLinux) http://git.altlinux.org/people/sbolshakov/packages/?p=etcnet.git;a=summary That's about all I could read of www.altlinux.org/etcnet (said page is Russian). Last changes were the start of this year. Reading the docs/ dir, I see that the READMEs are almost all "how to do something you already know how to do, using this package". etcnet.8 seems to be *almost* enough to get started; etcnet-options.5 is almost enough to do something; but the real documentation is in examples/. Unfortunately, there's no example of how to do wireless via WPA. I also see that it's meant to work with the hotplug scripts, and that it amounts to "a different way to configure ifup". Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A novice attempt to speed up Devuan development
On Sun, May 17, 2015 at 12:38:59PM -0400, Jaret Cantu wrote: > >Yes. I am on Debian wheezy. I think I always mention that. > Probably did. I am just forgetful, tried, and always assuming that everyone > on the Devuan list is at least striving for Jessie. I know it is a very > incorrect assumption to make, but I can't seem to help myself. Still > haven't coffeed today. > > >There are actually more lines need to have /usr/sbin otherwise I get more > >errors when I tried to start udev. > > > >root@d945gclf:/etc/init.d# /etc/init.d/udev stop > >[ ok ] Stopping the hotplug events dispatcher: udevd. > >root@d945gclf:/etc/init.d# > >root@d945gclf:/etc/init.d# /etc/init.d/udev start > >/etc/init.d/udev: 191: /etc/init.d/udev: udevadm: not found > >root@d945gclf:/etc/init.d# > > > > > > > >root@d945gclf:/etc/init.d# /etc/init.d/udev start > >[] Starting the hotplug events dispatcher: udevd/etc/init.d/udev: 197: > >/etc/init.d/udev: udevd: not found > >[warn] 127 ... (warning). > >[warn] Waiting 15 seconds and trying to continue anyway ... (warning). > > > >[] Synthesizing the initial hotplug events.../etc/init.d/udev: 206: > >/etc/init.d/udev: udevadm: not found > >failed. > >[] Waiting for /dev to be fully populated.../etc/init.d/udev: 216: > >/etc/init.d/udev: udevadm: not found > >done (timeout). > >root@d945gclf:/etc/init.d# > > > > > > > >root@d945gclf:/etc/init.d# /etc/init.d/udev start > >[ ok ] Starting the hotplug events dispatcher: udevd. > >[ ok ] Synthesizing the initial hotplug events...done. > >[ ok ] Waiting for /dev to be fully populated...done. > >root@d945gclf:/etc/init.d# > > Ooh, did I only fix that in one place in the repo? > > I had done some editing to my files after installing. > > PATH="/usr/sbin:/usr/bin:/sbin:/bin" > > Probably not a wise decision. I just threw in the one absolute path since > that is what was stopping me from booting (since it appeared before the > modified PATH, which I had added earlier). While that probably works for most people, it isn't quite up to the level that Debian expected formerly: Anything before mountall, networking, and mountnfs.sh should not use paths under /usr, because /usr could be a (possibly remote) mount. Configuring /dev with something in /usr is particularly bad; coincidentally, eudev was forked partly because systemd-udev started complaining about configurations with a separate /usr. On configuration files: Roger Leigh would probably know the proper way to handle this. You might try looking at the "microcode.ctl" package source, or sysvinit. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] The basic of building package
On Thu, May 21, 2015 at 02:08:23PM +0200, Anto wrote: > Another question is about generating the patch files to be added into > debian/patches directory. What I have been doing so far are the followings, > to get the patch files which look similar to the official patches: > > 1. Create "a" and "b" directory > > 2. Copy the files from the original source package including their directory > structures, into "a" and "b" directories > >If the file does not exist on the original sourcepackage, only generate > its directory structure on "a" directory and put the new file on "b" > directory under the same directory structure > > 3. Modify only the files on "b" directory > > 4. Run "git diff --no-prefix --no-index a/ b/ > .patch" > > I am sure that is not the proper way to do it. So could you please let me > know how to properly build the patches, especially for off-line purpose so > no local and remote git repositories? * The standard tool for Debian packages is "quilt", which needs a litle bit of setup to make it use debian/patches. You will need to "add" files that you want to edit *before* changing them. * git's default format is: --- a/ +++ b/ You do not need to do anything other than make sure that everything has been committed to git before you start editing; git will store the contents of the repository internally. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Unexpected upgrades when updating...
Hello, Running Devuan Jessie. I updated, marked all upgrades, and apt wanted to install ffmpeg instead of libav-tools. Looking at the proposed changes in detail, I see that this is a result of debian-multimedia.org (dmo) packages, as might be expected. What I *don't* get, though is why I'm getting dmo packages when my sources.list contains only the devuan merged repo, a Debian mirror, and angband.pl. apt-cache policy ffmpeg claims that this package is being offered via the devuan merged repo. So is there a way to make dmo packages go away? Secondly, I've installed googleearth via googleearth-package. It depends on lsb-core, which depends on the same version of lsb-release and lsb-base; apparently lsb-core has been rebuilt without rebuilding lsb-release and lsb-base, since they are unavailable. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote: > On 27/05/2015 12:12, Hendrik Boom wrote: > >I'm in the process of writing (yet) a(nother) editor and output formatter, > >and on reading this, I started to wonder -- just how could one separate > >a command-line version from the UI? I can see that the output > >formatter can be so separated (and very usefully), but the actual > >editing? > > Maybe I'm misunderstanding the question, as I'm unfamiliar with the > internal of editors. But IIUC, an editor is, by definition, a user > interface, so the command-line / UI separation looks impossible or > irrelevant to me here. > However, there are still some separations that you can perform when > designing an editor. Right off the top of my head: > - Core functions vs. actual interface, which could be terminal-based > or X-based. Think vim vs. gvim, or emacs -nw. > - programmable editor commands vs. interface to enter those commands. > Think the sed engine in vi, or the LISP engine in emacs. > > If you factor your work correctly, it should be trivial for a program > to get access to your editor commands via a library function call - and > you can make a command-line tool to wrap useful calls. Also, there could nvi (the Berkeley rewrite of vi, after abandoning their first version) uses a shared backend (vi-ipc) connected to the frontend via pipe(). There are about four frontends: terminfo-based (curses was derived from the code for this), tk, motif, and gtk. I ended up finding out this as a result of making the motif frontend build/work again. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] I want to mount a Packages page, buildd and Wanna-build system
On Tue, Jun 02, 2015 at 01:00:12PM -0500, APT Gatuno MX wrote: > El 31/05/2015 8:23 pm, Franco Lanza escribió: > > > >Hello Felix, > >if you can also donate a VPS to the project, this would be great. > > > >So, if you can do that, please do it and just let me know the > >ip address and the hostname you want to have and i will setup the > >devuan.org subdomain on our dns. > > > >If you can't do that or you think is better we host this machine, > >in few > >days i will give you a machine with ssh access to do the work. > > > >The repository to be used is packages.devuan.org/merged [suite] main > >[contrib] [non-free] > > Ok. There is a working Devuan packages at packages.devuan.gatuno.mx Thanks! Seems to work well. However, I'm wondering about something that's tangentially related but perhaps not part of the same code: Does anyone know what it takes to make Aptitude support downloading changelogs from non-Debian packages? Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Sun, May 31, 2015 at 12:19:51PM -0400, Hendrik Boom wrote: > On Thu, May 28, 2015 at 07:16:55PM -0700, Isaac Dunham wrote: > > On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote: > > > On 27/05/2015 12:12, Hendrik Boom wrote: > > > >I'm in the process of writing (yet) a(nother) editor and output > > > >formatter, > > > >and on reading this, I started to wonder -- just how could one separate > > > >a command-line version from the UI? I can see that the output > > > >formatter can be so separated (and very usefully), but the actual > > > >editing? > > > > > > Maybe I'm misunderstanding the question, as I'm unfamiliar with the > > > internal of editors. But IIUC, an editor is, by definition, a user > > > interface, so the command-line / UI separation looks impossible or > > > irrelevant to me here. > > > However, there are still some separations that you can perform when > > > designing an editor. Right off the top of my head: > > > - Core functions vs. actual interface, which could be terminal-based > > > or X-based. Think vim vs. gvim, or emacs -nw. > > > - programmable editor commands vs. interface to enter those commands. > > > Think the sed engine in vi, or the LISP engine in emacs. > > > > > > If you factor your work correctly, it should be trivial for a program > > > to get access to your editor commands via a library function call - and > > > you can make a command-line tool to wrap useful calls. Also, there could > > > > nvi (the Berkeley rewrite of vi, after abandoning their first version) > > uses a shared backend (vi-ipc) connected to the frontend via pipe(). > > There are about four frontends: terminfo-based (curses was derived > > from the code for this), tk, motif, and gtk. > > I ended up finding out this as a result of making the motif frontend > > build/work again. > > Thanks. I should probably look into that. It might be illumination. > Which version of the code or inteernal documentation should I be > looking for? And where? I think what I used was http://repo.or.cz/w/nvi.git, and the vi-ipc code is in ipc/. However, I'm not seeing much of anything by way of documentation. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] automounting in a window manager
On Sun, May 31, 2015 at 07:57:47AM +0800, Robert Storey wrote: > With all the recent discussion about DEs (Cinnamon, Gnome, Mate, etc), I > just thought I'd throw this in here... > > For the longest time, I simply used a window manager. In the beginning, it > was FVWM, but later I took a liking to IceWM. As opposed to a full-blown > Desktop Environment, I liked the speed and simplicity of a window manager. I use IceWM, and also FVWM1 (on my "sparta" devuan-with-mdev install). I prefer the simplicity, and I enjoy having something faster than *any* desktop, xfce included. > The only drawback is that window manager doesn't seem to do automounting of > plugged-in devices. I went looking for a solution, and found this page: In my book, that's an advantage. Of course a significant percentage of the times that I plug in a USB device I'm trying to repartition it. > https://awesome.naquadah.org/wiki/Automounting > > It says, among other things, that udev can be configured to handle > automounting. That's nice, but since systemd has polluted udev beyond > repair, I'm wondering if Devuan can be set up to handle it better, perhaps > with vdev. Or is there a better way? Use "mount" ;-) Locally, I sometimes use a script I named "mat", which mounts a device (shortname) at the "usual" location, creating the mountpoint if needed. This isn't the version I use, but it gives you the idea: #!/bin/sh [ -b "/dev/$1" ] || exit 3 mkdir -p "/mnt/$1" || exit 2 mount -o users,rw "/dev/$1" "/mnt/$1" Something like this could be run from mdev as a helper when a partition is detetected, or you could use "mount -a -T /etc/autotab", or you could use a hotplug helper along the lines of #!/bin/sh [ -n "$DEVTYPE" -a "$ACTION" = "add" ] || exit mkdir -p "/mnt/$DEVNAME" mount -o users,rw "/dev/$DEVNAME" "/mnt/$DEVNAME" Or you could parse the output of nlmon... There are no shortage of ways to set it up. > I believe that people who are opposed to systemd are similar to me - we > prefer simplicity over complex solutions, and are not impressed by bells > and whistles. Thus, I think people who are attracted to Devuan would be a > good market for a simple desktop based on IceWM. True. However, we're often able to set it up ourselves. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] straw poll, non-free firmware for installers
On Wed, Jun 03, 2015 at 08:37:22PM +1200, Daniel Reurich wrote: > Hi, > > I'd like a straw poll on whether we should include non-free firmware in our > installers by default. I would like to see essential "installation-related" firmware available on the installer media if it is properly redistributable. To elaborate: - Only firmware without which the installition *cannot* proceed are covered. Disk and RAID firmware can be downloaded from the installer, but making network firmware unavailable renders the installer useless to the user. Having to use VGA, VESA, or fbdev is not covered. - Non-free drivers are not covered. - I am *not* endorsing any changes to the defaults that the installer proper has, or to the settings of the installation. - "Available on the media" technically includes "have a udeb in some folder", and if that folder can be discovered I think that's enough. - Only firmware subject to a license allowing *anyone* to redistribute it, including on commercial media, is permitted. - In my humble opinion, it would be nice if the user had to manually enable said frmware (and could do so after checking that a lack of firmware caused a lack of working networking). Now, some comments on other comments... * If you're sending messages from your Windows phone, we already know where you stand. No need to repeat it three times. * The question is whether to change what's available on the installer, not whether to install nonfree firmware on systems by default. ...and on Daniel's later proposal: * A useful tool would be one that recurses through 'lsmod' output, using modinfo -F firmware and a file->package lookup to determine what packages are relevant. Conceptually, this *could* determine whether you're dealing with networking hardware. Additionally, one could scan for 'modalias' entries that are unclaimed, and find the required module/firmware. * Ideally, any change in installer behavior would be limited to advising the user about missing firmware and loaded drivers that require non-free firmware. I'd want it to say something along the lines of this (sample based on my currently non-operational X100e): The following drivers that are loaded use non-free firmware: DRIVER PACKAGE r8192sefirmware-realtek ... Some loaded drivers request uninstalled firmware: radeon firmware-linux-nonfree Some drivers have not been loaded, and require unavailable firmware: ... If you wish to obtain full functionality from these devices, it may be necessary to enable non-free packages. In some cases, drivers will work without the firmware. You may prefer to not use the hardware in question due to the proprietary licensing or for other reasons. [Continue] The last sentence is an abbreviated version, but should give you the picture. The point is to give users the knowledge that "this hardware would need such-and-such", without glossing over the fact that there are downsides to selecting it. This should be information presented before the user selects repos to enable. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] straw poll, non-free firmware for installers
On Fri, Jun 05, 2015 at 01:13:51AM +0100, KatolaZ wrote: > Maybe I am the only one unable to see the problem in asking the owner > of hardware which requires some essential non-free firmware during > installation to put the required firmware on a USB stick during the > first boot. If the user has got a way to burn a net-install cd, then > he almost surely has no problem into plugging a USB stick on that > other computer and copying one file therein Because maybe the user doesn't have a free USB stick available? No, I'm not coming up with theoretical problems: When I was taking courses at the university, there was a smallish LUG there, with its own club room, a few desktops, and a table. Standard practice for installing distros was bring your laptop, and there was a single shared flash drive that stayed in the room as installation media: to install a distro, someone downloads a hybrid ISO, dd's it to the flash drive, and then you boot from it. There was no second flash drive for installing, and frequently no one brought their own flash drive: almost everyone had a login on the university servers, where they could store almost anything, and course work was available via an online portal. In short, there was usually only the flash drive that the CD was written to. > From a legal point of view, I would also carefully refrain from > redistributing any non-free firmware in Devuan, the main reason being > that usually you *don't* have the right to redistribute it, and even > if you have got this right from the HW constructor, such right can be > withdrawn any moment at their own will, which might be a quite > unpleasent surprise for Devuan... There is a *very* large set of non-free firmware for which at least your first claim is false, and for much of it the second is false as well. I've actually read several of the licenses in firmware-linux-nonfree. b43 is/was a notable exception, getting it the "b43-fwcutter" package... which leads me to mention something else: The criteria for something getting into debian non-free require your claims to be false for that package, if it isn't a downloader or installer. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Sat, Jun 13, 2015 at 09:42:34AM -0400, Steve Litt wrote: > On Sat, 13 Jun 2015 10:37:19 +0100 > KatolaZ wrote: > > I think there is another, more fundamental question: do we really need > > to know in *real time* when a service/daemon is ready for its job or > > has done what it is supposed to do? AFAIK all this fuss with > > "daemon-readiness" began with the first attempts to have parallel boot > > sequences, which is something that is still *useless* in 95% of the > > use cases: servers don't get restarted evey other minute and "normal" > > users who don't use suspend can wait 30 seconds to have their desktop > > ready, what else? Embedded systems? Well, they usually have just a few > > services running, if any Quite honestly, it really *does* matter to me that I can boot Alpine Linux on my netbook in ~5 seconds rather than the ~10 seconds it takes using LFS-based init scripts on my built-from-scratch system. It really is nice to be able to grab it, press the power button, and have it ready to use by the time I get downstairs; the old 45-second+ boots were rather awkward for conversations where some online document was enquired about. Alpine is OpenRC+busybox init; the built-from-scratch system is musl/busybox/sysvinit/LFS bootscripts, but I've thought about reverting to busybox init and doing a simpler rc script that does what I need. > > What are we really talking about? Isn't this just another > > feature-for-the-feature's-sake-thing? Why should I bother to allow > > cups signalling immediately that it is ready to put my printouts on a > > queue that will anyway need minutes to be processed? Maybe if you have a print server? For a moment, I thought "minutes to be processed" was ridiculous hyperbole; I use a laser printer that gets ~20 pages per minute. (I had a *lot* of papers to write and print in college.) > KatolaZ, I just got done converting Plop Linux to init with a > combination of Suckless Init (for the > PID1/interrupt_listening/shutdown_instantiation) and daemontools-encore > for the process management. I have a daemontools service running > dhclient in the foreground (like all daemontools managed daemons). As > you know, dhclient takes between what, 3 and 20 seconds to get an IP > address, so in my LittKit ordered startup script, I have a loop to > detect when there's an IP address, and stall til one appears. > > If dhclient had seen fit to inform us of a DHCP lease aquisition in a > way other than backgrounding itself (a feature I don't use because > within daemontools I run the program in the foreground), I could have > detected that. Or possibly written LittKit to afirmatively kick off a > process when all its dependencies are met (and you would be right: that > would be more than is necessary). man 8 dhclient: -sf Path to the network configuration script invoked by dhclient when it gets a lease. If unspecified, the default /sbin/dhclient-script is used. Busybox udhcpc and toybox dhcp use "-s" for this. You could use the script to start the network tools directly, or write some indicator that lets the process manager start spawning network programs. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Sat, Jun 13, 2015 at 01:53:44AM +0200, Laurent Bercot wrote:
> On 12/06/2015 22:21, marc...@welz.org.za wrote:
> >The trick is for the daemon process to only background when
> >it is ready to service requests (ie its parent process exits
> >when the child is ready).
>
> This is bad design, for several reasons...
> The reasons why it's bad are mostly described here:
>
> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html
>
> Your solution enforces forking, i.e. auto-backgrounding, and
> prevents logging to stderr; in doing so, it prevents daemons from
> ever being used with a supervision framework. systemd may be able
> to supervise it, using cgroups, but that's about it, unless the
> admin is using foreground hacks.
>
> Moreover, the method you are using to transmit one bit of information,
> i.e. readiness of the service, is *the death of a process*. This
> is pretty heavy on the system; a simple write() does the job just
> as well, and hundreds of times faster.
I think that a program that must run in the background is broken.
Yet *prohibiting* auto-backgrounding imposes an even more heavy toll
on scripts where requires to be running and
ready: you *must* run a supervisor, or else run a lame-not-quite-a-
supervisor, just to do what would have been trivially done in a few
more lines of C.
While I haven't written the code yet, it strikes me that it should
be trivial to write something that can handle both styles of
notification, and maybe even share some of the code.
Essentially, part of the auto-background code becomes a trivial
not-quite-a-supervisor that exits as soon as it receives the same
notification that you use.
In the example, I'd want an option like "-S ", where
is the fd that goes to the pipe the supervisor is listening to.
Pseudocode for this without proper error checking:
int pipefds[2];
pid_t pid = 0;
parse options;
if (supervised) {
pipefds[0] = -1;
pipefds[1] = supervisor_fd;
} else if (background_option) {
pipe(pipefds);
pid = fork();
if (pid < 0) {
error_exit();
} else if (pid > 0) {
//close write end of pipe and watch read end till the pipe closes
} else /* if (pid == 0) */ {
//close read end of pipe
}
}
// setup process
if (supervised || background_option) {
write(pipefds[1], "1", 1);
close(pipefds[1]);
}
Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
