On 02/16/2021 04:56 PM, Jose R Rodriguez wrote:
On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote:
On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <
edward.shishkin@xxxxxxxxx> wrote:
On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
I built Linux kernel 5.10.1-1 within the 'Debian way' -- as
usual -- to generate a kernel component for my Debian-Installer
(d-i).
The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-
unstable.
Once I built the proper reiser4progs-2.0.4.tar.gz and generated
one set of components for d-i I built the d-i image.
Fact is, the installer throws an error in *both* bare metal and
VirtualBox 6.1.16:
...
Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-
base' selected
Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --
components=main --debian-installer --resolve-deps --
keyring=/usr/share/keyrings/archive.gpg buster /target
http://deb.debian.org/debian/
Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596:
/target/test-exec: Invalid argument
Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not
supported for file /test-exec (pid: 10077 comm: debootstrap)
Dec 22 20:19:56 debootstrap: E: NOEXEC
Dec 22 20:19:56 debootstrap: EF: Cannot install into target
'/target' mounted with noexec or nodev
Dec 22 20:20:12 base-installer: error: exiting on error base-
installer/debootstrap-failed
Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring
'bootstrap-base' failed with error code 1
Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item
'bootstrap-base' failed.
Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the
package description for brltty-udeb
[...]
Apparently, d-i [Debian-installer] complains about being unable
to set the test file executable and causes the error when 1 is
returned.
Notwithstanding, I manually verified that I am able to touch a
file and set it +x executable.
Furthermore, tricking the function return value to 0 I am able
to make d-i continue with the latest SFRN5 installation (see
[*trick*] below); yet, subsequently halts again with
an apparently related error --can not proceed any further.
Digging deeper with dmesg, we can see that apparently it is the
kernel which cannot 'read' properly. Please find a partial
dmesg log with relevant output
from an attempt on my physical development machine.
...
[ 508.614488] Loading Reiser4 (Software Framework Release:
5.1.3). See reiser4.wiki.kernel.org for a description of
Reiser4.
[ 508.661951] SGI XFS with ACLs, security attributes,
realtime, quota, no debug enabled
[ 509.326270] device-mapper: uevent: version 1.0.3
[ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01)
initialised: dm-devel@xxxxxxxxxx
[ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
[ 509.915300] sdb: sdb1 sdb2 sdb3
[ 511.973360] sdb: sdb1 sdb2 sdb3
[ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2
extents:1 across:9765884k FS
[ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol
(fs/reiser4/init_volume.c:222)[edward-1932]:
[ 636.240812] NOTICE: brick /dev/sda6 has been registered
[ 636.243003] reiser4 (sda6): found disk format 5.1.3.
[ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction
Model.
[ 643.759980] reiser4: brick /dev/sda6 activated
[ 643.788537] EXT4-fs (sda1): mounting ext2 file system using
the ext4 subsystem
[ 643.813474] EXT4-fs (sda1): mounted filesystem without
journal. Opts: (null)
[ 643.813488] ext2 filesystem being mounted at /target/boot
supports timestamps until 2038 (0x7fffffff)
[ 648.168730] kernel read not supported for file /test-exec
(pid: 9876 comm: debootstrap) [*trick*]
[ 898.761385] reiser4: brick /dev/sda6 deactivated
[ 991.001332] reiser4 (sda6): found disk format 5.1.3.
[ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction
Model.
[ 999.093480] reiser4: brick /dev/sda6 activated
[ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using
the ext4 subsystem
[ 1009.362722] EXT4-fs (sda1): mounted filesystem without
journal. Opts: (null)
[ 1009.362737] ext2 filesystem being mounted at /target/boot
supports timestamps until 2038 (0x7fffffff)
[ 6373.748413] kernel read not supported for file /test-exec
(pid: 10094 comm: debootstrap)
[ 6413.169920] kernel read not supported for file /usr/bin/true
(pid: 15960 comm: chroot)
Hello.
This is because of VFS changes in Linux-5.10.X.
Specifically, because of the following patch:
https://lkml.org/lkml/2020/8/17/174
In the upstream git repository it is commit
4d03e3cc59828c82ee89ea6e2
So, Christoph, what to do now for file systems which implement
->read() method of file operations?
*deafening silence* it appears that -- in the best of cases --
Christoph engaged in an act of _iter masturbation [1];
and in the worst of cases, the gentleman was aiming straight at
reiser4.
... It seems that chroot doesn't work
for them. And people are not able to release distros with
upgraded
kernels..
Not only 'chroot doesn't work' for us, but even after replacing the
kernel in a reiser4 (proper SFRN ;) instance and
upon an initial Linux 5.10.x kernel boot:
...
kernel read not supported for file usr/lib/systemd/systemd (pid: 1
comm: run-init)
kernel panic -- not syncing: Attempted to kill init!
exitcod=0x00000100
...
Fact is some of us have commercial interests when deploying
reiser4, both in cloud instances, baremetal, and on-premises.
In the future if -- and only if -- our reiser4 efforts come to
successful fruition, quite likely in due time we will be
able to financially commit to the Penguin's Linux Foundation
temple, just like large corporations do
in exchange for indulgences[2] which virtue-wash their past
and/or current corp. officers' *substantially darker deeds*;
heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU)
that 'virtuous' cult of GNU/Linux
developers/gatekeepers/maintainers' frivolous, *narcissist*,
ethics and/or moralities so often piled up against
Reiser's work --which, paradoxically(!?), actually was largely
implemented by Russian developers ;)
In the meantime, I hacked a reverse patch that undoes some(all) of
the surreptitious lethal attack on reiser4 fs
-- at least on AMD64 architectures (I did away with other
arch/Kconfigs).
And no, I am not a git pro-, undoing what I could of commit
4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
does not fix the 'kernel read' issue.
Notwithstanding, I would appreciate if you can take a look at the
attached patch. Probably it can be streamlined and/or improved
further to minimize pain on subsequent Linux kernel upgrades.
That patch is an attempt to swim against the current ;)
In a sense all of us who prefer reiser4 do not have a herd mentality.
So, yes, we 'swim against the current', if you will put it in those
terms, because we value data integrity (atomicity).
Cool.
Do you have resources to support such fork?
Notwithstanding, it is only an ephemeral hack for AMD64 architectures.
I have running locally reiser4 -enabled 5.10.13-2, 5.10.14-2, whereas I
have an Google Compute Engine (GCE), on an AMD Epyc (reizer4 label)
zone, custom instance testing with a cloud kernel 5.10.15-2.
< https://metztli.it/buster/cloud-5.10.15-2+reizer4_0_2.png >
Heck, I have updated the reiser4, Software Framework Release Number
(SFRN) 5.1.3, d-i netboot installer media with a test kernel 5.10.16-2
< https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso
Note that fsck.reiser4 still doesn't work with 5.1.3
Thanks,
Edward.
<
https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso.SHA256SUM
... крутые?
I no longer remember, why they want to get rid of set_fs for already
15
years, but ->read() and ->write() methods seem to be deprecated, and
the
correct way would be to implement the new ->read_iter() and
write_iter()
methods, where reiser4 works with "chunked" streams, represented by
iov_iter structure, rather than with "continuous" streams,
represented
by char __user *buf. The task is not that difficult, but rather time
consuming - I don't have a time for this right now..
Thanks,
Edward.
The patch has been tested in my local development machine
environment --
as I intalled the generated reiser4 -enabled linux 5.10.13/14
meta/kernel into a Debian Bullseye already running reiser4 (with
proper SFRN)
and the kernel booted nicely. Subsequently, after installing the
linux headers, etc. I built a couple of upgraded kernels
in Debian Buster GCC-8 and Bullseye GCC-10 environments -- thus
the hack seems to be stable.
Additionally, I have just made a Debian-Installer (d-i) with a
'kernel read' -patched Linux 5.10.14.1 which successfully installed
into a VirtualBox 6.1.18 VM:
<
https://metztli.it/buster/reiser4_0_2-linux-5.10.14-kernel-read-patched.png
>
Thanks,
Edward.
Best Professional Regards.
[1]
"The bug was fixed, again way back in 2010, and over time chip-
designers have moved on to improved memory management techniques.
Torvalds wrote that this sort of memory space override has been
banished from the x86, powerpc, s390 and RISC-V architectures."
< https://www.theregister.com/2020/10/25/linux_5_10_rc1/ ;>
[2] https://www.britannica.com/topic/indulgence
Best Professional Regards.
