Messages in this thread | | | Subject | Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\) | From | Edward Shishkin <> | Date | Tue, 16 Feb 2021 21:02:52 +0100 |
| |
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@gmail.com> 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@redhat.com >>>>> [ 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. >
| |