You are not logged in.
One of the founding fathers of devuan is an astronomer. All our releases are named after minor planets.
https://www.devuan.org/os/releases
1+ for apod. Some of my favorite desktop backgrounds come from there.
Oh yeah, pmount. Try this -
https://sourceforge.net/projects/refrac … nt-1.2.deb
It works for removable USB, CD and mmc devices. Add any fixed drives to /etc/pmount.allow.
Maybe you can do something with these.
From refractainstaller. This lists partitions. It does not differentiate between encrypted and non-encrypted. Using blkid would be one way to find the encrypted partitions.
find /dev -mindepth 1 -maxdepth 1 | egrep "*[shv]d[a-z][1-99]|*nvme[0-9]n[0-9]p[1-99]|*mmcblk[0-9]p[1-99]" | sort | awk '{print "\n" $0 }'Same thing with a graphical interface (yad)
device=$(find /dev -mindepth 1 -maxdepth 1 | egrep "*[shv]d[a-z][1-99]|*nvme[0-9]n[0-9]p[1-99]|*mmcblk[0-9]p[1-99]" \
| sort | awk '{print "\n" $0 }' \
| yad --list --title="Select device" --center --borders=10 --text="Select a device." \
--separator="" --column ' ' --column$'Partitions' --height=380 --width=200 --button="OK":0)From refracta2usb. These list usb devices.
usbdevlist=$(/usr/sbin/hwinfo --usb --short|grep "/dev/sd"|awk '{print $1}')
usbdevfulllist=$(/usr/sbin/hwinfo --usb --short|grep "/dev/sd"|awk '{print $0}')And used with yad.
device=$(yad --width=400 --height=200 --center --title="$TITLE" --list --separator="" --column="" --text=$"Detected USB devices:\n\n$usbdevfulllist\n\nSelect the target device you want to copy the live image to." $usbdevlist \
--button="OK":0 --button="Exit":1I had to alter some of these so they would make sense. I hope I didn't break anything.
I don't know enough about encryption to give any advice, I just want my laptop to not be wide open for any smack-head who finds it, and encrypting my home directory (and swap) takes care of that. This should be enough to prevent anyone stealing my laptop from also getting into my eBay account, or reading my personal data (identity theft). I don't store any state secrets so can't say how appropriate this method is if you do.
I don't think I suggested that this should be part of the installer - that's really not for me to say. But what I can say is that the /home encryption methods provided by the installer are unsuitable for my use case, since they require a separate partition and two passphrases at every boot. That's not how I want my laptop to work, but I'm not here to tell anyone how they should configure their system.
If you only encrypt your home and swap, there may be other things at risk. For example, wireless passwords may be stored in /var or /etc in plain text. There may be other things, so it's a good idea to encrypt the root partition. If you don't want /home on a separate partition, then don't put it on a separate partition, and it will be part of the root partition. The live installer will also make a swap file if you don't have a swap partition, and that file is kept in the root partition.
So...
Make a separate /boot partition, put everything else in the root partition and encrypt the root (i.e. Do not make or use a separate partition for /home). You will be required to give the passphrase ONCE to unlock and boot the system. Everything except /boot will be encrypted. If you don't want to give your user password to access the desktop, then set the display manager for autologin.
Or, if you really want, you can encrypt nothing during the install, put all in one partition and then encrypt /home with ecryptfs after the install.
I'm not sure what to say about your mute button or the power button issue. My setting for power button is Ask. That is the default setting. I was going to ask you what acpi software you had installed, but I see on mine, two acpi packages were removed (acpi-support-base and acpid) and the power manager does ask when I press the power button.
And I fixed my mute button light by switching the command to 'toggle' like yours instead of volume 99%-. Does aplay -l show more than one sound card? That can sometimes confuse things, depending on which one shows up as card0.
@dice: Thanks for the info on how to get the key into the initramfs to avoid having to give the password more than once. That might get included in a future version of the installer. It already does full-disk encryption.
The mute light on my T420 doesn't work right. I haven't looked into that.
You are right that a window comes up asking for root password after selecting sudo as default. That part was written so long ago I didn't remember that, and nobody else has pointed it out. There is a checkbox in that window that says "Disable root account" so I know the window was meant to come up. I'm not sure why, but I'll look into it.
The debconf dialogs really are the same ones in the graphical installer, but there are some problems with that. For one, we don't offer a graphical version of the debian/devuan installer because it got too big and was making the isos larger than we wanted. If you want to see the familiar ncurses version of these dialogs, sudo apt remove libgtk3-perl in the live session before running the installer. (More on this later.)
The second problem you noted is the drop-down menu. It went off-screen on my laptop and I couldn't get down to London. I believe that's a gtk-3 feature that I've seen before. The graphical debconf dialogs are going away in the next set of isos and it'll be back to the ncurses version. That's what it was for jessie and ascii. We're working on getting the beowulf point-release out, so it should be soon.
As you noted, selecting the locale does not automatically select the keyboard map. I just checked with the netinstall iso, and it doesn't do it there on the regular install, but it does on expert install. I think that's easy to change. (dpkg-reconfigure -plow ...)
You forgot the option I like to go with; use the user's login to decrypt /home. I'm not 100% sure how this bolts together (pam + ecryptfs?), but it certainly doesn't involve storing the decryption key in plain text on the machine, nor does /home need to be on a separate partition - I have to enter my (strong) password to decrypt and mount the directory as /home, but this is done seamlessly from the Slim login window.
I'm not familiar with this method. What installer uses encryptfs? The regular debian/devuan installer can do plain luks encryption on single partitions or it can encrypt a physical volume that contains multiple logical volumes for separate partitions. If you do encrypted LVM, you only have to put in a password once to unlock the encrypted volume. The live installer does not do LVM (without some manual tricks) so you can only encrypt individual partitions. If you choose a separate /home partition (it is not mandatory) and you encrypt that partition, you will need to enter a password for it. As I mentioned before, you can create a keyfile and keep it in the encrypted root to automatically unlock the home partition. It's not a plain-text password. See man cryptsetup for details.
In either of the above situations, you need a separate /boot partition that's not encrypted. It is possible with the live installer to do full-disk encryption and have an encrypted /boot partition. In that case you get to give the luks passphrase an extra time for grub, and on top of that, it takes grub a long time to digest the password.
You also get a lot of options that were missing from the GUI installer, such as configuring the network, setting up NTP, fetching latest packages, choosing what to install...
You missed those things for the same reason you had some other problems with the live installer. It's because you are not familiar with how it works. It's different from what you are used to. You certainly do have access to all those things because you are in a running live environment, and any changes you make to the system will be copied to the installed system. That includes network setting and configuration changes. You could also remove or install packages, but installing them might use up too much ram in the live session.
Thanks for the input. I will make some changes.
Hi all,
with some nearly unusable GUI widgets, like a drop-down containing every European TZ location (this should be a scroll-window), and the keyboard layout selection sends you on a circuitous journey just so you can tell it that yeah, the keyboard layout is the same as the (already chosen) locale.
This is the standard graphical debconf interface as the graphical install and the exact same language, time zone and keyboard settings in the debian/devuan installer or with dpkg-reconfigure. And yes, it is correct to set the keyboard separate from the language.
Many of the checkbox options are contradictory; for example I chose on one screen to disable the root account (btw - why does it say this is a bad idea!? It's a really good idea, and ought to be the default!) only to have the next ask me for a root password.
It only asks for a root password if you chose one of the options that preserves the root account. And making sudo the default is a really bad idea. Sudo is not meant to be a replacement for a root account, it's meant for fine-grained privilege escalation.
You probably would have done better with the live installer if you'd taken a look at the Installer Guide. It's the other devuan swoosh icon on the desktop. Or if you had just hit Enter at the second screen instead of clicking on Continue, you could have looked at the Help page.
The installer guide is also here for reference: https://www.devuan.org/os/documentation … f/live-gui
the hardware volume up/down/mute buttons don't work. TBH I don't think I tested them before removing pulseaudio, so I can't say if they were working or not, but they're defintely not working now. I can see that they generate the correct events with `acpi_listen`, but it seems nothing is listening to them? `lsmod` shows `thinkpad_acpi` is loaded, so that's not it.
In the Settings menu, go to Keyboard and Application Shortcuts and you can set up the volume keys to activate amixer. There are a few websites that explain how to get Thinkpad keys working in linux.
2) I was also surprised to see it ask me for an encryption password at boot; I'm used to the encrypted /home being automagically decrypted and mounted at log-on using ecryptfs (including encrypted swap). This should offer enough security for most users I would say, to hinder identity theft in case the laptop is lost or stolen. In any case I can't give the machine to my friend like this; he'd hate having to remember and type two different passwords to turn on his computer - or even the same one twice. I also didn't like how the installer (seemingly) forced me to use a separate partition for /home if I wanted it encrypted.
You have a few choices with this installer. You can install everything in one partition and have it encrypted. Your /boot directory will be part of the encypted partition. You will have to tell grub the passphrase to open it and start the boot. You will then have to repeat it for the kernel. This is referred to as full disk encryption, and it's a new feature in grub to be able ot deal with encrypted /boot.
You can encrypt the root filesystem and have /boot in a separate partition, unencrytped. You then have to give the passphrase during boot. Once.
You can optionally have a separate partition for /home. It's not mandatory, and I usually skip it on a laptop. If you choose to encrypt the separate /home, you will need to enter a passphrase for it, whether or not the root filesystem is encrypted. If you want to eliminate adding the second passphrase, you can create a key and have /home open automatically. This is only secure if the key is kept in an encrypted root filesystem (or a removable device).
I cannot get the laptop to sleep when I close the lid.
I found that it works just fine when you upgrade to chimaera, which is still in testing. Search the forum. There are a couple of discussions on how to get it working in earlier releases.
Security updates are sometimes late in devuan because amprolla gets confused when it sometimes gets a 404 on a debian repo. When this happens, it's usually discovered and fixed within a few days. You've probably seen the discussions on this forum about it.
There are people working on this, and based on something I was told a few days ago, it might already be fixed.
Pedro, you probably don't want to read this.
mckaygerhard wrote:
again talking without well knowed ! everybody can have free access to those security updates..
Either you don't know what you are talking about or you are deliberately spreading misinformation. I think it's the latter. You said that Debian offers 7 years of support. That is simply not true.
You don't know what goes on here. You just come by every now and then to throw shit on the project. Are you getting paid to do this? I don't have the time or desire to track down and identify all your alternate "facts". So I now have to assume that everything you say is false.
Thanks. I wasn't aware that a private company is offering commercial support for Debian, but I'm not surprised by that. If someone wants to form a private company to offer extended support for Devuan users, they are welcome to do so. I don't think it's fair to fault the dozen or so devs we have for not doing that.
Extended Long Term Support (ELTS) is a commercial offering to further extend the lifetime of Debian releases (after the 5 years offered by the LTS project). It is not an official Debian project. Debian's infrastructure and other Debian resources are not involved.
and Devuan as i know still are only 5 years of support,, Debian has 3+2 + ExLTS in a total of 7 years..
I've never heard of this before. Does Debian have a secret server for companies that want the extra two years of support? How does one go about getting that? Or is it only systemd that they support for the extra two years? That would explain why it's not in Devuan.
Do you even know how Devuan gets its packages? Have you heard of amprolla?
FYI: 99% of packages in the Devuan repository are not in the Devuan repository. When you understand that, you will have attained some level of enlightenment.
A universal package manager with a single repository where anyone can push
WTF???
polkit and apparmor — granular...
security uploaded by anyone. Right.
That all being said, I hope devuan will last for another 4-5 years the way it is at least... if not forever.
Buster/Beowulf has another year before it moves into LTS. Then figure another two before Bullseye/Chimaera moves to LTS. You could easily add another year or two to that, so we are potentially up to 5 years. Chimaera is already working pretty well, and Bullseye has gone into soft freeze, so I feel confident that it can't get screwed up too badly for us to fix and use it.
I've never played with arm images, so I guess that's why this problem seems so foreign to me. Please say exactly which iso or image you used. If you'd like, I could move this thread to the arm section of the forum where it might get more attention (from someone who knows more about arm than I do).
When I suggested setting up static ip for the pi, I meant in /etc/network/interfaces. Setting it up on an external device won't do anything to bring up the interface, it will only allow it to have an address when it asks for one. Is there anything other than the loopback entry in the interfaces file?
dpkg -l |egrep "network-manager|connman|wicd|ceni"will tell if one of those is installed.
Wow, this all sounds so wrong.
ifup/down works with interfaces that are configured in /etc/network/interfaces
ssh starts and stops according to the links in /etc/rc?.d which are defined in the init script, /etc/init.d/ssh. It does not care about ip addresses or interfaces. Check your system logs to see if you can figure out why ssh is not running.
If you're going to always use wireless on this device with the same local network, you could set up a static ip in /etc/network/interfaces. If you have any network management software installed (n-m, wicd, connman, etc.) you should remove it so it doesn't fight with your static config.
I just find this strange behaviour, it seems the netinstall iso install just disrgarded the compose key and ctrl_alt_backspace setting that i put in dpkg-reconfigure keyboard-configuration but the refractainstall took it?
Refractainstaller runs dpkg-reconfigure in the running live system, and then the changes get copied along with the rest of the system. I'm not sure how devuan/debian installer does it. I think it just stores the values and edits the target file, but it's also possible it does it in a chroot. Either way, I don't know why the two installers would give different results.
I can reproduce this error. You need to start jack or set audacity to use alsa. (or maybe pulseaudio if you use that.)
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be startedNew torrent files:
https://files.devuan.org/devuan_beowulf.torrent
https://files.devuan.org/devuan_ascii.torrent
We're using these trackers now:
udp://9.rarbg.me:2710
udp://tracker.opentrackr.org:1337
udp://tracker.cyberia.is:6969
refractainstaller runs 'dpkg-reconfigure keyboard-configuration' and that's all it does with keyboard. It copies the running system to the hard drive. It does not add or remove packages.
refractasnapshot excludes selected files, but it does not add or remove packages. See /usr/lib/refractasnapshot/snapshot_exclude.list
Maybe something to do with locale settings? I'm just guessing.
Yes, you could add a boot paramater instead of removing that live-config script. To test on the fly, press TAB at the isolinux boot menu or 'e' at the grub boot menu to edit the boot command.
To change the templates for the boot menus, so you don't have to edit them on every build, look in /usr/lib/refractasnapshot
Autologin is controlled by the display manager, and if there isn't one, startx is run from
/etc/profile.d/zz-live-config_xinit.sh
That file is created by /lib/live/config/0140-xinit
You could remove that file before making a snapshot, or comment out a few lines of code in that script. I think it will also work to add a boot option:
nocomponents=xinitIf there's a way to tell the computer to boot from usb, then it should ignore any bootloaders on the hard drive.
Boot loop usually means kernel and initramfs are missing. Mount the iso and look inside the live folder. There should be filesystem.squashf along with kernel and initramfs. And if the file names are different, make sure the boot menu has the right names.
If you chose force_efi, then I assume your host system boots in legacy bios mode. Make sure both grub-pc.bin and grub-efi-amd64.bin installed. And you'll need to have a copy of the not-installed grub package in the root of the system (or somewhere else if you specify the location in the config file.)
I like to install grub-efi-amd64 in the system and put the grub-pc deb package in the root, so it's available during installation on bios sytems. It works the opposite way, too, but if grub-efi is the one that's installed, then you will also have efibootmgr in the live system. That will make life easier if you boot on a uefi system.
dpkg -l |grep grub
Check to make sure there are two partitions in the iso.
fdisk -l <snapshot.iso>
I have no idea what would do that.
Look in /var/log/apt/history.log to see what really got installed or removed.
nm. If you saw what was here, forget it. It was wrong.
If you're using grub-efi-amd64-signed and have ID=devuan in /etc/os-release, you'll boot to a grub prompt instead of a boot menu. That's because grub will expect the signed bootloader to be found under /boot/efi/EFI/debian, but your bootloader will be in /boot/efi/EFI/devuan instead.
Some third-party software that expects to see debian might complain or refuse to install. I don't have an example.
There's also /etc/issue, which is in most linux distros.
I realize I didn't give you a link to the test iso I mentioned. See if you can get the network up with this iso. It has a newer kernel which will work with newer hardware.
https://get.refracta.org/files/experime … 9_0205.iso