All Activity

Adobe is releasing an update with bug fixes and new features for end users described in the New features summary as well as security updates for Acrobat and Reader. The security updates provide mitigations for vulnerabilities described in the security bulletins of Reader and Acrobat. Update or Complete Download Adobe Acrobat and Reader are being updated to version 24.005.20320. Updates should become available via the internal updater or checks can be manually activated by choosing Help/Check for Updates. Reader DC and other versions are available here: https://get.adobe.com/reader/ Note: UNcheck any pre-checked additional options presented with the update. They are not part of the software update and are completely optional. Release Notes

The Microsoft December 2024 security updates have been released and consist of 71 new patches to Microsoft products. Of the Microsoft CVEs released, 16 are rated critical, 54 important, and 1 moderate in security. At the time of release, one is listed as being publicly known and as being exploited. The security updates apply to the following products, features and roles: Windows and Windows Components, Office and Office Components, SharePoint Server, Hyper-V, Defender for Endpoint, and System Center Operations Manager. See the list of KBs at the bottom of the page at December 2024 Security Updates - Release Notes - Security Update Guide - Microsoft for information regarding known issues with the security updates as well as the CVEs with FAQs, Mitigations and/or Workarounds. Recommended Reading: See Dustin Childs review and analysis in Zero Day Initiative -- The December 2024 Security Update Review. Due to the holiday schedule, there will be no December 2024 non-security preview update.

Another update on Manjaro without issues. I used Pamac to do the update. [ray@ray-virtualbox ~]$ inxi -Fxz System: Kernel: 6.11.10-2-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 14.2.1 Desktop: Xfce v: 4.18.1 Distro: Manjaro base: Arch Linux Machine: Type: Virtualbox System: innotek GmbH product: VirtualBox v: 1.2 serial: <superuser required> Mobo: Oracle model: VirtualBox v: 1.2 serial: <superuser required> BIOS: innotek GmbH v: VirtualBox date: 12/01/2006 CPU: Info: dual core model: 11th Gen Intel Core i7-11700 bits: 64 type: MCP arch: Rocket Lake rev: 1 cache: L1: 160 KiB L2: 1024 KiB L3: 32 MiB Speed (MHz): avg: 2496 min/max: N/A cores: 1: 2496 2: 2496 bogomips: 9988 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 Graphics: Device-1: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter vendor: VMware driver: vboxvideo v: kernel bus-ID: 00:02.0 Display: x11 server: X.org v: 1.21.1.14 driver: X: loaded: modesetting gpu: vboxvideo resolution: 1920x974~60Hz API: EGL v: 1.5 drivers: swrast platforms: active: x11,surfaceless,device inactive: gbm,wayland API: OpenGL v: 4.5 vendor: mesa v: 24.2.8-arch1.1 glx-v: 1.4 direct-render: yes renderer: llvmpipe (LLVM 18.1.8 256 bits) Audio: Device-1: Intel 82801AA AC97 Audio vendor: Dell driver: snd_intel8x0 v: kernel bus-ID: 00:05.0 API: ALSA v: k6.11.10-2-MANJARO status: kernel-api Server-1: JACK v: 1.9.22 status: off Server-2: PipeWire v: 1.2.7 status: active Network: Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 v: kernel port: d020 bus-ID: 00:03.0 IF: enp0s3 state: up speed: 1000 Mbps duplex: full mac: <filter> Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge driver: piix4_smbus v: N/A port: N/A bus-ID: 00:07.0 Drives: Local Storage: total: 20.15 GiB used: 12.04 GiB (59.8%) ID-1: /dev/sda vendor: VirtualBox model: VBOX HARDDISK size: 20.15 GiB Partition: ID-1: / size: 19.66 GiB used: 12.04 GiB (61.3%) fs: ext4 dev: /dev/sda1 Swap: Alert: No swap data was found. Sensors: Src: lm-sensors+/sys Message: No sensor data found using /sys/class/hwmon or lm-sensors. Info: Memory: total: 6 GiB available: 5.77 GiB used: 1.48 GiB (25.6%) Processes: 183 Uptime: 6m Init: systemd Packages: 1087 Compilers: gcc: 14.2.1 Shell: Bash v: 5.2.37 inxi: 3.3.36 [ray@ray-virtualbox ~]$

