SliTaz Forum
You are not logged in.
I have done an update from 5.10.238-slitaz64 (with working CIFS-Support) to 5.10.255-slitaz64 two days ago and then from 5.10.238-slitaz64 to 5.10.256-slitaz64 today.
Both updates performed well but afterwards CIFS-Support was missing ('modprobe cifs' fails).
Thanks for help or correction.
I have just noticed that reboot after update boots the old kernel. So the mix of modules of different kernel versions produces the CIFS-problem. Indeed manual boot of the new kernel shows CIFS-Support.
So this topic is solved.
Still open question is why grub boots my (virtualized) BIOS-based system into the old kernel. (I have manually updated grub.cfg with out success.)
Offline
Hi HDS,
Strange cifs module correctly builded, available on linux64-cifs package, do you reboot on new kernel ?
I tested in qemu, doing upgrade installed new kernel 5.10.256, infact i try load cifs modules failed because module for 5.10.256 and running 5.10.255, but if reboot module loaded sucessfully.
root@eretria:~# modinfo /home/slitaz/current64tazpkgng/chroot/home/slitaz/wok/linux64-cifs/taz/linux64-cifs-5.10.256/fs/lib/modules/5.10.256-slitaz64/kernel/fs/cifs/cifs.ko.xz
filename: /home/slitaz/current64tazpkgng/chroot/home/slitaz/wok/linux64-cifs/taz/linux64-cifs-5.10.256/fs/lib/modules/5.10.256-slitaz64/kernel/fs/cifs/cifs.ko.xz
softdep: gcm
softdep: ccm
softdep: aead2
softdep: sha512
softdep: sha256
softdep: cmac
softdep: aes
softdep: nls
softdep: md5
softdep: md4
softdep: hmac
softdep: ecb
version: 2.29
description: VFS to access SMB3 servers e.g. Samba, Macs, Azure and Windows (and also older servers complying with the SNIA CIFS Specification)
license: GPL
author: Steve French
alias: smb3
alias: fs-smb3
alias: fs-cifs
srcversion: 48612BA661BE2753817B245
depends:
intree: Y
name: cifs
vermagic: 5.10.256-slitaz64 SMP mod_unload
parm: CIFSMaxBufSize:Network buffer size (not including header) for CIFS requests. Default: 16384 Range: 8192 to 130048 (uint)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (uint)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (uint)
parm: cifs_max_pending:Simultaneous requests to server for CIFS/SMB1 dialect (N/A for SMB3) Default: 32767 Range: 2 to 32767. (uint)
parm: enable_oplocks:Enable or disable oplocks. Default: y/Y/1 (bool)
parm: enable_gcm_256:Enable requesting strongest (256 bit) GCM encryption. Default: n/N/0 (bool)
parm: require_gcm_256:Require strongest (256 bit) GCM encryption. Default: n/N/0 (bool)
parm: disable_legacy_dialects:To improve security it may be helpful to restrict the ability to override the default dialects (SMB2.1, SMB3 and SMB3.02) on mount with old dialects (CIFS/SMB1 and SMB2) since vers=1.0 (CIFS/SMB1) and vers=2.0 are weaker and less secure. Default: n/N/0 (bool)
Offline
Sorry Shan, I have seen your response only after me editing the post.
Offline
No problem HDS.
hmm strange, normally on post_install action for regenerate grub.cfg file if found.
post_install()
{
chroot "$root/" depmod -a $VERSION-slitaz64
# GRUB stuff.
if [ -f "$root/boot/grub/menu.lst" ]; then
root_dev=$(cat $root/boot/grub/menu.lst | grep root= | sed 's/.*root=\([^ ]*\).*/\1/' | head -n 1)
grub_dev=$(cat $root/boot/grub/menu.lst | grep "root (" | head -n 1)
# Add new kernel entry in case of upgrade for installed system.
if ! grep -q $PACKAGE-$VERSION-slitaz64 "$1/boot/grub/menu.lst"; then
cat >> "$1/boot/grub/menu.lst" <<EOT
title SliTaz GNU/Linux (Kernel $VERSION-slitaz64)
$grub_dev
kernel /boot/vmlinuz-$VERSION-slitaz64 root=$root_dev
EOT
fi
# Display information message.
cat <<EOT
----
GRUB is installed, these tree lines must be in your /boot/grub/menu.lst:
title SliTaz GNU/Linux (Kernel $VERSION-slitaz64)
$grub_dev
kernel /boot/vmlinuz-$VERSION-slitaz64 root=$root_dev
----
EOT
fi
# GRUB2 stuff.
for cfgfile in $(find $root/boot -name "grub.cfg"); do
grub-mkconfig -o $root/$cfgfile
done
}
Offline
You are right! The manually produced grub.cfg is identically with that modified by post_install.
Unfortunately the grub menu is never shown at boot time.(The virtual machine producing the problem is made from the iso-image slitaz-current64-core64-grub2.iso.)
Furthermore if version 5.10.256 is manually booted (by changing the grub boot command) system is coming up but complains about vbox-modules. Indeed the subdirectory misc of /lib/modules/5.10.256-slitaz64/kernel is missing (in contrast to /lib/modules/5.10.238-slitaz64/kernel).
Something seems going wrong during the update.
Offline
Hi HDS,
Thanks for report, for issue with grub menu don't display i need to check it.
For vbox-modules, it's my fault, i rebuild kernel and deploy it concerning last CVEs (copy-fail, dirty-frag, fragnesia, and last ssh-keysign-pwn), but forgot to rebuild virtualbox related modules.
Build in progress, when it's ok i push it to repo, sorry for issue with virtualbox
Offline
Thank you for the fast response.
I have done the slitaz-update on a virtual Slitaz-machine (UEFI) running Versioin 5.10.238.
There was no problem and on reboot the correct grub menu could be produced. So the grub menu seems to be a special one of my BIOS virtual system. I will examine this further.
Unfortunately there is a missunderstanding with respect to VirtualBox: I run my virtual machines under Fedora (not Slitaz). Therefore I miss virtualbox-ose-guestutils in the update!
Offline
I have run grub-install. I have to add --force Option since otherwise grub tells that it wont install in unreliable block mode.
Afterwards the grub menu shows up!
Hence this problem is solved.
Offline
Hello Shann,
I have just seen the package virtualbox-ose-guestutils in the repo. I installed it (together with virtualbox-ose-modules64 ) and everything is running smooth.
Thanks!
Offline
Hi HDS,
For grub, yes depend of disk, grub doesn't happy with block mode, for my laptop and my small server used for build "current/6.0", both use nvme and grub need installed with --force option.
you're welcome, when i see your post with virtualbox-ose-guestutils, i realized that not rebuild it 
.
Nice to see all work.
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.56 MiB (Peak: 1.77 MiB) ]