SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
## Highlights
- Add 44.1KHz to allowed samplerates. The server can now switch by
default between 48KHz and 44.1KHz.
- Streams now allocate less resources.
- Fix some bugs that could make the server crash.
- Bluetooth now supports the LC3plus vendor codec.
- Many bugfixes and improvements.
It has been suggested before by others for previous releases, but somehow valgrind has not made it into Slackware.
In my opinion valgrind is very useful for debugging and together with kcachegrind also very useful for performance analysis of programs.
The odd thing is that Slackware includes kcachegrind. However, kcachegrind is not to any use without valgrind. Kcachegrind can also be even more useful together with graphviz.
It is not a big deal to install valgrind and graphviz from other sources like slackbuilds.org , but if valgrind is not included in Slackware you might just as well leave kcachegrind out and let slackbuilds.org pick up that ball.
It has been suggested before by others for previous releases, but somehow valgrind has not made it into Slackware.
In my opinion valgrind is very useful for debugging and together with kcachegrind also very useful for performance analysis of programs.
The odd thing is that Slackware includes kcachegrind. However, kcachegrind is not to any use without valgrind. Kcachegrind can also be even more useful together with graphviz.
It is not a big deal to install valgrind and graphviz from other sources like slackbuilds.org , but if valgrind is not included in Slackware you might just as well leave kcachegrind out and let slackbuilds.org pick up that ball.
regards Henrik
I use valgrind and find it helpful for debugging when used with gdb (which is included with Slackware).
I have not tried kcachegrind - will investigate, so thanks for mentioning it.
I have not tried kcachegrind - will investigate, so thanks for mentioning it.
The way to use it is:
1) compile your program with the -g switch:
gcc -g -o myprogram myprogram.c
2) run your program (valgrind will make this rather slow):
valgrind --tool=callgrind ./myprogram any optional parameters for myprogram
3) run kcachegrind on the generated callgrind.out.<pid>:
kcachegrind callgrind.out.8759
The callee map in kcachegrind quickly shows in which functions your program spends most CPU and you can study how much time is spent in each line of source code. With graphviz dot installed you will also get a call graph.
just a small note to report that firefox and thunderbird (also the versions in the repo) FTB with the newer cbindgen (0.24.x, installed via the build-deps script)
Rationale: one less in-house software (mkinitrd and associated scripts) to maintain. I will check it usage during installation and following a kernel upgrade.
EDIT. let's give two examples:
To embed a LUKS keyfile in the initrd and have it used by init, I had to modify init.
To make a "generic" initrd (not tied to the host where mkinitrd ran) I had to find out which modules to include.
Using dracut this is just a matter of editing a config file and/or providing command-line options.
Last edited by Didier Spaier; 06-13-2022 at 04:21 AM.
Rationale: one less in-house software (mkinitrd and associated scripts) to maintain. I will check it usage during installation and following a kernel upgrade.
EDIT. let's give two examples:
To embed a LUKS keyfile in the initrd and have it used by init, I had to modify init.
To make a "generic" initrd (not tied to the host where mkinitrd ran) I had to find out which modules to include.
Using dracut this is just a matter of editing a config file and/or providing command-line options.
I don't understand (my weak english perhaps).
For 1 I had no change to do in init script.
For 2 it's a matter of how generic you wanna be.
For both you could have sane defaults in /etc/mkinitrd.conf
I might be wrong and would be thankful if you could shed some light...
Edit : misread the 1. But what is the point to encrypt while you give the key ??
I am going to release GRUB 2.12 around October 2022.
I am not going to release any of earlier released versions with recent security fixes on top of them.
Good guys, too bad for GRUB.
Escape who can!
Debian patch folder.
Well, in the initrd root exists a script named "init" which is automatically executed by the kernel.
Quote:
Originally Posted by Tonus
For 2 it's a matter of how generic you wanna be.
Well, a common misconception is that you should hard code in the initrd which root partition you have.
In fact, you can specify in the bootloader configuration a series of parameters passed to initrd: root, rootfs and rootflags, which usually are enough for a "generic" initrd to do its job for the usual systems.
For further options, someone may need to modify the initrd's init script, then the mkinitrd package.
Quote:
Originally Posted by Tonus
For both you could have sane defaults in /etc/mkinitrd.conf
Well, dracut (and any other initrd systems) used by the major distributions are very modular and configurable things.
Quote:
Originally Posted by Tonus
Edit : misread the 1. But what is the point to encrypt while you give the key ??
Maybe the Russians have a particular rich imagination, but I can imagine instantly an example: how about a bootable USB dongle, which automatically decrypt the hard drive or its partitions? Walking away with the USB dongle will leave the box in an unbootable and undecryptable state.
However, unfortunately I do not believe that Dracut will be adopted. Because looks that they do not have so much consideration for initrds.
Last edited by LuckyCyborg; 06-13-2022 at 09:33 AM.
I don't understand (my weak english perhaps).
For 1 I had no change to do in init script.
You do, to embed the LUKS key in the initrd (as you realized, cf. your edit)
Quote:
For 2 it's a matter of how generic you wanna be.
My goal was (and still is) to make Slint portable if installed on a removable drive, i.e. be usable with the drive plugged in on pretty much any computer. To do that using dracut you just have to type as root:
Code:
dracut
Using mkinird instead I had to cook a rather fragile code snippet
Code:
portable() {
[ ! "$PORTABLE" ] && return
echo "portable" >>$INSTALL/log
echo "The presence of this file indicates that this system should be portable." > $SLINT/etc/portable
rootdelay=10
KERNELVERSION=$(ls $SLINT/boot/vmlinuz-generic-*|cut -d- -f3)
HOST_AND_STORAGE=$(find $SLINT/lib/modules/$KERNELVERSION/kernel/drivers/ -name "*.ko"|grep -e "/storage/" -e "/host/" -e "/core/"|grep -v -e /staging/ -e /inifiniband/|sed "s,.*/,,;s/.ko//;s/$/:/"|tr -d '\n')
FS="btrfs:ext2:ext4:f2fs:jfs:reiserfs:xfs:crc32_generic:crc32_pclmul:"
USB_KBD="uhci-hcd:usbhid:"
MODENCRYPT="af_alg:algif_skcipher"
FSTYPE=$(cat $INSTALL/fstype)
DRIVEPATH=$(cat $INSTALL/drivepath)
sed "/GRUB_DISABLE_OS_PROBER/s/.*/GRUB_DISABLE_OS_PROBER=true/" $SLINT/etc/default/grub >bof
mv bof $SLINT/etc/default/grub
if [ "$ENCRYPT" ]; then
sed "/#GRUB_ENABLE_CRYPTODISK/s/.*/GRUB_ENABLE_CRYPTODISK=y/
/GRUB_PRELOAD_MODULES/s/.*/GRUB_PRELOAD_MODULES=\"luks cryptodisk\"/
/^GRUB_DISABLE_LINUX_PARTUUID/s/.*/GRUB_DISABLE_LINUX_PARTUUID=true/
/^GRUB_DISABLE_LINUX_UUID/s/.*/GRUB_DISABLE_LINUX_UUID=false/" $SLINT/etc/default/grub >bof
mv bof $SLINT/etc/default/grub
fi
MODULES="$HOST_AND_STORAGE$FS$USB_KBD$MODENCRYPT"
chroot $SLINT grub-install --target=i386-pc $DRIVEPATH 1>>$INSTALL/log 2>>$INSTALL/errors
chroot $SLINT grub-install --target=x86_64-efi --no-nvram --bootloader-id=slint $DRIVEPATH 1>>$INSTALL/log 2>>$INSTALL/errors
mkdir -p $SLINT/boot/efi/EFI/BOOT
cp $SLINT/boot/efi/EFI/slint/grubx64.efi $SLINT/boot/efi/EFI/BOOT/BOOTx64.EFI
echo "EFI\slint\grubx64" > /SLINT/boot/efi/startup.nsh
lsblk -l -o uuid,type,name|grep part| \
sed "s, *\([^ ]*\) *[^ ]* *\([^ ]*\).*,s;/dev/\2;UUID=\1;," > $SLINT/tmp/part_list
chroot $SLINT geninitrd 1>>$INSTALL/log 2>>$INSTALL/errors
if [ "$ENCRYPT" ]; then
chroot $SLINT cp -a /etc/keys/root$KEYFILE /boot/initrd-tree/$KEYFILE
chroot $SLINT mkinitrd \
-k $KERNELVERSION \
-m $MODULES \
-K /$KEYFILE \
-C UUID=$(cat $INSTALL/rootcryptuuid):cryptroot \
-w $rootdelay \
-r UUID=$(cat $INSTALL/rootuuid) \
-o /boot/initrd-generic-$KERNELVERSION 1>>$INSTALL/log 2>>$INSTALL/errors
else
# we run mkinitrd again (after geninitrd) to include the setting
# -w rootdelay and the modules
chroot $SLINT mkinitrd \
-k $KERNELVERSION \
-w $rootdelay \
-m $MODULES \
-o /boot/initrd-generic-$KERNELVERSION 1>>$INSTALL/log 2>>$INSTALL/errors
fi
cat <<-EOF >>$SLINT/etc/grub.d/40_custom
menuentry "Detect and boot installed operating systems" {
set sg2d_directory="/boot/grub"
export sg2d_directory
configfile "/boot/grub/main.cfg"
}
EOF
( cd $ISO/boot/grub/
cp osdetect.cfg tools.cfg main.cfg grub-mkrescue-sed.sh \
$SLINT/boot/grub/
)
chroot $SLINT /usr/sbin/update-grub 1>>$INSTALL/log 2>>$INSTALL/errors
cat <<-EOF >> $SLINT/tmp/post-install
if [ ! -f /etc/fstab.orig ]; then
cp /etc/fstab /etc/fstab.orig
fi
sed -f /tmp/part_list /etc/fstab > dummy
mv dummy /etc/fstab
sed "/# Initially/d" /etc/fstab > dummy
mv dummy /etc/fstab
EOF
chmod 0755 $SLINT/tmp/post-install
chroot $SLINT /tmp/post-install 1>>$INSTALL/log 2>>$INSTALL/errors
}
I'd like to make this simpler, more robust and needing less maintenance
Quote:
For both you could have sane defaults in /etc/mkinitrd.conf
I'd be pleased to see these sane defaults...
Quote:
I might be wrong and would be thankful if you could shed some light...
I hope this post answers that.
Quote:
Edit : misread the 1. But what is the point to encrypt while you give the key ??
The key is typed by the user during installation. Indeed it can easily be stolen if the system is running unattended. But in this case anyone having physical access to the machine can do anything with it anyway.The use case I have in mind is rather "my (fully shut down) laptop (or the drive) is stolen while traveling". Then the drive is fully protected, as the initrd is in the root partition, which itself is inside a LUKS encrypted device (decrypted by grub when you type the passphrase before displaying its boot menu).
PS Didn't see the answer from LuckyCyborg before posting.
PS2 Je pourrais écrire en Français (plus facile pour toi comme pour moi) mais c'est interdit par le réglement...
Last edited by Didier Spaier; 06-13-2022 at 11:13 AM.
Good guys, too bad for GRUB.
Escape who can!
Debian patch folder.
Yes I have seen this message from Daniel. And I assume that applying the zillion patches from Debian is too demanding in terms on manpower for Slackware, considering that a cherry pick would be in order as some are for contexts or architectures not in Slackware scope. Further Patrick would need to update the patches too when Debian does it. Too much work for little benefit in my opinion, hence my proposal to just pull from git up to a specific commit, without taking any not yet upstream-ed patch. I would not recommend that for other software, but having followed GRUB development since several years I am pretty sure Daniel would not apply any proposed patch set without a good rationale, a good documentation and serious testing and review.
Last edited by Didier Spaier; 06-13-2022 at 10:39 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.