Updated MX without any problems today.

Mozilla sent Firefox Version 133.0.3 to the Release Channel. Fixed Fixed the missing scrollbar in the Library window, such as when viewing History or Bookmarks. (Bug 1934482).Fixed a problem where toolbar buttons were not visible on mouseover when using both the Windows High Contrast theme and the Firefox System theme. (Bug 1930840)Fixed blurry line drawing on some Canvas elements when hardware acceleration is enabled. (Bug 1933668).Fixed incorrect Firefox window positioning on Windows when restoring from maximized. (Bug 1934238). Update: To get the update now, select "Help" from the Firefox menu, then pick "About Firefox". Mac users need to select "About Firefox" from the Firefox menu. For non-English versions, Fully Localized Versions are available for download. Release Notes

It's really like playing whack-a-mole. About the only thing we can be sure of is that some sort of corruption occurs during updates. It seems to be worse if a kernel upgrade is indicated. I doubt that there is a foolproof remedy. If I absolutely had to run a Linux VM in Windows I think I would choose a different virtualization solution - VMWare maybe. And my choice of distro would be probably Debian-based. All this "learning" has convinced me that "one PC - one O/S" is the better way to go. You can test a distro in a VM but the only way to be sure is to actually install it. If you need to run Windows as a guest in Linux, you have better options.

I checked my Endeavour VM and the date/time were exactly as the host system, despite not using EndeavourVM since Dec 1. Safe to say that Endeavour doesn't exhibit the described time/date symptoms that I notice in my Arch & Manjaro VMs. Sorry we're not making more progress toward solving the case, but we are crossing suspects off the list.

Checked time and the VM is exactly the same as the host. No asymmetry at all.

OK I'll check on the clock when I next boot up the VM. It seems that about the only common theme is that in the process of updating the installation certain files get corrupted. The symptoms of that corruption vary though. This is the first time I got the errors about conflicting files. Also I was able to force through the update but in the process the kernel was borked. But then I was able to recover with the help of the ISO and I haven't been able to do that before. The use of --overwrite is a blunt force object and I wouldn't want to do that on any system that was important to me.

that IS interesting. this seems to prove the theory that local package database and mirror repos are somehow conflicting. Referencing my prior post about the time/date in Arch VM taking a while to sort itself when I open the Arch VM, I'm thinking there's a clue in that post; in that the LOCAL package database time/date is out of sync with mirror time/date. This doesn't happen with bare-metal installs, because they're constantly synced in "real time". But my Arch VM takes awhile to sync the correct time/date, so I usually manually intervene to force the updated time/date. I only experience this in my Arch-related VMs. My Debian/'Buntu VMs sync the correct date/time immediately upon opening the VM, no matter how long it's been since I last opened the VM. That's my latest theory... Now that you have Endeavour repaired, and know how to keep it going in VirtualBox, may I ask that you pay attention to the date/time of the VM, in relation to the ACTUAL date/time. Let's test THAT theory?!

I might add that I just upgraded my old Lenovo Flex2-15D that runs EOS on the rails and it went as smooth as could be.

I found your website interesting, Mel. I'm a hands on kind of guy myself, but it took the form of a radio electronics hobby, some 61 years now. I love to design and build gear. RV'ing looks like a lot of fun! Many of the radio amateur operators who RV take their radios along with them. And there is also an interesting sub group of them who like to 'operate QRP'. This means voluntarily limiting transmitter output power to 5 watts or less. (Normal is around 100W). I did some limited tent camping in my Boy Scout days, enjoyed it always. But RV'ing brings it to a higher level of comfort for sure. Must be really neat to scout out all those parks all over the west! Clutter

Well this has been interesting. I attempted a large update with pacman -Syyu and got a number of failed to commit transaction (conflicting files) So I did a forced overwrite sudo pacman --overwrite "*" -Syyu Everything seemed to work OK but then when rebooted there was a problem with the kernel and the system would not boot. So I did arch-chroot from the ISO and used dracut-rebuild to fix the kernel and then reinstalled GRUB and configured GRUB. Now reboot from the system drive works again. There is still some weirdness going on in VirtualBox.

I hear ya Clutter I still cam do a hard days work although a bit slower. LoL! I to still climb on rv roofs to install solar systems for myself and friends. I do a lot of upgrades, mods and repairs to rv's Mostly ones I've owned. To see go to my website. CLICK HERE Mel 86 years strong

