raymac46 Posted November 20 Author Posted November 20 I am now not posting from my Windows machine which hosts EOS so I cannot reveal the grub.cfg. But I did modify and update GRUB so it is there and running. When I get a chance I'll do that. I'll check and see if I can get to TTY as well. Quote
raymac46 Posted November 20 Author Posted November 20 [ray@ray-virtualbox ~]$ sudo cat /boot/grub/grub.cfg [sudo] password for ray: # # DO NOT EDIT THIS FILE # # It is automatically generated by grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### insmod part_gpt insmod part_msdos if [ -s $prefix/grubenv ]; then load_env fi if [ "${next_entry}" ] ; then set default="${next_entry}" set next_entry= save_env next_entry set boot_once=true else set default="0" fi if [ x"${feature_menuentry_id}" = xy ]; then menuentry_id_option="--id" else menuentry_id_option="" fi export menuentry_id_option if [ "${prev_saved_entry}" ]; then set saved_entry="${prev_saved_entry}" save_env saved_entry set prev_saved_entry= save_env prev_saved_entry set boot_once=true fi function savedefault { if [ -z "${boot_once}" ]; then saved_entry="${chosen}" save_env saved_entry fi } function load_video { if [ x$feature_all_video_module = xy ]; then insmod all_video else insmod efi_gop insmod efi_uga insmod ieee1275_fb insmod vbe insmod vga insmod video_bochs insmod video_cirrus fi } if [ x$feature_default_font_path = xy ] ; then font=unicode else insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 70524857-0e37-463c-9378-d543035d3859 else search --no-floppy --fs-uuid --set=root 70524857-0e37-463c-9378-d543035d3859 fi font="/usr/share/grub/unicode.pf2" fi if loadfont $font ; then set gfxmode=auto load_video insmod gfxterm set locale_dir=$prefix/locale set lang=en_CA insmod gettext fi terminal_input console terminal_output gfxterm insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 70524857-0e37-463c-9378-d543035d3859 else search --no-floppy --fs-uuid --set=root 70524857-0e37-463c-9378-d543035d3859 fi insmod png background_image -m stretch /usr/share/endeavouros/splash.png if [ x$feature_timeout_style = xy ] ; then set timeout_style=menu set timeout=5 # Fallback normal timeout code in case the timeout_style feature is # unavailable. else set timeout=5 fi ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/10_linux ### menuentry 'EndeavourOS Linux' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-70524857-0e37-463c-9378-d543035d3859' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 70524857-0e37-463c-9378-d543035d3859 else search --no-floppy --fs-uuid --set=root 70524857-0e37-463c-9378-d543035d3859 fi echo 'Loading Linux linux-lts ...' linux /boot/vmlinuz-linux-lts root=UUID=70524857-0e37-463c-9378-d543035d3859 rw nowatchdog nvme_load=YES loglevel=3 spectre_v2=off echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-lts.img } submenu 'Advanced options for EndeavourOS Linux' $menuentry_id_option 'gnulinux-advanced-70524857-0e37-463c-9378-d543035d3859' { menuentry 'EndeavourOS Linux, with Linux linux-lts' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-lts-advanced-70524857-0e37-463c-9378-d543035d3859' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 70524857-0e37-463c-9378-d543035d3859 else search --no-floppy --fs-uuid --set=root 70524857-0e37-463c-9378-d543035d3859 fi echo 'Loading Linux linux-lts ...' linux /boot/vmlinuz-linux-lts root=UUID=70524857-0e37-463c-9378-d543035d3859 rw nowatchdog nvme_load=YES loglevel=3 spectre_v2=off echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-lts.img } menuentry 'EndeavourOS Linux, with Linux linux-lts (fallback initramfs)' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-lts-fallback-70524857-0e37-463c-9378-d543035d3859' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 70524857-0e37-463c-9378-d543035d3859 else search --no-floppy --fs-uuid --set=root 70524857-0e37-463c-9378-d543035d3859 fi echo 'Loading Linux linux-lts ...' linux /boot/vmlinuz-linux-lts root=UUID=70524857-0e37-463c-9378-d543035d3859 rw nowatchdog nvme_load=YES loglevel=3 spectre_v2=off echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-lts-fallback.img } menuentry 'EndeavourOS Linux, with Linux linux' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-70524857-0e37-463c-9378-d543035d3859' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 70524857-0e37-463c-9378-d543035d3859 else search --no-floppy --fs-uuid --set=root 70524857-0e37-463c-9378-d543035d3859 fi echo 'Loading Linux linux ...' linux /boot/vmlinuz-linux root=UUID=70524857-0e37-463c-9378-d543035d3859 rw nowatchdog nvme_load=YES loglevel=3 spectre_v2=off echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux.img } menuentry 'EndeavourOS Linux, with Linux linux (fallback initramfs)' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-70524857-0e37-463c-9378-d543035d3859' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 70524857-0e37-463c-9378-d543035d3859 else search --no-floppy --fs-uuid --set=root 70524857-0e37-463c-9378-d543035d3859 fi echo 'Loading Linux linux ...' linux /boot/vmlinuz-linux root=UUID=70524857-0e37-463c-9378-d543035d3859 rw nowatchdog nvme_load=YES loglevel=3 spectre_v2=off echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-fallback.img } } ### END /etc/grub.d/10_linux ### ### BEGIN /etc/grub.d/20_linux_xen ### ### END /etc/grub.d/20_linux_xen ### ### BEGIN /etc/grub.d/25_bli ### if [ "$grub_platform" = "efi" ]; then insmod bli fi ### END /etc/grub.d/25_bli ### ### BEGIN /etc/grub.d/30_os-prober ### ### END /etc/grub.d/30_os-prober ### ### BEGIN /etc/grub.d/30_uefi-firmware ### if [ "$grub_platform" = "efi" ]; then fwsetup --is-supported if [ "$?" = 0 ]; then menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' { fwsetup } fi fi ### END /etc/grub.d/30_uefi-firmware ### ### BEGIN /etc/grub.d/40_custom ### # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. ### END /etc/grub.d/40_custom ### ### BEGIN /etc/grub.d/41_custom ### if [ -f ${config_directory}/custom.cfg ]; then source ${config_directory}/custom.cfg elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then source $prefix/custom.cfg fi ### END /etc/grub.d/41_custom ### [ray@ray-virtualbox ~]$ Quote
raymac46 Posted November 20 Author Posted November 20 Confirming when things are running OK I can use <Host>F1 to get to TTY1 and <Host>F2 to get back to the GUI. <HOST> for me is the right-Ctrl key. Quote
raymac46 Posted November 21 Author Posted November 21 (edited) I installed LightDM and lightdm-gtk-greeter but SDDM seems to be OK so far. However the other Display Manager is now available if needed. Haven't had any glitches for a couple of days. Edited November 21 by raymac46 1 Quote
Hedon James Posted November 22 Posted November 22 15 hours ago, raymac46 said: I installed LightDM and lightdm-gtk-greeter but SDDM seems to be OK so far. However the other Display Manager is now available if needed. Haven't had any glitches for a couple of days. Between this and TTY access, now you have some options for troubleshooting. Without TTY terminal access, you're kinda flying blind. I don't think you have an SDDM issue, but it can't be ruled out either. My SDDM issue was back in LXQT 0.14, and LXQT recently released 2.0....I noted the Endeavour version is 2.1. I'd like to believe SDDM black screen at boot issues have been resolved between those releases. It was a simple and stupid fix. As I recall, the login theme (a text file) wasn't copied to the proper directory. All I had to do was boot a LiveMedia, mount the installation drive, and copy a file from "locationA" to "locationB". Reboot, and there was the SDDM login manager. Later on, I found a cool login theme that I switched to quite easily. Which is probably why I noticed the Endeavour login theme and commented. I like it....something I would've done also. LOL! Saw another update with "linux header" in the list and took it. Watched dracut rebuild the kernel & modules and rebooted to test. No issues. 1 Quote
raymac46 Posted November 22 Author Posted November 22 So far all I have upgraded is a few gtk modules from the extra repo. Everything continues to work OK. I'm surprised at how few examples I have been able to find of folks running EOS in VirtualBox on Windows. I watched a YouTube video on how to do it, and the person did pretty much the same things as I did. No real problems mentioned in the EOS forum. In fact a Google search on installing EOS in VBox on Windows turned up this thread on Page 1 LOL. Quote
raymac46 Posted November 23 Author Posted November 23 I'm giving up. Another minor update crashed the eos-welcome screen and Firefox won't run because. /usr/lib/libtinysparq1.so.0 file too short Any attempt to rescue by rebuilding the kernel and/or reinstalling grub didn't work. I still have a GUI but it's not right. I conclude that some issues with yay/pacman and VBox are not reconcilable. Quote
securitybreach Posted November 23 Posted November 23 2 minutes ago, raymac46 said: I'm giving up. Another minor update crashed the eos-welcome screen and Firefox won't run because. /usr/lib/libtinysparq1.so.0 file too short Any attempt to rescue by rebuilding the kernel and/or reinstalling grub didn't work. I still have a GUI but it's not right. I conclude that some issues with yay/pacman and VBox are not reconcilable. Fix for error: https://bbs.archlinux.org/viewtopic.php?id=291861 Has nothing to do with VM 1 Quote
raymac46 Posted November 23 Author Posted November 23 Different lib but I get the idea. However the VM is not working well if I continue to get these corrupted updates. 'll use Endeavour OS on the rails where it works best. 2 Quote
Hedon James Posted November 23 Posted November 23 Bummer, but I understand. Wish we could figure out WHY it's corrupting. But even then we still don't know HOW to fix. Sometimes the fix is to wait for someone smarter to figure it out. I have also searched forums and find it surprising there is an overall lack of similar symptoms for win hosted vms of arch-based distros. Makes me wonder if the problem isn't unique to your host system/hardware and version of VB? Quote
raymac46 Posted November 23 Author Posted November 23 Might be. I am using the latest version of VBox (7.1.4) and my setup is a bog standard Dell desktop system with an Intel i7-11700 and 32GB RAM. Quote
raymac46 Posted November 23 Author Posted November 23 (edited) And don't forget that Debian based VMs are very stable for me and always have been. I also had trouble with EOS on a Linux based desktop system from 2013. There are some interactions I have that you don't in a VMM that isn't VirtualBox. Edited November 23 by raymac46 Quote
raymac46 Posted November 23 Author Posted November 23 Normally I wouldn't do this but I've installed Manjaro Xfce in VirtualBox. It is different enough from EOS but still has some elements of Arch in it. I'll see if it crashes after some updates. I'd really like to pin down VBox as the source of trouble. Quote
raymac46 Posted November 23 Author Posted November 23 [ray@ray-virtualbox ~]$ inxi -Fxz System: Kernel: 6.10.13-3-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: 9986 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.4-arch1.0.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.10.13-3-MANJARO status: kernel-api Server-1: JACK v: 1.9.22 status: off Server-2: PipeWire v: 1.2.5 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: 9.43 GiB (46.8%) ID-1: /dev/sda vendor: VirtualBox model: VBOX HARDDISK size: 20.15 GiB Partition: ID-1: / size: 19.66 GiB used: 9.43 GiB (48.0%) 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: 892.2 MiB (15.1%) Processes: 176 Uptime: 1m Init: systemd Packages: 1085 Compilers: gcc: 14.2.1 Shell: Bash v: 5.2.37 inxi: 3.3.36 [ray@ray-virtualbox ~]$ Quote
securitybreach Posted November 23 Posted November 23 9 hours ago, raymac46 said: It is different enough from EOS but still has some elements of Arch in it. Well Manjaro is like comparing Ubuntu to Debian whereas AntiX is more pure Debian. The same basically applies to Endeavor compared to Arch. Manjaro may use pacman and the AUR but that is only thing that is similar to Arch. They are on a different release model which isn't rolling like Arch. The same issues you will find on manjaro aren't present on arch, etc. 1 Quote
raymac46 Posted November 23 Author Posted November 23 I understand the difference. I'll start a new thread on this. 1 Quote
securitybreach Posted November 23 Posted November 23 4 minutes ago, raymac46 said: I understand the difference. I'll start a new thread on this. Cool Quote
Hedon James Posted November 23 Posted November 23 11 hours ago, raymac46 said: Normally I wouldn't do this but I've installed Manjaro Xfce in VirtualBox. It is different enough from EOS but still has some elements of Arch in it. I'll see if it crashes after some updates. I'd really like to pin down VBox as the source of trouble. FWIW, I have Arch & Manjaro VMs that I continue to update, roll forward, and keep an eye on for several years now (10ish?). Both were built in VBox, but migrated to VMM around 2020. When I migrated, I converted the VBox-native VDI disk formats to VMM-native qcow (qemu copy on write) formats. Both continue to update and operate without issue. And now I can add Endeavour to the list of Arch-based distros in my VM farm. I don't have the history (yet) that I have with Arch and Manjaro, but I have had 2-3 kernel updates and several reboots, with no issues whatsoever. Too soon to say with 100% confidence, but I'm about 90%-95% confident in the Endeavour VM. I think you have an issue with VBox, and possibly how it interacts with your Win host system. Focusing on your corrupted updates, the only other thing I can think of is maybe your virtual network device? I remember VBox provided a drop down menu for network device connection types, but can't remember the options...bridged? NAT? other? What are you selecting, and is it possible your selection is affecting your detected location, thereby choosing different/faulty mirrors than your bare metal install? Are you behind a VPN that rotates your "virtual" location, thereby causing mirror issues? Conversely, you have demonstrated that Endeavour/Arch on metal are non-issues. You have demonstrated that Debian-based VMs on Win host is a non-issue. With those 2 constants established: - can you install Endeavour on a VBox VM on a Linux host? this may indicate a Windows issue, versus VBox issue - assuming a Windows issue, do you have a 2nd Windows host that you can use for VM installation? this may indicate an issue specific to one PC hardware versus another You have tried several iterations of Endeavour VM on your machine, each with the same result; despite varying lengths of activity before you keep arriving at the same destination. I think another run at Endeavour on that machine is likely to yield the same result, AGAIN. IMO, I think you need to pull back to a larger, "macro" view and start considering that the issue may lie within Windows vs Linux, possibly VBox itself (depending on host), or possibly the hardware/software combination on the specific machine you keep duplicating failure with. (it's certainly reproducible!) For a chance at success, I think you need to get that hardware out of the equation. Not permanently, but specifically as it relates to this exercise in intellectual curiousity. JMO... With all that said, hope I'm not coming across as telling you what to do. I'm just trying to share my thoughts from our collective brain (RAID brain? LOL!). If anything in there sparks an idea....COOL. If it does not, feel free to disregard. This IS your project, but I'll keep playing along until you stop the project or I run out of ideas. LOL! 1 Quote
raymac46 Posted November 23 Author Posted November 23 I *have* installed EOS on a Linux host (LM22) and I had the same crashing issues. I am using NAT as my network adapter. Have done so for a long time. My other Windows machine does not have enough RAM to run VMs. I'll be setting up another thread with Manjaro in VBox on Windows 11 so as not to overcomplicate matters. 1 1 Quote
raymac46 Posted November 25 Author Posted November 25 Performed an update/upgrade on my EndeavourOS install on my old Lenovo laptop without any problems. EOS is stable when installed as a primary OS. 1 1 Quote
Hedon James Posted Sunday at 02:48 PM Posted Sunday at 02:48 PM December 1....time to upgrade my "rolling release VMs". Sometimes I forget, or am too busy to make time, and create problems to be solved because I waited too long. But not today....today I remembered. Updated Endeavour (and Arch, Manjaro, and OpenSUSE tumbleweed) with no issues. I saw the Endeavour LTS kernel updated to 6.6.63, as well as the alternative kernel 6.12.?? Once again, Endeavour recommended a reboot, as core packages had changed, so I rebooted when done. Logged back into Endeavour with no issues whatsoever. Checked for any additional stray updates, but there were none. EndeavourVM is up to date and good to go. If I don't update again in December, I'll do it on January 1 or as soon as possible near that date. But so far, performing as expected with no unforseen issues. 2 Quote
raymac46 Posted Sunday at 05:32 PM Author Posted Sunday at 05:32 PM Given that my copy of EOS in a laptop and yours in VMM are working well, I think we can conclude that the issue is between EOS and VBox. So far I haven't seen a problem with Manjaro in VBox. Quote
Hedon James Posted Sunday at 09:39 PM Posted Sunday at 09:39 PM 4 hours ago, raymac46 said: Given that my copy of EOS in a laptop and yours in VMM are working well, I think we can conclude that the issue is between EOS and VBox. So far I haven't seen a problem with Manjaro in VBox. didn't you also indicate problems with an Arch VM? If you have issues with Arch & Endeavour VMs, but not Manjaro, I would note that i think I remember Manjaro building it's own kernel, rather than using upstream Arch. If that turns out to be the case, I think a vanilla Arch kernel is the most likely explanation. And IF that is the case, I wonder if a 3rd party kernel, like Liquorix or Zen, or something else? Maybe build your own and pin it in the VM? Thinking out loud... https://wiki.archlinux.org/title/Kernel 1 Quote
securitybreach Posted Sunday at 09:47 PM Posted Sunday at 09:47 PM BTW Zen is officially supported and not 3rd party/unofficial like Liquorix. I personally use Zen on my desktop and hardened on my laptops and servers. Quote
raymac46 Posted yesterday at 12:48 AM Author Posted yesterday at 12:48 AM I used VBox to try installing Arch when I first became interested in the distro. However, I had the opportunity to install Arch on the rails with my Toshiba netbook back in 2017 or so. That installation is still running well. I may have had problems with Antergos when I tried that distro in VirtualBox - not Arch. Can't recall really. Manjaro has always worked fairly well for me in VBox - especially the Xfce flavor. The problem seems to be when things go south, that it's after an update that ends up corrupting a few shared libraries. Whether that is kernel related or module related or some other cause is still a mystery. Quote
Hedon James Posted yesterday at 02:52 PM Posted yesterday at 02:52 PM 13 hours ago, raymac46 said: I looked through that thread and find it interesting that you have always had problems with Arch (and Arch derivates) in a VM environment. It's interesting because it seems to be unique to you. That thread is 10 years old, and Arch is usually on the leading edge of solutions to problems. If your experience was widespread, Arch would've profferred a solution LONG ago, IMO. We have several Arch users here at BATL, but they're all running on metal hardware, not virtual environments. Are you and I the only ones here running Arch in VMs? And am I the only one running Arch derivates in VMM, rather than VB? Back to the 2014 thread....your symptoms haven't changed. Runs fine at installation, but gets borked at update. Made me think of something.....well, MAYBE something, maybe nothing. Early in my Arch learnings, I read an article (or a post?) that suggested that using -Syyu flags for updates was better than -Syu.....can't remember the reason....sync the mirrors before upgrading packages in a failsafe manner? Maybe one of the Arch users can comment? EDIT: Found a discussion referencing the difference. But as someone who runs Arch in VMs and only updates about 1x per month (sometimes 2x, if I'm on top of things; sometimes 1x every other month when I'm slacking and forgot! ) I adopted that convention from the beginning of my Arch tinkerings. That is how I update and upgrade my Arch VMs: sudo pacman -Syyu ALWAYS....EVERY time! And maybe that's a reason why my Arch VMs continue to run without issue, while yours gets corrupted in a reproducible manner. Or maybe I'm just using an extra "y" flag that does nothing, like a placebo?! Either way, I thought it worth mentioning. We have theorized that your mirrors get corrupted, or "unsync", which causes issues for pacman. Perhaps the extra flag would resolve that issue for you? It certainly can't "hurt" your system. At worst it does nothing for you; best case, it resolves your issue! Quote
securitybreach Posted yesterday at 02:58 PM Posted yesterday at 02:58 PM Well the Syyu was useful at one point when mirrors weren't updated as frequently. For years now, when you run Syu it also syncs the mirrors. I do have arch running on my VPS so its technically virtual but not using a virtual manager for my section of a blade server. Quote
Hedon James Posted yesterday at 03:02 PM Posted yesterday at 03:02 PM ^this MAY also explain your earlier attempt (in this thread) to sync mirrors and update Endeavour, which resulted in successful reboot for you. MAYBE? If I remember correctly, you are in Canada eh? Are you in an area where you are on the fringe of 2 different servers with your ISP? Possibly switching between ISP servers between VM boots, causing your mirrors to be out of sync? Theorizing that your metal installation doesn't have this issue because it is ONLINE, and mirrors sync in the background while using, or at rest; while the VM comes online for an update and....mirrors OUT OF SYNC...boom, issue.... Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.