The command CHROOT leads to Segmentation fault. A FIX.

Kernels & Hardware, configuring network, installing services

Re: The command CHROOT leads to Segmentation fault. A FIX.

Postby Head_on_a_Stick » 2020-04-20 12:31

john123son wrote:It seems that someone turned off a kernel option, vsyscall=emulate, that chroot relies on.

What on Earth are you blabbering on about? :?
Code: Select all
empty@E485 ~ % sudo chroot arch
root@E485 / #

Works for me™ without that vsyscall kernel option.

Also:
john123son wrote:To fix this, add vsyscall=emulate to the GRUB_CMDLINE_LINUX_DEFAULT variable.

That calls the non-legacy vsyscall option, which is enabled in the stock buster kernel (CONFIG_X86_VSYSCALL_EMULATION). It has *nothing* to do with CONFIG_LEGACY_VSYSCALL_EMULATE — if that option isn't enabled in the kernel then you can't make it work with a kernel parameter.

EDIT: that option appears to be the default: https://github.com/torvalds/linux/blob/ ... .txt#L5449
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12777
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: The command CHROOT leads to Segmentation fault. A FIX.

Postby Head_on_a_Stick » 2020-04-20 13:31

john123son wrote:This can be hard to debug or figure out if you don't know what you are looking for.

Yeah, you're certainly having problems with it :mrgreen:

john123son wrote:I have recompiled the kernel with CONFIG_X86_VSYSCALL_EMULATION=y but kept CONFIG_LEGACY_VSYSCALL_NONE=y

Those options are already applied in the stock Debian buster kernel version...

john123son wrote:I'd say that turning X86_VSYSCALL_EMULATION back on and keeping the default as LEGACY_VSYSCALL_NONE=y should not hurt security wise

From my buster box:
Code: Select all
empty@E485 ~ % grep 'X86_VSYSCALL\|LEGACY_VSYSCALL' /boot/config-4.19.0-8-amd64
CONFIG_X86_VSYSCALL_EMULATION=y
# CONFIG_LEGACY_VSYSCALL_EMULATE is not set
CONFIG_LEGACY_VSYSCALL_NONE=y
empty@E485 ~ %

And vsyscall=emulate is the default setting, as I've already explained: https://www.kernel.org/doc/html/v4.19/a ... eters.html
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12777
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: The command CHROOT leads to Segmentation fault. A FIX.

Postby Head_on_a_Stick » 2020-04-20 19:14

You're just trying to find excuses to post yet more links to that stupid ****** thread, please stop. As a spam-hunter I should probably just move this entire thread and any others in which you're posted that link...
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12777
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: The command CHROOT leads to Segmentation fault. A FIX.

Postby LE_746F6D617A7A69 » 2020-06-15 07:57

john123son wrote:what percentage of Debian users do you think know that they need to add vsyscall=emulate to the kernel command line to get chroot to work?

Actually, the question is:
What percentage of Debian users do you think know that they need to add vsyscall=emulate to the kernel command line to get chroot to work with an ancient version of Debian, where the executables are incompatible with the current version of kernel?

I'm using [s]chroot on a daily basis and it works correctly.
For a while I was running Debian7 32bit on Debian9 64bit in a schroot, because I had no time to move some apps to a new OS version - worked flawlessly.

So, it's just Your special, unique case - and IMO You should change the title of this topic, because chroot command doesn't need any fixes in the kernel.
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
LE_746F6D617A7A69
 
Posts: 414
Joined: 2020-05-03 14:16


Return to System configuration

Who is online

Users browsing this forum: No registered users and 10 guests

fashionable