Hey Mel....if you reverse your age, that's me. I turned 68 at the end of August. To quote abarbarian, "Hope I get to 86 with all me marbles." Here's to your continued good health! I hope you had a nice Thanksgiving. And now we can look forward to Christmas.... Take care.

The only things I would be interested in buying from the "incompatible" Windows 10 universe are very high-end Thinkpads, Dell Latitudes, or HP Elitebooks in absolutely Grade A condition. I have already been gifted a consumer-grade HP machine that I upgraded a bit with an SSD, and I have another quad-core pre-Ryzen AMD laptop. Both of these work great with Linux. If your preference is Windows 11, good refurbished machines are available at decent prices. I cannot see any reason to go for an older Skylake-powered Thinkpad unless you want it as a Linux machine.

Also: https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported

Reflector can automate this on every pacman upgrade:

That's what rankmirrors is for: https://wiki.archlinux.org/title/Mirrors#List_by_speed it's been a part of pacman for over a decade and mentioned in the installation guide.

Not sure how Arch ranks mirrors (distance between ISPs? Ping speeds?) but my theory is that Ray is between 2 mirrors, and those mirrors are on 2 different sync schedules; so Ray is only getting partial upgrades when he syncs packages on his VM. This is only a problem for guys like us, who only run a VM on occasion; and that VM is a rolling release. In that use-case scenario, I think using the -yy flag to sync and upgrade is ESSENTIAL. Especially when Ray has reproduced his failure multiple times, and the -yy flag prevents the failure (so far, knock on wood!). I wonder if Ray's experience can be tied to an observation of MY Arch VM. As already stated, I built my Arch VM in VirtualBox years ago, and migrated it to VMM (thanks SB for the recommendation!), where it has continued to perform without issue...probably going on close to 10 years now?! Typically, I do not shutdown when I exit, nor reboot when I start; I only do that when new kernel presents. Other than those cases, I usually just exit by "save the state" and start from the "saved state" when opening. I have noticed that the Arch VM re-opens from the prior date of the prior session. And I do have NTP enabled. If I let the Arch VM "idle" long enough, the date will sort itself; sometimes in a minute, sometimes in 5 minutes, sometimes much longer. (it's not really idle, it's busy in the background...but I use the word idle to mean that I refrain from doing anything) I'm usually opening ArchVM simply to update/upgrade, and I can't be waiting extended periods for Arch to sort its date, which is kinda critical to the process, so I take to the CLI and manually adjust the time, then switch back to NTP before commencing with the update/upgrade. If I were doing this more frequently, like every day, every other day, or every week, perhaps it wouldn't even be an issue. But Arch notices and gets fussy when the internal clock says Nov 1 (the prior session) and the current date is Dec 1. There is SOMETHING about Arch that causes it to be slow to update it's internal clock. I've got Arch, Debian, Lubuntu, OpenSUSE, Manjaro, Endeavour, Vanilla, and Windows VMs. Only Arch, Manjaro, and Windows exhibit the delay in updating the date/time to current date/time. Maybe Endeavour, but I haven't run it long enough to say for certain. All others update the date/time within seconds of opening the VM. Any idea why Arch is slower (lower priority?) to update the date/time when VM is re-opened? Whatever the reason, I'm thinking that MAYBE Ray & I are experiencing the same issue with Arch in a VM. But it's not a problem for me because it's glaringly obvious to look at date/time and see the elapsed time differential, so I deal with THAT before I update/upgrade. It's a problem for Ray because he updates MUCH more frequently than I do, so the date/time differential isn't as obvious. This could also possibly tie into my theory about Ray being between 2 mirrors? Thoughts? Is it possible that Arch updates date/time differently than other distros? And THAT is the underlying issue? In the meantime, it seems that the -Syyu flags solve Ray's issue (knock on wood); but then the REAL question becomes "why does the repo database require re-syncing?" Seems like my observation regarding date/time in Arch would also explain the differences between a bare-metal and VM installation?

Hello, I suspect the sell-off won't begin to happen in earnest until we are a little closer to the Windows 10 EOL date. Regards, Aryeh Goretsky

Anyway, if it works whatever