In reply to @wjvcyxnsbj:mozilla.org
see this 24.04.1 OEM provisioning flow

Many thanks for your help @mei, can confirm I've got this working thanks!

Do you know if there's a way I can update GRUB before installing OEM Ubuntu 24.04? I have a problem where my DVD player doesn't seem to get picked unless I "Replace quiet splash with nomodeset" (following: https://linuxmint-installation-guide.readthedocs.io/en/latest/boot_options.html#nomodeset-boot-option)

Thanks again!

In reply to @wjvcyxnsbj:mozilla.org
see this 24.04.1 OEM provisioning flow

Many thanks for your help @mei , can confirm I've got this working thanks!

Do you know if there's a way I can update GRUB before installing OEM Ubuntu 24.04? I have a problem where my DVD player doesn't seem to get picked unless I "Replace quiet splash with nomodeset" (following: https://linuxmint-installation-guide.readthedocs.io/en/latest/boot_options.html#nomodeset-boot-option)

Thanks again!

Many thanks for your help @mei , can confirm I've got this working thanks!

Do you know if there's a way I can update GRUB before installing OEM Ubuntu 24.04? I have a problem where my DVD player doesn't seem to get picked unless I "Replace quiet splash with nomodeset" (following: https://linuxmint-installation-guide.readthedocs.io/en/latest/boot_options.html#nomodeset-boot-option)

Thanks again for any help!

In reply to @ashugg:matrix.org
What CIFS errors are you seeing lilnospig ?

In reply to @eduardo976095:matrix.org
My Lenovo laptop gives errors when activating the TPM and SECURE BOOT, that is, it detects them but does not finish configuring correctly, and it stays on the Lenovo screen for several seconds when it turns on as if it were searching for the system. I don't know if that is normal because it didn't happen to me with Windows.

@eduardo976095:matrix.org I followed this how-to and I was able to use Secure Boot and TPM in my Lenovo

In reply to @lilnospig:matrix.org
Several different ones. I get this one quite a lot: 'kernel: CIFS: VFS: No writable handle in writepages rc=-9' and in digging through the logs more deeply, I am seeing: 'kernel: CIFS: VFS: \X.X.20.28 Error -104 sending data on socket to server', 'kernel: CIFS: VFS: Send error in read = -512'. I have 18 of these VMs and they are all doing something like this. I also have Ubuntu 20.04 connected with the same application to the same NAS, same shares, etc and not getting the same issues. I have not looked to see if there errors are in there logs yet (another 12 physical servers), but the application that uses the shares is the same on both sets.

In reply to @ashugg:matrix.org
I have not seen this happen myself. What is your NAS backend? From a look with Google most of the useful hits for "No writable handle in writepages rc=-9" that I found were from proxmox users with VMs on a Synology or TrueNAS Core - one person apparently resolved the issue by fixing their network routing (that sounded strange) and another, with TrueNAS Core, said upgrading to TrueNAS Scale (essentially FreeBSD -> Linux) gave them a newer Samba version on the NAS and that is what they think fixed it.

In reply to @lilnospig:matrix.org
Well the VMS are sitting on 3 different identical physical servers (6VMs each), Bonded 10G nics, etc. I still have plenty of hardware available. I'll verfiy the route with the customer but it should be switch> router> switch for NAS in the same rack. As for the NAS itself, its a dell powerscale A300 cluster with 16 servers. I can reach out to dell about an update, its just weird I do not see the issues on the Ubuntu 20.04 devices. I am also getting oom_killer errors, but if the NAS is not available to write to, it'll only cache that data for so long before it has to drop it. I also did some googling, which took me to the kernel option. The mounts are created via the software we are using, but their api shows they are using mount.cifs ... at the kernel level. Which is why I ended up here. Its an issue I've been trying to work out with the software company but they keep pointing to something outside their code, making it my problem. The only thing that really stands out to me that has changed was there was a NIC driver on the base host that updated and changed the NIC names. I had to reconfigure the netplan files for those 3 host servers. Any ideas?

There are so many differences between the Linux kernel releases used by Ubuntu 20.04 and Ubuntu 22.04 that working this out could be quite difficult. It does seem though that the Ubuntu 22.04 kernel is encountering something with the Dell PowerScale A300's SMB share that it doesn't like.

So looking at the facts as I understand them:

(1) The Ubuntu 20.04 and 22.04 VMs run on 3 identical physical servers
(2) Inside these Ubuntu 20.04 and 22.04 VM guests, you have a software that makes use of the SMB share(s) provided by the Dell PowerScale A300 cluster
(3) Kernel error messages are being reported on the Ubuntu 22.04 VMs but not the Ubuntu 20.04 VMs

And you've implied, but can you please elaborate on this?

(4) Problems are encountered on the Ubuntu 22.04 VMs but not on the Ubuntu 20.04 VMs

i.e. the kernel messages are not harmless, there is something actually going wrong? What's going wrong?

Yes, mounting SMB shares is handled at the kernel level and is invoked by mount.cifs

Also assuming x86_64 architecture, the generic GA kernel, and Ubuntu Server not Ubuntu Desktop, on both sets of VMs.

Is the software in question - whatever it is - being sold to the customer with any warranty or under a support or maintenance agreement? Is Ubuntu 22.04 confirmed to be a supported platform by the software company? Is Dell's PowerScale A300 confirmed to be a supported platform by the software company? If so, I'd be (nicely) pushing it back on them as much as possible. If your role is to be the system integrator or the solution provider, and your vendor says "our product works with X" and then it doesn't work with X, they do rather put you in an embarrassing position after you've already on-sold the solution to the customer.

If the software company's position is that you're on your own, and good luck, then yes do check with Dell about any possible updates for the PowerScale A300.

How about the virtualisation platform that the Ubuntu VMs are running in? Does it support Ubuntu, and does Canonical support Ubuntu on that virtualisation platform?

I would also consider the following:

• confirm the Ubuntu 22.04 VMs are up-to-date ("linux-image-virtual" package version 5.15.0.124.124, "cifs-utils" package version 2:6.14-1ubuntu0.1)
• check SMB protocol version used by the kernel mount of the SMB share on both Ubuntu 20.04 and Ubuntu 22.04, "cat /proc/mounts" should reveal this, if Ubuntu 20.04 is using smb 2.1 but 22.04 is using smb 3.0, try remounting the share on 22.04 using the "vers=2.1" mount argument
• the HWE (hardware enablement) kernel package provides a newer kernel for the OS - does using the HWE kernel on Ubuntu 20.04 (kernel 5.15 instead of 5.4) cause the problems to start occurring, and/or does using the HWE kernel on Ubuntu 22.04 (kernel 6.8 instead of 5.15) cause the problems to stop occurring?
• can you try Ubuntu 24.04 as a VM and see if the problem occurs there?

You can check whether the system is using the HWE kernel with "hwe-support-status --verbose" as well as checking version numbers in "uname -a" against the Ubuntu kernel lifecycle chart (https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle).

I hope that these various suggestions help you eliminate wrong answers one by one until you find the right thing. You can also consult the Ubuntu Kernel FAQ (https://wiki.ubuntu.com/Kernel/FAQ) which tells you how to talk to the Ubuntu Kernel team - at the moment that says it's only IRC, but they also have a room on here (https://matrix.to/#/#kernel:ubuntu.com) so maybe check in both places.

If there are significant stakes on the line (money, reputation) I would also consider getting Ubuntu Pro + Infra Support subscriptions from Canonical for enterprise support (https://ubuntu.com/support). My suggestions are just offered voluntarily by a random internet person.

Good luck!