You are not logged in.
Excellent comment, alexkemp.
To play DVDs, vlc and libdvdcss2 did the trick for quite some time already, in most Linux distros.
Bluray is a completely different story! Thank you for your hints!
Could be nice, a good idea. Certainly if it's somewhere in Central Europe I'd be interested. Depending on the type of conference as well (speeches, workshops, exchange of experiences, future developments and directions where Devuan goes...). Lovely.
I'm committed to Devuan.
webman, I'm not aware of what version of Devuan you use.....
but, by default the selection of xfce4 desktop environment installs slim as display-manager.
Just install lightdm instead --- and you will be able to switch users.
(Use sysnaptic or apt install lightdm to install and answer the questions sensibly)
Good luck
Easy:
Is it running?
-->
someuser@mybox:~$ /etc/init.d/eudev status
or
-->
someuser@mybox:~$ ps -aef | grep udev
restart it:
-->
someuser@mybox:~$ sudo /etc/init.d/eudev restart
Check status (openrc):
-->
someuser@mybox:~$ rc-status -a | grep eudev
eudev is a replacement for udev.
Udev depends on and is integrated with systemd; we all don't want that..... agree?
To alexkemp and owners of Brother multi-function printers
I followed your story about your nightmarish printer driver and configuration problems.
I used to have HP printers (MFPs) and they worked extremely well with Linux. HPLIP and CUPS do it all best. Now the printer is failing and I have to replace it. Most new HP printers do things via the cloud only, which is rubbish I will avoid.
So my interest turned to the Brother brand.
Your report made me skeptical and I did some research on the Internet and did some tests.
1. A Brother DCP-L2550DW (black-and-white laser) worked out of the box with no configuration and software installation.
My PC had all CUPS packaged installed already, and the System-Config-Printer program showed right there that new printer. All tests and scanning went fine. This was at a friends site, they use Apple PCs only.
2. A test with an older Brother DCP-L9055 was a complete disaster. Nothing at all worked. That was another neighbour's site, they use Windows and also Apple laptops. (That printer was most probably mis-configured, so it works only with Windows)
3. I bought myself a Brother MFC-J5340DW, installed it in my network following the Quick-Setup-Guide, went to my workstation PC and that thing worked without any configuration or software installation. Out-of-the-box - Big success. Every test was successful.
If you show me how, I can post the CUPS test-printout - it shows some CUPS-specifics.
A quick check revealed that all CUPS packages are installed. It looks like the CUPS and the CUPS-browsed play an important role.
My PCs are all installed with Devuan Chimaera.
Now, my idea is this:
1. remove all downloaded Brother .deb packages. Not even special .ppd files are required. Only the amd64 architecture is required in my case, so no i386 or i586 packages here. Also delete all configured printers in your "System-Administration-Print Settings" program.
You need the CUPS packages.
2. Reset your Brother DCP-L3510DW printer to factory-defaults and set it up as shown in the Quick-Config-Guide.
3. Then go (as user) to "System-Administration-Print Settings" menu and see if you see your brother printer is already there and test it.
When you Devuan system is installed in a standard way (Chimaera), it should work.
I hope in your LAN there is no filtering inside your network. All protocols shall pass within the LAN.
Please let us know if that helps.
My very best greetings and good luck. Andre
Thank you, alexkemp!
That's really good information.
Andre4freedom
Again, one can take the harm out of UEFI/EFI Firmware/BIOS:
DISABLE "SECURE BOOT".
That frees you from the dependency of MS-signed keys for OS or software... And saves you from a lot of configuration trouble.
This will create a RAID volume and will synchronize it.
Usually the partitioner within the installer will do that for you.
You can monitor it by cat /proc/mdstat
What I do with my EFI partition is just to copy over the contents. The EFI devices are not in a RAID.
Devuan Daedalus Installation using RAID-1 Disks and UEFI/GPT mode
*****************************************************************
After all, I tried to install Devaun Daedalus to a single disk in pure UEFI/GPT mode (but secure boot disabled).
Installation went well, but finally the computer wouldn't boot. Again. Misery.
To deal with that problem, I had to reset the computer including all BIOS settings to factory defaults and to completely wipe all residual configuration from the disks.
Then a new trial to install an Enterprise Linux (Alma Linux 9.1) in UEFI mode.
That went well too, AND the computer would re-boot after all.
Now, using the Devuan USB-boot stick I configured the disks as visible below.
The disks:
----------
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD1000DHTZ-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 081780F2-D244-5C4E-9623-C4200969845D
Device Start End Sectors Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 3147775 2097152 1G Linux RAID
/dev/sda3 3147776 976773120 973625345 464.3G Linux RAID
Disk /dev/sdb: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: SAMSUNG HD502HJ
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FD95D43D-6719-4C2A-B389-299985C86967
Device Start End Sectors Size Type
/dev/sdb1 2048 1050623 1048576 512M EFI System
/dev/sdb2 1050624 3147775 2097152 1G Linux RAID
/dev/sdb3 3147776 976773119 973625344 464.3G Linux RAID
The RAID status:
----------------
linuxadmin@daedalus:~$ cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sdb3[0] sda3[1]
486680576 blocks super 1.2 [2/2] [UU]
[==============>......] resync = 71.4% (347912704/486680576) finish=22.8min speed=101256K/sec
bitmap: 2/4 pages [8KB], 65536KB chunk
md0 : active raid1 sdb2[0] sda2[1]
1046528 blocks super 1.2 [2/2] [UU]
unused devices: <none>
The block devices:
------------------
linuxadmin@daedalus:~$ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 530D-FFCA
├─sda2 linux_raid_member 1.2 daedalus:0 ddc7f83e-413b-367b-5753-38ec7a4f55b3
│ └─md0 ext3 1.0 BOOT c4b6ab5f-f5a6-483a-a2c2-0ef546daab37 884.2M 5% /boot
└─sda3 linux_raid_member 1.2 daedalus:1 1d92ad6e-ac89-97e5-541a-96410abb2c9c
└─md1 LVM2_member LVM2 001 FLJkFO-IZCD-kWiE-2IUI-pS59-4xMm-RcPd1K
├─vg0-lvroot 30.8G 10% /
├─vg0-lvhome 43.2G 0% /home
├─vg0-lvswap [SWAP]
└─vg0-lvsrv 339.9G 0% /srv
sdb
├─sdb1 vfat FAT32 0D98-84C3 498.2M 2% /boot/efi
├─sdb2 linux_raid_member 1.2 daedalus:0 ddc7f83e-413b-367b-5753-38ec7a4f55b3
│ └─md0 ext3 1.0 BOOT c4b6ab5f-f5a6-483a-a2c2-0ef546daab37 884.2M 5% /boot
└─sdb3 linux_raid_member 1.2 daedalus:1 1d92ad6e-ac89-97e5-541a-96410abb2c9c
└─md1 LVM2_member LVM2 001 FLJkFO-IZCD-kWiE-2IUI-pS59-4xMm-RcPd1K
├─vg0-lvroot 30.8G 10% /
├─vg0-lvhome 43.2G 0% /home
├─vg0-lvswap [SWAP]
└─vg0-lvsrv 339.9G 0% /srv
sdc
sdd
sde
sdf
sr0
The active mounted filesystems:
-------------------------------
linuxadmin@daedalus:~$ df -h
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 1.2M 1.6G 1% /run
/dev/mapper/vg0-lvroot 37G 3.8G 31G 11% /
tmpfs 5.0M 8.0K 5.0M 1% /run/lock
tmpfs 3.1G 0 3.1G 0% /dev/shm
/dev/md0 989M 54M 885M 6% /boot
/dev/sdb1 511M 13M 499M 3% /boot/efi
/dev/mapper/vg0-lvhome 46G 1.7M 44G 1% /home
/dev/mapper/vg0-lvsrv 359G 28K 340G 1% /srv
cgroup_root 10M 0 10M 0% /sys/fs/cgroup
tmpfs 1.6G 16K 1.6G 1% /run/user/1000
tmpfs 1.6G 4.0K 1.6G 1% /run/user/109
linuxadmin@daedalus:~$
The LVM2 configuration:
-----------------------
linuxadmin@daedalus:~$ sudo pvscan
[sudo] password for linuxadmin:
PV /dev/md1 VG vg0 lvm2 [464.13 GiB / 0 free]
Total: 1 [464.13 GiB] / in use: 1 [464.13 GiB] / in no VG: 0 [0 ]
linuxadmin@daedalus:~$ sudo vgscan
Found volume group "vg0" using metadata type lvm2
linuxadmin@daedalus:~$ sudo lvscan
ACTIVE '/dev/vg0/lvroot' [37.25 GiB] inherit
ACTIVE '/dev/vg0/lvhome' [46.56 GiB] inherit
ACTIVE '/dev/vg0/lvswap' [15.36 GiB] inherit
ACTIVE '/dev/vg0/lvsrv' [<364.96 GiB] inherit
The installation of Devuan Daedalus went quite well, then. Finally it was able to reboot.
The only thing that needs to be done yet is to clone the EFI partition to the second disk.
In my case:
dd if=/dev/sdb1 of=/dev/sda1 bs=1M
I will do that once the RAID1 md1 is synced.
As you can see, doing all that for UEFI's sake gives a lot of pain, but it's doable.
I hope you can deal with this information and adapt your installation.
If not, loving UEFI-volunteers are welcome to help you.
dcolburn: keep in mind to never access the RAID components or LVM2 elements directly.
The devices to mount, of fsck, or whatever are:
/dev/md0 989M 54M 885M 6% /boot
/dev/mapper/vg0-lvroot 37G 3.8G 31G 11% /
/dev/mapper/vg0-lvhome 46G 1.7M 44G 1% /home
/dev/mapper/vg0-lvsrv 359G 28K 340G 1% /srv
/dev/sdb1 and /dev/sda1 are the EFI partitions, Never touch them for other reasons that to do a grub-install on each of them.
Greetings, Andre
Okay, with this machine you best stick with UEFI mode and GPT partitioning scheme.
But be aware that the RAID1 setup is different. I have pointed to an article that shows right that:
https://askubuntu.com/questions/1299978/install-ubuntu-20-04-desktop-with-raid-1-and-lvm-on-machine-with-uefi-bios
Unfortunately I can't help at this point right now, since I have to invest considerably more time to work it out under UEFI/GPT conditions.
I'm sure someone in our Devuan community has the deeper knowledge. I always had the problem with the grub-install in UEFI mode in RAID setups. The boot afterwards just hangs with the message "BOOT"
You are right, rolfie. But have you tried that with RAID1 installations???
The little boot partition plus LVM2 on the second partition overcomes all these "limitations". It's still quite usual on enterprise-server hardware.
Oh, BTW: when checking with fdisk -l /dev/sda (or /dev/sdb), make sure your partitioning in the installer has been committed to disk! Everything you do in the installer becomes active after committing the part you do. Until then it's in memory only. ;-)
I don't know your hardware or motherboard.
My test machine can do both, old-style BIOS mode and UEFI mode. (My experiences with software RAID1 System-installations in UEFI-mode are quite bad)
However, I suggest that you stick to one scheme:
Either
-BIOS/MBR mode mainboard
-MBR / DOS disk labels
-Boot the stick with the USB NON_UEFI selection.
Or
-EFI/UEFI mainboard
-GPT disk labels
-Boot stick with the USB UEFI selection.
When booting, EFI mainboard firmware offers you the UEFI-USB-Boot option to load the USB stick. In that mode you do a EFI-mode Devuan install and the installer proposes GPT disk formatting. On MBR/BIOS hardware this would be in MBR mode with DOS labels on the disk. I wouldn't force to mix the modes, even though possible. I'm no specialist in UEFI tricks, but HoaS seems to know a lot more on that topic.
You may be able to mix up these elements, but the result could be "interesting".
In MBR mode you can go as instructed in my post. In EFI mode you must have 1 active, bootable EFI partition. you can set aside a second such partition on your second disk. After successful installation you can then dd the active EFI partition to the inactive second one. Maybe it works?
Hello dcolburn,
your disk partitioning looks right (https://www.sun2save.com/images/misc1/newpartitionattempt1.jpg)
But how have you assembled the RAID devices? RAID Device 0 should become md0 and contain /dev/sda1 and /dev/sdb1
RAID Device 1 should become md1 and consist of your bigger partitions, sda2 and sdb2
You can do that in your installer program, in the "Configure Software RAID" sub-menu and it does the job right.
Once you have md0 and md1, you can proceed following the instructions. md0 should be your /boot partition. md1 is an excellent base for a LVM2 Volume Group vg0.
Good luck!
Colburn,
I have done some testing and research to your problems.
First of all it seems that your computer/server/mainboard has not been set up properly.
There are 2 ways to operate hardware and its OS to be installed: UEFI or classic MBR type. This affects the boot process and how the disks are used.
1. UEFI
=======
This is a very tricky new solution. EFI is a good solution to overcome limitations to the classic PC restrictions. It requires you to label and format disks in GPT manner.
Now U-EFI, provoked by big tech companies adds complexities to "increase" security against malware, but it's mainly used to lock out any software that is NOT "certified" by Microsoft.
To avoid that UEFI snag, you have to disable the "Secure Boot" option in the mainboard (or BIOS) setup.
To do that, I suggest to reset the mainboard to factory defaults and the selectively adjust the few settings you really need:
- disable secure boot
- keep the board in EFI mode
- check the boot-order (priority) for the system to boot from
- Install from a CD, DVD or USB-stick (select the UEFI-USB install media)
- Scrub your disks and fdisk them to GPT and so on (I suppose you let the Devuan installer do it, it does it well!)
2. MBR / BIOS mode
==================
Most enterprise level servers work in that mode. Ask an datacenter operator.
There are no worries about secure boot etc.
To do that, I suggest to reset the mainboard to factory defaults and the selectively adjust the few settings you really need:
- check the boot-order (priority) for the system to boot from
- Install from a CD, DVD or USB-stick (select the USB install media)
- Scrub your disks and fdisk them to MBR (DOS Label) and so on (I suppose you let the Devuan installer do it, it does it well!)
3. RAID
=======
If your motherboard or system includes a Hardware RAID controller, make sure you know it well and follow the manufacturers indications for the OS setup. I have worked quite a lot with such kind of hardware and it worked well (Dell PERC) Others are quite problematic, because usually they let you access RAID members from the OS, which is a very bad thing!
If in doubt, switch the controllers to simple SCSI or SATA controller through-mode and disable the RAID functions on that hardware.
Then install Devuan using the software RAID option. This works really well.
4. My experience with an UEFI board and SW-RAID
===============================================
My system worked well with one single disk, all in UEFI and GPT mode. That's why I added a disk and tried to set it up with the Devuan installer to assemble the RAID and partitions. I failed miserably.
I switched the system to BIOS/MBR mode, relabeled the disks to DOS Labels and set up the thing all using the Devuan Daedalus installer (Netinstall)
It worked really well, like a charm.
5. Example setup
================
- Reset the computer to factory defaults
- Set options sensibly as mentioned above
- Boot the Devuan Netinstall stick
- Choose the standard install method (just "Install")
- Give all answers accordingly to your needs
- Enter the Disk Partitioner:
-- Remove any residual config whatsoever There shall be no LVM volumes, no LV Groups, no RAID partitions, just nothing.
-- Create a 512MB primary partition, the first, on each disk and set the type to type fd (Linux RAID). (sda1 sdb1)
-- Create a very big primary or extended partition. the second, on each disk and set the type to fd (Linux RAID). (sda2 sdb2)
-- Go to the RAID submenu of the partitioner and create the the RAID volumes.
(Assemble sda1 and sdb1 to md0, and sda2 and sdb2 to md1)
-- Now back in the main partition menu, define md0 as the /boot partition (ext3 or ext4)
-- Enter the LVM submenu (Logical Volume Manager)
1. Declare md1 a LVM physical volume
2. Create a Volume Group vg1 and add md1 as a member
3. In that volumegroup create the volumes you need:
-- 40 GB for root (ext4) (/)
-- 40++ GB for home (ext4) (/home)
-- ??GB for swap (swap) (size depends on you RAM in the system)
-- ??GB for server-uses (ext4) (/srv)
-- Now back in the main partion menu, define the for logical volumes as shown above
(I will show the filesystem layout at the end)
- Now continue your installation, tasksel does a wonderful job. (I chose Devuan Desktop, XFCE, web server, Console productivity and SSH server)
- !!! at the end, don't just hit continue! chose Back instead and start a shell in the install environment. There you type
grub-install /dev/sda and grub-install /dev /sdb (That makes both disks bootable.
Note: this is absolutely the one and only instance when you must access the RAID members of md0. It only copies one boot block to each disk.
- Here, you can reboot. It worked for me.
- Hint1: remove the anacron scheduler, it's of no use on a server and only causes problems at reboot
- Hint2: add your software as needed, web servers, ftp servers, database servers etc. They all should create and use subdirectories beneath /srv
- Hint3: LVM2 is an excellent way to handle disk space. It allows for snapshots even.
- Hint4: Backup to devices that are formatted (i.e. ext4) and mounted temporarily to /mnt. Never backup to device nodes like /dev/sdxyz. Tape drives did that.
I hope that helps.
A few notes:
Never, in the whole server's life, access RAID or LV members or elements of it. That is a sure way to hell. The only exception is the grub-install after kernel- or GRUB-updates.
RAIDed Volumes are accessed using /dev/md0 (for mounting, fsck etc) but don't touch /dev/md1 in our case.
Logical Volumes are accessed using /dev/mapper/VGx-lv-yyy (for mounting, fsck etc)
All filesystem activities as also backups etc have to access the corresponding mountpoints.
Now the configuration on my test server:
***********************************************************
linuxadmin@devuan:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 1.1M 1.6G 1% /run
/dev/mapper/VG0-lv--root 38G 3.8G 32G 11% /
tmpfs 5.0M 8.0K 5.0M 1% /run/lock
tmpfs 3.1G 0 3.1G 0% /dev/shm
/dev/md0 446M 52M 369M 13% /boot
/dev/mapper/VG0-lv--home 47G 1.8M 45G 1% /home
/dev/mapper/VG0-lv--srv 339G 28K 322G 1% /srv
cgroup_root 10M 0 10M 0% /sys/fs/cgroup
tmpfs 1.6G 12K 1.6G 1% /run/user/1000
tmpfs 1.6G 4.0K 1.6G 1% /run/user/109
***********************************************************
linuxadmin@devuan:~$ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 linux_raid_member 1.2 devuan:0 d67d9792-6c1c-c10f-c183-ccdfd63fb72a
│ └─md0 ext3 1.0 BOOT f16202ab-b30f-40df-95e5-9c18998b9b60 368.9M 12% /boot
└─sda2 linux_raid_member 1.2 devuan:1 f1e96c15-2935-8021-39ee-71cba1fab584
└─md1 LVM2_member LVM2 001 NEkYz6-31wg-ymNm-xR09-98J3-RavJ-0TZrZK
├─VG0-lv--root 31.6G 10% /
├─VG0-lv--home 44.2G 0% /home
├─VG0-lv--swap [SWAP]
└─VG0-lv--srv 321.5G 0% /srv
sdb
├─sdb1 linux_raid_member 1.2 devuan:0 d67d9792-6c1c-c10f-c183-ccdfd63fb72a
│ └─md0 ext3 1.0 BOOT f16202ab-b30f-40df-95e5-9c18998b9b60 368.9M 12% /boot
└─sdb2 linux_raid_member 1.2 devuan:1 f1e96c15-2935-8021-39ee-71cba1fab584
└─md1 LVM2_member LVM2 001 NEkYz6-31wg-ymNm-xR09-98J3-RavJ-0TZrZK
├─VG0-lv--root 31.6G 10% /
├─VG0-lv--home 44.2G 0% /home
├─VG0-lv--swap [SWAP]
└─VG0-lv--srv 321.5G 0% /srv
***********************************************************
linuxadmin@devuan:~$ cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sda2[0] sdb2[1]
468618240 blocks super 1.2 [2/2] [UU]
bitmap: 1/4 pages [4KB], 65536KB chunk
md0 : active raid1 sda1[0] sdb1[1]
497664 blocks super 1.2 [2/2] [UU]
unused devices: <none>
***********************************************************
linuxadmin@devuan:~$ lvshow
-bash: lvshow: command not found
linuxadmin@devuan:~$ man lvm
linuxadmin@devuan:~$ pvscan
-bash: pvscan: command not found
linuxadmin@devuan:~$ sudo pvscan
[sudo] password for linuxadmin:
PV /dev/md1 VG VG0 lvm2 [<446.91 GiB / 0 free]
Total: 1 [<446.91 GiB] / in use: 1 [<446.91 GiB] / in no VG: 0 [0 ]
linuxadmin@devuan:~$ sudo vgscan
Found volume group "VG0" using metadata type lvm2
linuxadmin@devuan:~$ sudo lvscan
ACTIVE '/dev/VG0/lv-root' [38.14 GiB] inherit
ACTIVE '/dev/VG0/lv-home' [47.68 GiB] inherit
ACTIVE '/dev/VG0/lv-swap' [15.83 GiB] inherit
ACTIVE '/dev/VG0/lv-srv' [<345.25 GiB] inherit
linuxadmin@devuan:~$
Link to a excellent article that hints to the intricacies of UEFI-RAID-LVM
https://askubuntu.com/questions/1299978 … -uefi-bios
https://unix.stackexchange.com/question … oft-raid-1
I hope these (lengthy) instructions help.
If you need clarification, I will try to help. Good luck.
dcolburn,
I'm trying to help you. I am building up a system that reflects your configuration, more or less.
System using EFI mode (but secure boot disabled!!!)
2 disks in a Software-RAID1 setup
Devuan Daedalus (not recommended, use Chimaera as it's current stable)
I will write the procedure for you to follow - if you wish so.
I have a production server running for years without any problems. It's an enterprise server (meaning BIOS mode).
It runs with a RAID1 setup (mdadm, no HW-RAID) and never fails me.
It runs with Devuan Beowulf.
I will not cover backup, this is another topic.
My procedure will take a little time.
Good day!
Beware of more evil to come:
https://www.theregister.com/2022/10/26/tightening_linux_boot_process_microsoft_poettering/
You know what this guy did to Linux and the free and open source world - pulseaudio and systemd greet you :-(
Now he is proposing even worse things: locking down hardware with TPM2 - Micro$oft must be happy to have him on board.
I am scared.
Oh, you were quicker than me ;-)
Easiest way:
just download https://files.devuan.org/devuan_chimaera/installer-iso/devuan_chimaera_4.0.0_amd64_desktop.iso
test its checksum and dd it to a USB-stick.
The USB stick doesn't have to be partitioned or formatted, just dd it to the device file /dev/sd? and not to /dev/sd?1 or so. (? = your drive. Find out with lsblk)
Then boot that USB drive and of you go...
(sudo dd if=devuan_chimaera_4.0.0_amd64_desktop.iso of=/dev/sdb bs=1M)
Hello,
yes, there is... kaiyel points to good an accurate information.
In today's times, the disks are big enough to hold most of a filesystem. But:
If you intend to separate just the /home filesystems to its own partition, do it by all means, that's a very good reason.
But, if, out of old (and good) habits you want to keep /usr separate, you have to be sure you can access enough system- and filesystem-repair binaries in the root filesystem in case of severe filesystem problems that prevent automatic mounting these other filesystems.
Therefore things like mount, fsck, ps etc have to be kept in the /bin or /sbin directory (which is in the root filesystem).
In old SysV times I have encountered funny constructions like the basic OS tools kept in the rootfilesystem/usr directory, and /usr was used as mountpoint for it's separate filesystem. If the mount is successful at boot, you have all the tools. If not, you could still try to repair with whatever tools are kept beneath the mountpoint /usr.
I know, it sounds boring these days, but it had its reasons not too long ago.
Good day to all.
Sorry it didn't help.
I was referring to your post:
sudo mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
Just an idea: sudo is not always the same as root.
I suggest to do a
su -
That switches your shell to the root account. Then try to change to the script directory and run it (as root user)
After the (hopefully) successful installation you just leave the root shell
Ctrl-D
And your shell will be back to your user again.
Good luck.
That looks pretty cool. I love it.
I should try openbox too, once I find the time and a not to busy computer.
Congrats!
Now that clears it all up.
Thank you all for your hints and contributions.
Have great, but not too hot weekend
Thank you, Head_on_a_Stick,
Great.
Any idea what the dock could be?
Have a nice weekend.