You are not logged in.
mmm I don't much care about GUI, but I don't think I would see much value in using a platform that wants to be in control how my stuff looks. Probably best for me that I keep staying away from it ![]()
Yes, one way would be to change the "method" for eth0 in (/etc/network/interface) from dhcp to manual and instead have the dhclient command as an up command (i.e. to be run after that the interface is brought up at link level).
To do that you would first run it as dhcp, then use pgrep dhclient to get hold of the full command to run, which you copy to be the up, with your modifications.
@nahkhiirmees: you might rather want to use the reject statement in the client host's /etc/dhcp/dhclient.conf. See man dhclient.conf for details.
As a reminder: this is a Devuan forum, and not a social-political arena. Behave.
Thank you for noticing. Yes, they are all perfect again ![]()
perhaps it works with
# modprobe efivarsAfaik, when you installed lvm2 it should have added itself to initrd. Though my conjecture from your other notes is that you have the lvm2 software installed some other way. Perhaps a package reinstallation would be an option?
Possibly this all has been an effect of an apparent misconfiguration of Devuan's authoritative name servers such that some of them only served the ipv6 addresses for deb.devuan.org.
This has been corrected, so things might improve.
@Grumpy, with all respect, it's kind of like contacting your bike manufacturer when you, on your way to the shop, find that there is a temporary road closure.
More precisely, the Temporary failure in resolving 'deb.devuan.org' notice is from the initial phase in the networking when the apt software (on your computer) attempts to find an IP address for that service. The service itself is not involved in that phase.
It would also be useful to know whether this person used the default Install option or the Advanced/Expert install option, and the choices along the way. Often enough people opt to use the latter and then make choices contrary to their needs and intentions. It would be good feedback about the appropriateness (and lack of) of the steps' advice and instructions.
I don't know much of this either, but fwiw I agree with your observations.
You might be able to use amixer to toggle that 'HDMI/DP,pcm=3 Jack' control.
First you'd do
amixer contentsto see what is possible and the "names" of things, and then something like
amixer cset iface=CARD,name='HDMI/DP,pcm=3 Jack' toggleto toggle that control.
You might also want to review the output from
alsa-info --no-upload --stdoutwhich supposedly tells everything possible about the alsa setup. It's a good haystack to look for needles in ![]()
The daedalus preview ISOs are currently only those that provide packages. Each is set up as a "repository" which most easily is used as a "file://" source in sources.list. I suppose some "cdrom:" line might work as well but I haven't had luck with those. So, my suggested hands-on is:
mount the ISO at some file path /X
add a line to sources.list (note the plethora of slashes):
deb [trusted=yes] file::///X daedalus main contrib non-freethen run apt-get update and so on
Those ISOs don't include any installer and are not bootable.
Just to be sure:
Devuan's "stable" is a link currently pointing at "chimaera"
Devuan's "testing" is a link currently pointing at "daedalus", and
Devuam's "ceres" is a link pointing at "unstable".
It's typically as stable to use Devuan's "unstable" as it is to use Debian's "unstable" ("sid"), because most of Devuan's packages come unaltered from Debian. Mostly it works well (better?) to run a "chimaera" installation and only add in "daedalus" packages where necessary and possible.
quick note: I think your IV and V are in wrong order: init executes /etc/init.d/rcS because that's what /etc/inittab says. That file is the configuration for init.
Please continue ![]()
EDIT: Actually, you skipped over the pre-pivot stage, which is the initial bootup (adding .1 to your III) using the initrd filesystem.
The kernel begins by running its /init which is a shell script, and that script will eventually pivot the root to the "real" filesystem and exec /sbin/init. The initrd scripting is held in /usr/share/initramfs-tools which is a configuration place for building an initrd, since the actual, running initrd is the cpio package loaded from /boot into RAM by the kernel (using the initrd= parameter).
afaik most linux systems have that 2-stage boot, to allow the bootup to be programmed generically even though every actual bootup is a specific host. It's quite possible to set up the bootup for the specific host without using an initrd stage but then typically it needs a specific kernel with the right modules compiled in.
True. And the OP may also have their good reasons for not using mariadb, which is the "product line" that is supported within the Devuan context (well, Debian context really, since it's not forked).
Isn't it called mariadb in chimaera?
The most common mistake for an "expert" installer is to skip the "load components" (or similar) step.
Does that fit your use case?
Respectfully, these "works for me" anecdotes seem rather small-minded and useless, pretty much like the whole idea itself.
Personally I'm in no way confused by having multiple directories with programs and libraries, and I imagine that the likelihood of confusing something or someone is larger with making this kind of change than not changing.
The idea is a matter of choice, and the main stigma is in the question of who should make the choice.
In many ways it's similar to that choice of excluding /sbin and /usr/sbin from non-root user's default setup; a choice which in my view is equally stupid.
But I don't make these choices. I merely learn to live with them.
Well, five * like that actually means "run every minute", and generally it looks fine, so it really should work fine provided that
a) the pathnames are fully correct (also in letter casing), and
b) the file does end with at least one newline.
Somehow it seems your machine has a disagreement about whether the hardware clock is UTC or localtime, perhaps between the bios and the kernel. Maybe that it ticks in localtime and your kernel believes that to be UTC, so it applies TZ distance "again".
@Altoid, quite possibly the MemAvailable measure has lost its most significant digit (it's rather unusual to have more free than available memory), and maybe you should consider replacing
_memavail=$(grep -i memavailable /proc/meminfo | cut -c 19-27) # OK no cats harmed _memfree=$(grep -i memfree /proc/meminfo | cut -c 19-27) # OK no cats harmed
with something else, like e.g.
_memavail=$(sed '/memavailable/I!d;s/[^0-9]*//;q' /proc/meminfo) # OK no cats or cuts
_memfree=$(sed '/memfree/I!d;s/[^0-9]*//;q' /proc/meminfo) # OK no cats or cutsEDIT: (though maybe I'm wrong about what memfree and memavailable means?)
I think you (again?) are confused by groucho not having /usr/sbin in PATH (and not /sbin).
It's not a sudo issue; /usr/sbin/service is happily being executed by any user, although the start and stop of services may well require root.
Usually "install linux beowulf" would mean to use an installer ISO which then kicks in already on the boot-up of the machine.
Presumably you think of doing something else and you may then need to explain in some more detail what you mean.
In particular "installation through the command line" implies you are running an OS. which?