You are not logged in.
Before we go into details: what do you really want? Be able to be online and getting updates via internet connection? Or do you want to ban the internet and only depend on the DVD? You seem to have a mixture in your sources.list.
Got my workstation and a laptop running Daedalus for several months now productive at home. No major issues, just smaller topics.
As simple as it is, currently there is no "daedalus-security" yet as long as Daedalus still is in the testing stage.
You need to open the luks volume with the same name as listed in the crypttab. An easy way to get a chroot is to use the rescue mode of the install medium, the netinstall is sufficient.
Well, the encryption problem is fixed with the netinstall iso dated June 1st. The nopat issue still exists.
Thank you for your attention.
@Ralph: just for completion, also the legacy mode throws the same libgcc error on the May 27th version.
@Ralph: thank you. Can confirm that the 'nopat' option works. The installer boots into a VBox VM and you can select a language.
But: when trying to set up an encrypted LVM in expert mode, the installer stumbles, I get a red screen past entering the passphrase twice. On console 4 I see the message "partman-crypto: libgcc_s.so.1 must be installed for pthread_exit to work"
Well, definitely there is a kernel dump on console 4 related to the graphics (after I found out how to switch consoles in a VBox window). Have no idea how to copy this.
VBox 7.0.8 from originator on Daedalus amd64 on X570/Ryzen 5900/6700XT hardware. VMSVGA video driver selected.
netinstall previews dated May 8th, 22nd and 27th do start in EFI mode, install and expert install and end in a grey screen where I would expect the language selection screen. Same isos work fine in legacy mode and and real HW.
Tried to get to some screen with useful debug info and failed ...
Somebody with some more knowledge should look into this issue. If I can help with some more input, please let me know.
Thanks, rolfie
I have a file server in the basement supporting nfs. The clients mount the nfs shares via a cron job @reboot. If the server is unavailable the cron job never finishes, but the clients do boot up without delay. This setup works for more than 15 years now.
Well, I copy new fonts to:
TTF: /usr/share/fonts/truetype
OTF: /usr/share/fonts/opentype
ATM: /usr/share/fonts/type1, not really supported any more nowadays
and I create a new directory for them below that paths. Do the copy with root privileges, and make sure the directory has 755 as octal rights and the fonts have 644 as octal rights.
Works fine.
Use the rescue mode in the installer.
My two cents:
1.) The sudo issue
I am talking about the installer in expert mode. I am only using this mode since I am experienced enough to understand where the possible problems are, and I know what to expect and where I can tweak the installations.
The installer gives you the choice to enable the root account with an administrative password. Then sudo is not installed. When you think you need the sudo package, you have to add that package after first boot into the system.
If you deny a root password, sudo is getting installed, and you have to use it the Ubuntu way for admin tasks. When you do not like this, you can assign a password to root and then login as root or use su -.
2.) My experience with EFI
I have several modern PCs that partially have pure EFI bios like my laptop, some older ones (AMD X470/X570) still have CSM as backup. I am installing them in pure EFI mode, SB is disabled and the keys are getting deleted. I never had any trust in SB. CSM is off an all these machines. No other setting needs to be changed. My laptop was something special, an Acer Aspire5. To be able to modify the Bios settings, I had first of all to set an admin PW for the Bios.
Chimaera should be able to be installed with and without SB. You just have to boot the installer in EFI mode. Note: you will typically get the boot medium twice in the boot override: one is marked with the comment EFI, make sure you use this one. The other just shows the device name, thats for installation in legacy mode.
No idea about the HW in the Lifebook, and if some components are too new for stock Chimaera. If stock Chimaera does not satisfy, the first step would be to add kernel and firmware from backports.
3.) You are using the expert installer. Make sure you load the installer components. This is one of the first steps past selecting the language settings. If you skip that step you will get very limited install options, e.g. you ext2 as file system, no ext3/4 options.
Good luck.
Edith: just had a look at some test reports for this device. You should be fine with stock Chimaera.
Investigate what caused the HDD crash, and attribute the change to the crash.
Daedalus is testing, you will have to live with what you get. Its no different from Debian Testing = Bookworn. When it is released officially, you will get the full story.
I did my installs with a preview dated July 22, since after that the installer was missing some locales to support e.g. German during installation. Never tried one of the newer ones that have the fix.
I would suggest to switch HDMI with DP or vice versa, or try to use a different monitor if available.
I had some trouble with a 6700XT under Chimaera, refer to https://dev1galaxy.org/viewtopic.php?id=5364, moved to Daedalus and the PC is working fine since then.
Testing in Devuan is called Daedalus: https://www.devuan.org/os/releases
Your system is encrypted, so the /usr/share/... path isn't available to grub when booting.
The solution is to copy the /usr/share/desktop-base/grub-themes/desktop-grub-theme-files to /boot/grub/themes. This will provide the default layout in an unencrypted location. Every now and then the /etc/default/grub may get overwritten by updates. Then you have to fiddle again.
I have no idea what will happen if you simply comment the themes-line from /etc/default/grub. That may cause a real hickup...
This line
Found theme: /usr/share/desktop-base/grub-themes/desktop-grub-theme/theme.txt
indicates that grub wants to read the path /usr/share/desktop-base/grub-themes/desktop-grub-theme. This path is available on an unencrypted system for grub and for the system when running update-grub at any time, no errros.
On an encrypted system, when grub starts, this path isn't available yet until the initramfs has opened the root directory. This is when you get the errors as from the initial post. When running update grub there is no error since then /usr/share.... is available.
You need to dig a bit deeper into the path on your selected server. The Daedalus directory it self was created in 2021, below you should find up to date previews, the latest seems to be dated March 27th.
BTW: basic non-free stuff is already integrated, there are no separate isos as with Debian.
You have to leave the Ventoj partitioning scheme for the boot stick alone as is. Don't try to modify this. Per Default there is a boot partition that hold everything for legacy and efi boot, and a partition for the iso's. I think there is no LVM involved if I am not mistaken.
It is not Ventoj that is causing problems, it is the installer itself. If you are manually directing the installer to the intended partitions for the installation everything works fine.
In manual partitioning mode you can see which devices and parititons are what for and select the desired spave for the system.
With a Ventoj multiboot stick never use automated install! You will need to use manual partitioning to have full control where the system goes. This works perfectly.
The installation of the clearlooks-phenix-sapphire-theme changed /etc/grub/default back to desktop-base and the themes there. On my encrypted Daedalus this produced the initial error in grub, an update-grub did NOT fix this. I copied clearlooks-phenix-sapphire-theme to /boot/grub/themes and changed the /etc/grub/default to point to the /boot/grub/themes-directory, and everything is fine again.
Could it be that grub searches for the theme on the encrypted system device? Check /etc/default/grub.
When this is the case you may need to move the theme files to the unencrypted /boot.