You are not logged in.
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.
Hello,
that looks pretty cool. Can you tell us how you have achieved this?
Desktop environment, window manager, dock, what artwork?
Keep on with Devuan, it's great, really!
Greetings.
Hello,
you say nothing about your configuration: which desktop environment do you use?
There should be a "Display" configuration applet in you DE. open it, let it detect all displays and set each one up. Make sure to remove the option that mirrors display 1 and 2. It should be that...
Good luck.
I agree, OpenRC is the logical choice:
It's easy to use,
It's very effective
It's maintainable and transparent
And, it's mostly compatible with old init scripts
I have used it from the beginning with Devuan and it never failed me.
It does one job and does it well
All this in a very true UNIX manner
I'm sorry to hear, Altoid.
As I wrote, dd writes from the beginning of the disk/partition. Even only a smaller iso-file dumped to it will overwrite the partition-boot-block and a lot of important filesystem information, like the superblock, some inode-tables, directories, datablocks etc.
Even if you are successful in creating a new partition table or taking the one from the end of the blockdevice (GPT), the overwritten information is gone.
When you create a new filesystem and install an OS or copy data to it, the data is mostly written to the beginning of the filesystem. So there are more likely data erased there when an accidental dd wreaks its havoc. You may be able to recover some files if they and the related inode-tables are in the non-overwritten area. But blocks my still be missing since the filesystem can reuse emptied blocks if their files were once deleted and the associated file was extended, before the accident happened.
The explanation may not please - life can be miserable.
Hello,
please know that dd is a disk-dumper, a block-copying program, that acts on physical devices (like disks, partitions etc). If you give a file-name as output device it will write the blocks to that file. If the output device is partition or a disk, then for heavens sake you will have the contents of that input file (the iso image) on your partition or device. Even if you manage to recover the superblock or some inodes from you original filesystem, the blocks pointed to will still contain copied blocks from your source-device (or file). The dd program starts to copy block by block, from the beginning. man dd helps....
Sorry, but reality can be hard.
Don't despair:
Use a shell (terminal) and type
sudo tasksel
Then give the right answers and it does the magic for you.
Happy new Year
Just tested the most recent installer iso:
https://files.devuan.org/devuan_chimaer … nstall.iso
(Alpha from May 3rd, 2021)
on the same Dell PC Optiplex 990 PC
- UEFI / GPT mode (with secure boot disabled of course)
- Standard Install
- Chose Cinnamon Desktop, OpenRC
--> worked very well
(had to add the non-free firmware-amd-graphics for the AMD GPU)
And once again the same with the XFCE4 Desktop.
Everything works well, though anacron still stalls the shutdown process occasionally.
I therefor just disable the service to be happy.
Thanks for that good progress you make.
Just a hint: be sure to type in the password correctly. That requires a correct keyboard setup!!
The WiFi PreShared Keys are, of course, case sensitive.
Good luck.
Here my experiences with the new installer iso:
https://files.devuan.org/devuan_chimaera/installer-iso/
1. An old Dell PC Optiplex 780
- BIOS / MBR mode
- Expert Install (standard install didn't start)
- Chose Cinnamon Desktop, OpenRC
--> worked very well
(only had a hick-up with the keyboard selection, it worked correctly in X but not on text console. Fixed it with a dpkg-reconfigure keyboard-configuration)
2. A newer Dell PC Optiplex 990
- UEFI / GPT mode (with secure boot disabled of course)
- Standard Install
- Chose Cinnamon Desktop, OpenRC
--> worked very well
(had to add the non-free firmware-amd-graphics for the AMD GPU)
I tested to install a second DE on both machines: XFCE4 using the tasksel program, and it went very well.
Is there a chance to get rid of the installation of anacron by default? That thing still does delay enormously the shutdown, occasionally.
--> Conclusion: it's already very good for me, thank you for that very pleasant and successful adventure
Micronaut, do yourself a favour:
Either leave your system in classic BIOS-mode and your disk in MBR mode, and you will have no negative consequences. (My own experience with a 10 years old HP elitebook pro).
If yours is enough recent, you may re-initialize your laptop, Set BIOS settings to factory defaults, then enable EFI/UEFI-boot, your Intel Virtualisation options to your needs and DISABLE SECURE BOOT (=disable TPM). Then wipe the disk and initialize the disk with a GPT label. When you now install Devuan, it will be in UEFI/EFI mode and it should work.
But if your PC works well in your current setup, there is no harm in using it that way.
Is your GNOME desktop running in "fallback" mode?
If yes, make sure your graphics controller is supported or install the non-free firmware drivers. Gnome needs 3D acceleration.
It's just my thought, but possibly off-track.
Good luck.
Does this mean that our friend "nomorelogic" will have to wait for Devuan 4 Chimaera to come out on an install-able iso?
(With a more recent kernel, then...)
rolfie,
there is one thing to mention:
If you set the motherboard to CSM mode, then you are well advised to install in NON-UEFI mode!
If you set the motherboard to UEFI mode, then you MUST disable the "secure boot" option and install in UEFI (EFI) mode.
You can choose the install-mode when you boot your stick afresh.
The Devuan installers handle these things quite well, usually... so is my experience with it.
I know, it's possible to fiddle with CSM disk mode and EFI boot, or in UEFI mode with classic (CSM) boot. If you succeed, all the better, but expect upgrades, migration or parallel-installs to fail.
I have learned that the hard way: EFI is fine, CSM is fine, but UEFI (secureboot) is a portal to hell.