vault backup: 2026-01-05 13:03:55

2026-01-05 13:03:55 +08:00
parent 21460fc35d
commit be7c6cdcc9
589 changed files with 396508 additions and 27 deletions
@@ -0,0 +1,161 @@
+
+**Summary of the Problem and Solution**
+
+---
+
+### **Problem Overview**
+
+You were attempting to run an Oracle 11g Docker container using the command:
+
+```bash
+docker run -idt --name oracle -h oracle --privileged=true -p 1521:1521 -p 2222:22 \
+lhrbest/oracle_11g_ee_lhr_11.2.0.4:2.0 init
+```
+
+- **Issue Experienced:**
+  - The Docker container exited immediately after starting, without any error messages.
+  - The exit code was **139**, indicating a **segmentation fault (SIGSEGV)**.
+  - The issue occurred on a **Debian** system but not on **OpenSUSE**.
+
+---
+
+### **Root Cause**
+
+The segmentation fault was due to the way modern Linux kernels handle **`vsyscall`** (virtual system call):
+
+- **`vsyscall` Deprecation:**
+  - Modern kernels have deprecated `vsyscall` in favor of **vDSO** (virtual dynamic shared object) for security reasons.
+  - By default, `vsyscall` might be disabled or set to a mode incompatible with older applications.
+
+- **Impact on Oracle 11g:**
+  - Oracle 11g, being legacy software, relies on the old `vsyscall` mechanism for certain operations.
+  - Without proper `vsyscall` support, Oracle binaries can crash with a segmentation fault.
+
+- **Difference Between Systems:**
+  - **OpenSUSE** may have `vsyscall` support enabled or set to emulate by default.
+  - **Debian**, especially with newer kernels, has `vsyscall` disabled or set to a mode that doesn't support the required legacy behavior.
+
+---
+
+### **Solution**
+
+**Enable `vsyscall` Emulation on the Debian System:**
+
+1. **Verify Current `vsyscall` Mapping:**
+
+   ```bash
+   sudo grep vsyscall /proc/self/maps
+   ```
+
+   - If no output is returned, `vsyscall` is not currently mapped.
+
+2. **Edit GRUB Configuration:**
+
+   - Open the GRUB configuration file:
+
+     ```bash
+     sudo nano /etc/default/grub
+     ```
+
+   - Locate the line starting with `GRUB_CMDLINE_LINUX_DEFAULT`.
+
+   - Append `vsyscall=emulate` to the existing parameters within the quotes.
+
+     **Example:**
+
+     ```bash
+     GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vsyscall=emulate"
+     ```
+
+3. **Update GRUB Settings:**
+
+   - Apply the changes by updating GRUB:
+
+     ```bash
+     sudo update-grub
+     ```
+
+4. **Reboot the System:**
+
+   - Restart your machine to apply the new kernel parameter:
+
+     ```bash
+     sudo reboot
+     ```
+
+5. **Confirm `vsyscall` is Enabled:**
+
+   - After rebooting, check if `vsyscall` is now mapped:
+
+     ```bash
+     sudo grep vsyscall /proc/self/maps
+     ```
+
+   - You should see an output similar to:
+
+     ```
+     ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
+     ```
+
+6. **Run the Docker Container Again:**
+
+   - With `vsyscall` emulation enabled, attempt to start the Oracle container:
+
+     ```bash
+     docker run -idt --name oracle -h oracle --privileged=true --shm-size=2g \
+     -p 1521:1521 -p 2222:22 lhrbest/oracle_11g_ee_lhr_11.2.0.4:2.0 init
+     ```
+
+   - The container should now start successfully without exiting.
+
+---
+
+### **Explanation of the Solution**
+
+- **`vsyscall=emulate` Kernel Parameter:**
+  - Tells the kernel to emulate the old `vsyscall` behavior, allowing legacy applications to function correctly.
+  - Balances compatibility with security, as emulation is safer than direct mapping.
+
+- **Why It Works:**
+  - Restores the expected environment for Oracle 11g, preventing segmentation faults caused by missing `vsyscall` support.
+
+---
+
+### **Additional Considerations**
+
+- **Security Implications:**
+  - Enabling `vsyscall` emulation is generally safe but reintroduces some legacy code paths.
+  - The risk is minimal for most users, but it's important to keep the system updated.
+
+- **Alternate Solutions:**
+  - **Upgrade Oracle Version:**
+    - Consider using a newer version of Oracle that doesn't rely on `vsyscall`.
+  - **Use an Older Kernel:**
+    - Downgrading the kernel to a version where `vsyscall` is enabled by default.
+    - Not recommended due to potential security vulnerabilities.
+
+- **Documentation and References:**
+  - Similar issues and solutions have been documented in various repositories:
+    - [JiscSD/rdss-archivematica Issue #65](https://github.com/JiscSD/rdss-archivematica/issues/65)
+    - [Enalean/docker-tuleap-aio Issue #57](https://github.com/Enalean/docker-tuleap-aio/issues/57)
+    - [moby/moby Issue #28705](https://github.com/moby/moby/issues/28705)
+
+---
+
+### **Summary**
+
+- **Problem:**
+  - The Oracle 11g Docker container was exiting with a segmentation fault on Debian due to `vsyscall` being disabled in the kernel.
+
+- **Solution:**
+  - Enabling `vsyscall` emulation by adding `vsyscall=emulate` to the kernel boot parameters in GRUB.
+  - Updating GRUB and rebooting the system applied the changes.
+  - The container then started successfully.
+
+---
+
+**By adjusting the kernel parameter to enable `vsyscall` emulation, you resolved the compatibility issue between Oracle 11g and the modern Debian kernel, allowing the Docker container to run without errors.**
+
+---
+
+If you have any further questions or need assistance with other issues, feel free to ask!