On 11/5/21 2:36 pm, Didier Kryn wrote:
> Le 11/05/2021 à 06:57, Brad Campbell via Dng a écrit :
>> G'day all,
>>
>> I use a self-compiled kernel (v5.10) at the moment.
>> An Ascii to Beowulf upgrade died early on because the eudev preinst
>> script isn't correctly parsing /proc/kallsyms.
>>
>> Preparing to unpack .../25-eudev_3.2.9-8~beowulf1_amd64.deb ...
>> Since release 198, udev requires support for the following features in
>> the running kernel:
>>
>> - inotify(2)            (CONFIG_INOTIFY_USER)
>> - signalfd(2)           (CONFIG_SIGNALFD)
>> - accept4(2)
>> - open_by_handle_at(2)  (CONFIG_FHANDLE)
>> - timerfd_create(2)     (CONFIG_TIMERFD)
>> - epoll_create(2)       (CONFIG_EPOLL)
>> dpkg: error processing archive
>> /tmp/apt-dpkg-install-PJCPSM/25-eudev_3.2.9-8~beowulf1_amd64.deb
>> (--unpack):
>>  new eudev package pre-installation script subprocess returned error
>> exit status 1
>>
>> root@bkmac:/tmp/temp# needed_symbols='inotify_init signalfd accept4
>> open_by_handle_at timerfd_create epoll_create'
>>
>> root@bkmac:/tmp/temp# for symbol in $needed_symbols; do echo $symbol ;
>> egrep "^[a-fA-F0-9]+ T \.?sys_${symbol}$" /proc/kallsyms ; done
>> inotify_init
>> signalfd
>> accept4
>> open_by_handle_at
>> timerfd_create
>> epoll_create
>>
>> root@bkmac:/tmp/temp# for symbol in $needed_symbols; do echo $symbol ;
>> egrep "^[a-fA-F0-9]+ T __x64.sys_${symbol}$" /proc/kallsyms ; done
>> inotify_init
>> ffffffff811ac000 T __x64_sys_inotify_init
>> signalfd
>> ffffffff811af380 T __x64_sys_signalfd
>> accept4
>> ffffffff813df4a0 T __x64_sys_accept4
>> open_by_handle_at
>> ffffffff811d3410 T __x64_sys_open_by_handle_at
>> timerfd_create
>> ffffffff811b00c0 T __x64_sys_timerfd_create
>> epoll_create
>> ffffffff811ad9b0 T __x64_sys_epoll_create
>>
>> I unpacked, patched out the check and re-packed the deb, then manually
>> installed it.
>> Unfortunately for me (yay) the upgrade then proceeded to break
>> horribly with an apt-get -f install resulting it in wanting to
>> uninstall X and everything associated with it, requiring severe manual
>> intervention to get a functioning system again.
>>
>> root@bkmac:/var/cache/apt/archives# apt-get -u dist-upgrade
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> You might want to run 'apt --fix-broken install' to correct these.
>> The following packages have unmet dependencies:
>>  cups-daemon : Depends: libcups2 (= 2.2.10-6+deb10u4) but
>> 2.2.1-8+deb9u6 is installed
>>  cups-ipp-utils : Depends: libcups2 (= 2.2.10-6+deb10u4) but
>> 2.2.1-8+deb9u6 is installed
>>  libcupsimage2 : Depends: libcups2 (= 2.2.10-6+deb10u4) but
>> 2.2.1-8+deb9u6 is installed
>>  libeudev-dev : Depends: libeudev1 (= 3.2.2-13) but 3.2.9-8~beowulf1
>> is installed
>>  libreoffice-java-common : Depends: libreoffice-common (=
>> 1:6.1.5-3+deb10u7) but 1:5.2.7-1+deb9u11 is installed
>>  libreoffice-style-colibre : Depends: libreoffice-common (=
>> 1:6.1.5-3+deb10u7) but 1:5.2.7-1+deb9u11 is installed
>>  libusb-1.0-0-dev : Depends: libusb-1.0-0 (= 2:1.0.22-2) but
>> 2:1.0.21-1 is installed
>>  python3-distutils : Depends: python3 (>= 3.7.1-1~) but 3.5.3-1 is
>> installed
>>  python3-lib2to3 : Depends: python3 (>= 3.7.1-1~) but 3.5.3-1 is
>> installed
>> E: Unmet dependencies. Try 'apt --fix-broken install' with no packages
>> (or specify a solution).
>>
>> I got there, but there was a lot of manual dpkg -i from the cache
>> directory to get things back on track.
>>
>> Just a headsup.
>>
>> Brad
>
>
>     Hello Brad.
>
>     I'd bet you disabled - or failed to enable - one of the mentionned
> kernel features during the config phase of your kernel build. So it
> would just be a matter of carefully configuring your kernel build, not
> reusing an old config file.
>

G'day Didier,

I did neither. Here's the relevant bit again where I modified the regex to match the output from the v5 kernel indicating that all required symbols are present and accounted for :

root@bkmac:/tmp/temp# needed_symbols='inotify_init signalfd accept4 open_by_handle_at timerfd_create epoll_create'
root@bkmac:/tmp/temp# for symbol in $needed_symbols; do echo $symbol ; egrep "^[a-fA-F0-9]+ T __x64.sys_${symbol}$" /proc/kallsyms ; done
inotify_init
ffffffff811ac000 T __x64_sys_inotify_init
signalfd
ffffffff811af380 T __x64_sys_signalfd
accept4
ffffffff813df4a0 T __x64_sys_accept4
open_by_handle_at
ffffffff811d3410 T __x64_sys_open_by_handle_at
timerfd_create
ffffffff811b00c0 T __x64_sys_timerfd_create
epoll_create
ffffffff811ad9b0 T __x64_sys_epoll_create

Somewhere between the kernel the eudev package was built for and the kernel I'm running, the output of /proc/kallsyms changed. It now contains the architecture prepended to the symbol name, and the eudev preinst script can't parse it. eudev runs perfectly well on the kernel.

For example :
brad@bkmac:~$ grep sys_open_by_handle_at /proc/kallsyms
0000000000000000 T __x64_sys_open_by_handle_at
0000000000000000 T __ia32_sys_open_by_handle_at
0000000000000000 T __ia32_compat_sys_open_by_handle_at

It matches what I found in this bug : https://bugs.devuan.org/cgi/bugreport.cgi?bug=383
In that instance the reporter got it installed by downgrading his kernel.

Regards,
Brad