Reiser4: Format 4.0.1: Meta(data) checksums

Reiser4: Format 4.0.1: Meta(data) checksums

[Edward Shishkin]

Hi all,

This is the first release of new software versions of reiser4 kernel
module and reiser4prods, which invoke the builtin mechanism of
tracking compatibility basing on versions of reiser4 plugin library.
More about this can be found here:
https://reiser4.wiki.kernel.org/index.php/Reiser4_development_model

Reiser4progs of the new software release version number 4.0.1
are provided by the package reiser4progs-1.1.0. Please find here:
https://sourceforge.net/projects/reiser4/files/reiser4-utils/reiser4progs

Reiser4 kernel module of the new software release version number
4.0.1 is provided by the patch reiser4-for-4.1.5. Please find here:
https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-4.x/

At mount time disk format version of your partition's superblock will
be upgraded by the kernel, and you will be suggested to complete the
upgrade offline by fsck:

# dmesg | grep [rR]eiser4
Loading Reiser4 (format release: 4.0.1).
reiser4: sda5: found disk format 4.0.0.
reiser4: sda5: upgrading disk format to 4.0.1.
reiser4: sda5: use 'fsck.reiser4 --fix' to complete disk format upgrade.

You may ignore this suggestion and continue to work as usual.
However, I would suggest to find a time and complete the upgrade.

NOTE: after mount in the new kernel you won' t be able to
check your partition by reiser4progs-1.0.9 and older versions, so
please upgrade your reiser4progs BEFORE. Everyone who relies on
liveCDs with reiser4progs-1.0.9, or older versions: be careful!

More about reiser4 (meta)data checksums can be found here:
https://reiser4.wiki.kernel.org/index.php/Reiser4_checksums

Thanks,
Edward.

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Jose R R]

Niltze, Ed-



On Mon, Aug 31, 2015 at 8:21 AM, Edward Shishkin
<edward.shishkin@gmail.com> wrote:
>
> Hi all,
>
> This is the first release of new software versions of reiser4 kernel
> module and reiser4prods, which invoke the builtin mechanism of
> tracking compatibility basing on versions of reiser4 plugin library.
> More about this can be found here:
> https://reiser4.wiki.kernel.org/index.php/Reiser4_development_model
>
> Reiser4progs of the new software release version number 4.0.1
> are provided by the package reiser4progs-1.1.0. Please find here:
> https://sourceforge.net/projects/reiser4/files/reiser4-utils/reiser4progs
>
> Reiser4 kernel module of the new software release version number
> 4.0.1 is provided by the patch reiser4-for-4.1.5. Please find here:
> https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-4.x/
>
> At mount time disk format version of your partition's superblock will
> be upgraded by the kernel, and you will be suggested to complete the
> upgrade offline by fsck:
>
> # dmesg | grep [rR]eiser4
> Loading Reiser4 (format release: 4.0.1).
> reiser4: sda5: found disk format 4.0.0.
> reiser4: sda5: upgrading disk format to 4.0.1.
> reiser4: sda5: use 'fsck.reiser4 --fix' to complete disk format upgrade.
>
> You may ignore this suggestion and continue to work as usual.
> However, I would suggest to find a time and complete the upgrade.
>
> NOTE: after mount in the new kernel you won' t be able to
> check your partition by reiser4progs-1.0.9 and older versions, so
> please upgrade your reiser4progs BEFORE. Everyone who relies on
> liveCDs with reiser4progs-1.0.9, or older versions: be careful!
>
> More about reiser4 (meta)data checksums can be found here:
> https://reiser4.wiki.kernel.org/index.php/Reiser4_checksums
>
> Thanks,
> Edward.
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I have applied reiser4-for-4.1.5.patch.gz to both pristine
linux-4.1.5.tar.xz from kernel.org and to 4.1.6 from upstream Debian
and both kernels fail to (re)boot into the Reiser4 root partition in
which they were built.

I am using Debian Sid reiser4progs_1.1.0-1_amd64.deb from
https://packages.debian.org/sid/reiser4progs

In both instances, after GRUB boots from the boot partition into the
root Reiser4 partition and message after
fsck.reiser4 /dev/sdaX
[ 3.979349 ] BUG: unable to handle kernel NULL pointer dereference at
0000000000000069
[...]
(initramfs prompt) will not boot into its Reiser4 partition

From another partition I have even tried (using
reiser4progs_1.1.0-1_amd64.deb, too)
fsck.reiser4 --version
fsck.reiser4 1.1.0
Format release: 4.0.1
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by
reiser4progs/COPYING.

fsck.reiser4 --fix /dev/sdaX
and
fsck.reiser4  --build-fs /dev/sdaX

which finished fine. Nevertheless upon rebooting into fsck'ed
partition with the Reiser4 4.0.1 kernel module nothing changes, i.e.,
I get BUG and kernel boot stops at initramfs prompt.


Best Professional Regards.

-- 
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
---------------------------------------------------------------------------------------------
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Edward Shishkin]

On 09/08/2015 10:46 PM, Jose R R wrote:
> Niltze, Ed-

Hello

>
>
>
> On Mon, Aug 31, 2015 at 8:21 AM, Edward Shishkin
> <edward.shishkin@gmail.com> wrote:
>> Hi all,
>>
>> This is the first release of new software versions of reiser4 kernel
>> module and reiser4prods, which invoke the builtin mechanism of
>> tracking compatibility basing on versions of reiser4 plugin library.
>> More about this can be found here:
>> https://reiser4.wiki.kernel.org/index.php/Reiser4_development_model
>>
>> Reiser4progs of the new software release version number 4.0.1
>> are provided by the package reiser4progs-1.1.0. Please find here:
>> https://sourceforge.net/projects/reiser4/files/reiser4-utils/reiser4progs
>>
>> Reiser4 kernel module of the new software release version number
>> 4.0.1 is provided by the patch reiser4-for-4.1.5. Please find here:
>> https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-4.x/
>>
>> At mount time disk format version of your partition's superblock will
>> be upgraded by the kernel, and you will be suggested to complete the
>> upgrade offline by fsck:
>>
>> # dmesg | grep [rR]eiser4
>> Loading Reiser4 (format release: 4.0.1).
>> reiser4: sda5: found disk format 4.0.0.
>> reiser4: sda5: upgrading disk format to 4.0.1.
>> reiser4: sda5: use 'fsck.reiser4 --fix' to complete disk format upgrade.
>>
>> You may ignore this suggestion and continue to work as usual.
>> However, I would suggest to find a time and complete the upgrade.
>>
>> NOTE: after mount in the new kernel you won' t be able to
>> check your partition by reiser4progs-1.0.9 and older versions, so
>> please upgrade your reiser4progs BEFORE. Everyone who relies on
>> liveCDs with reiser4progs-1.0.9, or older versions: be careful!
>>
>> More about reiser4 (meta)data checksums can be found here:
>> https://reiser4.wiki.kernel.org/index.php/Reiser4_checksums
>>
>> Thanks,
>> Edward.
>> --
>> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> I have applied reiser4-for-4.1.5.patch.gz to both pristine
> linux-4.1.5.tar.xz from kernel.org and to 4.1.6 from upstream Debian
> and both kernels fail to (re)boot into the Reiser4 root partition in
> which they were built.
>
> I am using Debian Sid reiser4progs_1.1.0-1_amd64.deb from
> https://packages.debian.org/sid/reiser4progs
>
> In both instances, after GRUB boots from the boot partition into the
> root Reiser4 partition and message after
> fsck.reiser4 /dev/sdaX
> [ 3.979349 ] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000069


Could you catch the full stack dump at serial console,
or take a pic of this by using camera?

Thanks,
Edward.


> [...]
> (initramfs prompt) will not boot into its Reiser4 partition
>
>  From another partition I have even tried (using
> reiser4progs_1.1.0-1_amd64.deb, too)
> fsck.reiser4 --version
> fsck.reiser4 1.1.0
> Format release: 4.0.1
> Copyright (C) 2001-2005 by Hans Reiser, licensing governed by
> reiser4progs/COPYING.
>
> fsck.reiser4 --fix /dev/sdaX
> and
> fsck.reiser4  --build-fs /dev/sdaX
>
> which finished fine. Nevertheless upon rebooting into fsck'ed
> partition with the Reiser4 4.0.1 kernel module nothing changes, i.e.,
> I get BUG and kernel boot stops at initramfs prompt.
>
>
> Best Professional Regards.
>

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Jose R R]

Scratch my previous issue, Ed. It is *not* related to your new Reiser4
software release 4.0.1 module nor reiser4progs.

My usual development environment is a modified non-systemd Debian Sid
(unstable) on a Reiser4 root partition. The kernels built won't boot
in *that* particular instance due to a least one other additional
issue:
target filesystem does not have requested /sbin/init

However, I tried one of my recently built reiser4-patched kernels into
a systemd Debian Sid -- also running on reiser4 root partition -- and
the system booted and behaved as you predicted.

< https://pbs.twimg.com/media/COccj66UAAA7mfp.png:large >

Sorry about that, Ed. It's my fault for only testing in the build
environment (although I had not had an issue with reiser4 builds until
this kernel 4.x and new 4.0.1 software combination change).

On Tue, Sep 8, 2015 at 4:20 PM, Milan Buška <milan.buska@gmail.com> wrote:
> Hi all.
>
> I'm not an expert but I think that the error happened during kernel
> compilation.
> I have compiled into the kernel filesystem reiser4 directly into the kernel,
> not as modules and yet I have no problems. This is a record of my boot.
>
> Loading Linux 4.1.6-reiser4 ...
> early console in decompress_kernel
>
> Decompressing Linux... Parsing ELF... done.
> Booting the kernel.
> INIT: version 2.88 booting
> The system is coming up.  Please wait.
> *******************************************************************
> This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
> *******************************************************************
>
> Fscking the /dev/sda2 block device.
> Will check the consistency of the Reiser4 SuperBlock.
> Will check the consistency of the Reiser4 FileSystem.
> ***** fsck.reiser4 started at Wed Sep  9 00:31:06 2015
> Reiser4 fs was detected on /dev/sda2.
> Master super block (16):
> magic:          ReIsEr4
> blksize:        4096
> format:         0x0 (format40)
> uuid:           631c2925-dca7-41be-b40c-46e7b2052e28
> label:          SYSTEM-ROOT
>
> Format super block (17):
> plugin:         format40
> description:    Disk-format plugin.
> version:        1
> magic:          ReIsEr40FoRmAt
> mkfs id:        0x6129d214
> flushes:        0
> blocks:         27000832
> free blocks:    26270124
> root block:     118355
> tail policy:    0x2 (smart)
> next oid:       0x86a7b6
> file count:     170068
> tree height:    5
> key policy:     LARGE
>
>
> CHECKING THE STORAGE TREE
>         Read nodes 269426
>         Nodes left in the tree 269426
>                 Leaves of them 265060, Twigs of them 4257
>         Time interval: Wed Sep  9 00:31:06 2015 - Wed Sep  9 00:31:22 2015
> CHECKING EXTENT REGIONS.
>         Read twigs 4257
>         Time interval: Wed Sep  9 00:31:22 2015 - Wed Sep  9 00:31:22 2015
> CHECKING THE SEMANTIC TREE
>         Found 171872 objects (some could be encountered more then once).
>         Time interval: Wed Sep  9 00:31:22 2015 - Wed Sep  9 00:31:25 2015
> ***** fsck.reiser4 finished at Wed Sep  9 00:31:25 2015
> Closing fs...done
>
> FS is consistent.
>
> hostname: ishi
> font: ter-v16n
> keyboard: us
> INIT: Entering runlevel: 2
> starting services: sysklogd lo net firewall crond gpm dbus
>
> Version reiser4progs:
> $ /sbin/fsck.reiser4 --version
> /sbin/fsck.reiser4 1.1.0
> Format release: 4.0.1
> Copyright (C) 2001-2005 by Hans Reiser, licensing governed by
> reiser4progs/COPYING.
>
> $ uname -a
> Linux ishi 4.1.6-reiser4 #1 SMP Tue Sep 1 17:44:08 CEST 2015 x86_64 Intel(R)
> Core(TM) i5-3570K CPU @ 3.40GHz GenuineIntel GNU/Linux
>
> I also recommend checking with such parameters and patches reiser4progs is
> compiled on Debian. See the debian / rules.
>
> Greeting
>
> Milan
>

I appreciate your input Milan, thank you.

I usually build a reiser4 module in Debian and make sure that
initramfs-tools are aware of it during kernel installation by editing
/etc/initramfs-tools/modules, adding directive: reiser4
Otherwise, reiser4 module will not be included in the initrd and the
system will not boot.

Thank you all.


Best Professional Regards.


-- 
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
---------------------------------------------------------------------------------------------
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 4787 bytes --]

On 2015-09-09 at 00:54 -0700, Jose R R wrote:
> Scratch my previous issue, Ed. It is *not* related to your new
> Reiser4
> software release 4.0.1 module nor reiser4progs.
> 
> My usual development environment is a modified non-systemd Debian Sid
> (unstable) on a Reiser4 root partition. The kernels built won't boot
> in *that* particular instance due to a least one other additional
> issue:
> target filesystem does not have requested /sbin/init

Could you please elaborate? I'm getting the exact same oops with "new"
reiser4 (did not have a chance to investigate it, so just fell back to
the old kernel for the meantime).

-- 
Ivan Shapovalov / intelfx /

> 
> However, I tried one of my recently built reiser4-patched kernels
> into
> a systemd Debian Sid -- also running on reiser4 root partition -- and
> the system booted and behaved as you predicted.
> 
> < https://pbs.twimg.com/media/COccj66UAAA7mfp.png:large >
> 
> Sorry about that, Ed. It's my fault for only testing in the build
> environment (although I had not had an issue with reiser4 builds
> until
> this kernel 4.x and new 4.0.1 software combination change).
> 
> On Tue, Sep 8, 2015 at 4:20 PM, Milan Buška <milan.buska@gmail.com>
> wrote:
> > Hi all.
> > 
> > I'm not an expert but I think that the error happened during kernel
> > compilation.
> > I have compiled into the kernel filesystem reiser4 directly into
> > the kernel,
> > not as modules and yet I have no problems. This is a record of my
> > boot.
> > 
> > Loading Linux 4.1.6-reiser4 ...
> > early console in decompress_kernel
> > 
> > Decompressing Linux... Parsing ELF... done.
> > Booting the kernel.
> > INIT: version 2.88 booting
> > The system is coming up.  Please wait.
> > *******************************************************************
> > This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
> > *******************************************************************
> > 
> > Fscking the /dev/sda2 block device.
> > Will check the consistency of the Reiser4 SuperBlock.
> > Will check the consistency of the Reiser4 FileSystem.
> > ***** fsck.reiser4 started at Wed Sep  9 00:31:06 2015
> > Reiser4 fs was detected on /dev/sda2.
> > Master super block (16):
> > magic:          ReIsEr4
> > blksize:        4096
> > format:         0x0 (format40)
> > uuid:           631c2925-dca7-41be-b40c-46e7b2052e28
> > label:          SYSTEM-ROOT
> > 
> > Format super block (17):
> > plugin:         format40
> > description:    Disk-format plugin.
> > version:        1
> > magic:          ReIsEr40FoRmAt
> > mkfs id:        0x6129d214
> > flushes:        0
> > blocks:         27000832
> > free blocks:    26270124
> > root block:     118355
> > tail policy:    0x2 (smart)
> > next oid:       0x86a7b6
> > file count:     170068
> > tree height:    5
> > key policy:     LARGE
> > 
> > 
> > CHECKING THE STORAGE TREE
> >         Read nodes 269426
> >         Nodes left in the tree 269426
> >                 Leaves of them 265060, Twigs of them 4257
> >         Time interval: Wed Sep  9 00:31:06 2015 - Wed Sep  9
> > 00:31:22 2015
> > CHECKING EXTENT REGIONS.
> >         Read twigs 4257
> >         Time interval: Wed Sep  9 00:31:22 2015 - Wed Sep  9
> > 00:31:22 2015
> > CHECKING THE SEMANTIC TREE
> >         Found 171872 objects (some could be encountered more then
> > once).
> >         Time interval: Wed Sep  9 00:31:22 2015 - Wed Sep  9
> > 00:31:25 2015
> > ***** fsck.reiser4 finished at Wed Sep  9 00:31:25 2015
> > Closing fs...done
> > 
> > FS is consistent.
> > 
> > hostname: ishi
> > font: ter-v16n
> > keyboard: us
> > INIT: Entering runlevel: 2
> > starting services: sysklogd lo net firewall crond gpm dbus
> > 
> > Version reiser4progs:
> > $ /sbin/fsck.reiser4 --version
> > /sbin/fsck.reiser4 1.1.0
> > Format release: 4.0.1
> > Copyright (C) 2001-2005 by Hans Reiser, licensing governed by
> > reiser4progs/COPYING.
> > 
> > $ uname -a
> > Linux ishi 4.1.6-reiser4 #1 SMP Tue Sep 1 17:44:08 CEST 2015 x86_64
> > Intel(R)
> > Core(TM) i5-3570K CPU @ 3.40GHz GenuineIntel GNU/Linux
> > 
> > I also recommend checking with such parameters and patches
> > reiser4progs is
> > compiled on Debian. See the debian / rules.
> > 
> > Greeting
> > 
> > Milan
> > 
> 
> I appreciate your input Milan, thank you.
> 
> I usually build a reiser4 module in Debian and make sure that
> initramfs-tools are aware of it during kernel installation by editing
> /etc/initramfs-tools/modules, adding directive: reiser4
> Otherwise, reiser4 module will not be included in the initrd and the
> system will not boot.
> 
> Thank you all.
> 
> 
> Best Professional Regards.
> 
> 



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Jose R R]

On Wed, Sep 9, 2015 at 6:16 AM, Ivan Shapovalov <intelfx100@gmail.com> wrote:
> On 2015-09-09 at 00:54 -0700, Jose R R wrote:
>> Scratch my previous issue, Ed. It is *not* related to your new
>> Reiser4
>> software release 4.0.1 module nor reiser4progs.
>>
>> My usual development environment is a modified non-systemd Debian Sid
>> (unstable) on a Reiser4 root partition. The kernels built won't boot
>> in *that* particular instance due to a least one other additional
>> issue:
>> target filesystem does not have requested /sbin/init
>
> Could you please elaborate?

I can only describe what's going on; still searching for a solution myself.

< http://without-systemd.org/wiki/index.php/Main_Page >

initrd.imgs created within a debian Sid environment -- with systemd
replaced by init -- will fail to mount new reiser4 root file system
during boot; whereas,
initrd.imgs created within a debian Sid environment -- with systemd --
will mount *any* (systemd and non-systemd) new reiser4 root fs and
boots system -- as it should.

Issue closely resembles recent ZFS issue <
https://github.com/zfsonlinux/zfs/issues/3605 > except that, in this
non-systemd particular case, neither mkinitramfs-tools nor
dracut-created initrd.imgs are successful.

As I am running a couple of more or less similar AMD64 Debian Sid on
Reiser4 root fs, I built the initrd.img for a non-systemd Debian Sid
inside the environment of a systemd Debian Sid.

I already disassembled an older 3.xy.z initrd and compared its
contents with a initrd.img 4.1.6 built into this non-systemd Debian
Sid but file trees appears similar.

< http://linux.koolsolutions.com/2009/11/12/initramfs-ramfs-tmpfs-compressed-image/
>

Thus, a kernel I built in this non-systemd environment (Sept. 07,
2015) can be installed in a systemd environment and it will boot;
moreover, I can take the initrd.img produced in the systemd enviroment
(during kernel installation) and use it to boot this non-systemd
system -- and will proceed smoothly into its new Reiser4 4.0.1 root
fs.

< https://pbs.twimg.com/media/COiiyUtUkAAw95X.png:large >

>
>>
>> However, I tried one of my recently built reiser4-patched kernels
>> into
>> a systemd Debian Sid -- also running on reiser4 root partition -- and
>> the system booted and behaved as you predicted.
>>
>> < https://pbs.twimg.com/media/COccj66UAAA7mfp.png:large >
>>
>> Sorry about that, Ed. It's my fault for only testing in the build
>> environment (although I had not had an issue with reiser4 builds
>> until
>> this kernel 4.x and new 4.0.1 software combination change).
>>
>> On Tue, Sep 8, 2015 at 4:20 PM, Milan Buška <milan.buska@gmail.com>
>> wrote:
>> > Hi all.
>> >
>> > I'm not an expert but I think that the error happened during kernel
>> > compilation.
>> > I have compiled into the kernel filesystem reiser4 directly into
>> > the kernel,
>> > not as modules and yet I have no problems. This is a record of my
>> > boot.
>> >
>> > Loading Linux 4.1.6-reiser4 ...
>> > early console in decompress_kernel
>> >
>> > Decompressing Linux... Parsing ELF... done.
>> > Booting the kernel.
>> > INIT: version 2.88 booting
>> > The system is coming up.  Please wait.
>> > *******************************************************************
>> > This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
>> > *******************************************************************
>> >
>> > Fscking the /dev/sda2 block device.
>> > Will check the consistency of the Reiser4 SuperBlock.
>> > Will check the consistency of the Reiser4 FileSystem.
>> > ***** fsck.reiser4 started at Wed Sep  9 00:31:06 2015
>> > Reiser4 fs was detected on /dev/sda2.
>> > Master super block (16):
>> > magic:          ReIsEr4
>> > blksize:        4096
>> > format:         0x0 (format40)
>> > uuid:           631c2925-dca7-41be-b40c-46e7b2052e28
>> > label:          SYSTEM-ROOT
>> >
>> > Format super block (17):
>> > plugin:         format40
>> > description:    Disk-format plugin.
>> > version:        1
>> > magic:          ReIsEr40FoRmAt
>> > mkfs id:        0x6129d214
>> > flushes:        0
>> > blocks:         27000832
>> > free blocks:    26270124
>> > root block:     118355
>> > tail policy:    0x2 (smart)
>> > next oid:       0x86a7b6
>> > file count:     170068
>> > tree height:    5
>> > key policy:     LARGE
>> >
>> >
>> > CHECKING THE STORAGE TREE
>> >         Read nodes 269426
>> >         Nodes left in the tree 269426
>> >                 Leaves of them 265060, Twigs of them 4257
>> >         Time interval: Wed Sep  9 00:31:06 2015 - Wed Sep  9
>> > 00:31:22 2015
>> > CHECKING EXTENT REGIONS.
>> >         Read twigs 4257
>> >         Time interval: Wed Sep  9 00:31:22 2015 - Wed Sep  9
>> > 00:31:22 2015
>> > CHECKING THE SEMANTIC TREE
>> >         Found 171872 objects (some could be encountered more then
>> > once).
>> >         Time interval: Wed Sep  9 00:31:22 2015 - Wed Sep  9
>> > 00:31:25 2015
>> > ***** fsck.reiser4 finished at Wed Sep  9 00:31:25 2015
>> > Closing fs...done
>> >
>> > FS is consistent.
>> >
>> > hostname: ishi
>> > font: ter-v16n
>> > keyboard: us
>> > INIT: Entering runlevel: 2
>> > starting services: sysklogd lo net firewall crond gpm dbus
>> >
>> > Version reiser4progs:
>> > $ /sbin/fsck.reiser4 --version
>> > /sbin/fsck.reiser4 1.1.0
>> > Format release: 4.0.1
>> > Copyright (C) 2001-2005 by Hans Reiser, licensing governed by
>> > reiser4progs/COPYING.
>> >
>> > $ uname -a
>> > Linux ishi 4.1.6-reiser4 #1 SMP Tue Sep 1 17:44:08 CEST 2015 x86_64
>> > Intel(R)
>> > Core(TM) i5-3570K CPU @ 3.40GHz GenuineIntel GNU/Linux
>> >
>> > I also recommend checking with such parameters and patches
>> > reiser4progs is
>> > compiled on Debian. See the debian / rules.
>> >
>> > Greeting
>> >
>> > Milan
>> >
>>
>> I appreciate your input Milan, thank you.
>>
>> I usually build a reiser4 module in Debian and make sure that
>> initramfs-tools are aware of it during kernel installation by editing
>> /etc/initramfs-tools/modules, adding directive: reiser4
>> Otherwise, reiser4 module will not be included in the initrd and the
>> system will not boot.
>>
>> Thank you all.
>>
>>
>> Best Professional Regards.
>>
>>
>
>



-- 
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
---------------------------------------------------------------------------------------------
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]

On 2015-09-10 at 04:57 -0700, Jose R R wrote:
> On Wed, Sep 9, 2015 at 6:16 AM, Ivan Shapovalov <intelfx100@gmail.com
> > wrote:
> > On 2015-09-09 at 00:54 -0700, Jose R R wrote:
> > > Scratch my previous issue, Ed. It is *not* related to your new
> > > Reiser4
> > > software release 4.0.1 module nor reiser4progs.
> > > 
> > > My usual development environment is a modified non-systemd Debian
> > > Sid
> > > (unstable) on a Reiser4 root partition. The kernels built won't
> > > boot
> > > in *that* particular instance due to a least one other additional
> > > issue:
> > > target filesystem does not have requested /sbin/init
> > 
> > Could you please elaborate?
> 
> I can only describe what's going on; still searching for a solution
> myself.
> 
> < http://without-systemd.org/wiki/index.php/Main_Page >
> 
> initrd.imgs created within a debian Sid environment -- with systemd
> replaced by init -- will fail to mount new reiser4 root file system
> during boot; whereas,
> initrd.imgs created within a debian Sid environment -- with systemd -
> -
> will mount *any* (systemd and non-systemd) new reiser4 root fs and
> boots system -- as it should.
> 
> Issue closely resembles recent ZFS issue <
> https://github.com/zfsonlinux/zfs/issues/3605 > except that, in this
> non-systemd particular case, neither mkinitramfs-tools nor
> dracut-created initrd.imgs are successful.
> 
> As I am running a couple of more or less similar AMD64 Debian Sid on
> Reiser4 root fs, I built the initrd.img for a non-systemd Debian Sid
> inside the environment of a systemd Debian Sid.
> 
> I already disassembled an older 3.xy.z initrd and compared its
> contents with a initrd.img 4.1.6 built into this non-systemd Debian
> Sid but file trees appears similar.
> 
> < http://linux.koolsolutions.com/2009/11/12/initramfs-ramfs-tmpfs-com
> pressed-image/
> > 
> 
> Thus, a kernel I built in this non-systemd environment (Sept. 07,
> 2015) can be installed in a systemd environment and it will boot;
> moreover, I can take the initrd.img produced in the systemd
> enviroment
> (during kernel installation) and use it to boot this non-systemd
> system -- and will proceed smoothly into its new Reiser4 4.0.1 root
> fs.
> 
> < https://pbs.twimg.com/media/COiiyUtUkAAw95X.png:large >
> 

Very interesting, thanks for the observations. I'm surprised with the
fact that systemd makes a difference here...

--
Ivan Shapovalov / intelfx /


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Jose R R]

Here is some additional info:

A while back, I installed Debian Jessie AMD64 into a KVM virtual
machine and also included the initial non-systemd boot argument:
preseed/late_command="in-target apt-get install -y sysvinit-core"
< https://wiki.debian.org/systemd#Installing_without_systemd >

Afterwards a previous reiser4-patched Linux kernel 4.0.x was installed
into the virtual machine and its root fs was subsequently formatted to
reiser4.. The virtual machine was working fine:
< https://pbs.twimg.com/media/CKIKgoZUAAIFx12.png:large >

Yesterday, I installed into the vm a newer 4.1.6 kernel built "the
debian way" except that it was customized with the newer 4.0.1 Reiser4
patch. Upon rebooting the VM, I captured a sequence of 4 snapshots (by
paging down) that basically recreate the fail that I experienced
priorly in the physical machine:

< https://metztli.it/blog/index.php/ixiptli/non-systemd-debian-sid-reiser4 >

Accordingly, seems the *lack of systemd* is enough for a Debian Sid
instance to create a bad initrd.img. I have no idea if issue only
appears with Reiser4 root fs or if it includes other file systems as
root. Work in progress...

On Thu, Sep 10, 2015 at 5:10 AM, Ivan Shapovalov <intelfx100@gmail.com> wrote:
> On 2015-09-10 at 04:57 -0700, Jose R R wrote:
>> On Wed, Sep 9, 2015 at 6:16 AM, Ivan Shapovalov <intelfx100@gmail.com
>> > wrote:
>> > On 2015-09-09 at 00:54 -0700, Jose R R wrote:
>> > > Scratch my previous issue, Ed. It is *not* related to your new
>> > > Reiser4
>> > > software release 4.0.1 module nor reiser4progs.
>> > >
>> > > My usual development environment is a modified non-systemd Debian
>> > > Sid
>> > > (unstable) on a Reiser4 root partition. The kernels built won't
>> > > boot
>> > > in *that* particular instance due to a least one other additional
>> > > issue:
>> > > target filesystem does not have requested /sbin/init
>> >
>> > Could you please elaborate?
>>
>> I can only describe what's going on; still searching for a solution
>> myself.
>>
>> < http://without-systemd.org/wiki/index.php/Main_Page >
>>
>> initrd.imgs created within a debian Sid environment -- with systemd
>> replaced by init -- will fail to mount new reiser4 root file system
>> during boot; whereas,
>> initrd.imgs created within a debian Sid environment -- with systemd -
>> -
>> will mount *any* (systemd and non-systemd) new reiser4 root fs and
>> boots system -- as it should.
>>
>> Issue closely resembles recent ZFS issue <
>> https://github.com/zfsonlinux/zfs/issues/3605 > except that, in this
>> non-systemd particular case, neither mkinitramfs-tools nor
>> dracut-created initrd.imgs are successful.
>>
>> As I am running a couple of more or less similar AMD64 Debian Sid on
>> Reiser4 root fs, I built the initrd.img for a non-systemd Debian Sid
>> inside the environment of a systemd Debian Sid.
>>
>> I already disassembled an older 3.xy.z initrd and compared its
>> contents with a initrd.img 4.1.6 built into this non-systemd Debian
>> Sid but file trees appears similar.
>>
>> < http://linux.koolsolutions.com/2009/11/12/initramfs-ramfs-tmpfs-com
>> pressed-image/
>> >
>>
>> Thus, a kernel I built in this non-systemd environment (Sept. 07,
>> 2015) can be installed in a systemd environment and it will boot;
>> moreover, I can take the initrd.img produced in the systemd
>> enviroment
>> (during kernel installation) and use it to boot this non-systemd
>> system -- and will proceed smoothly into its new Reiser4 4.0.1 root
>> fs.
>>
>> < https://pbs.twimg.com/media/COiiyUtUkAAw95X.png:large >
>>
>
> Very interesting, thanks for the observations. I'm surprised with the
> fact that systemd makes a difference here...
>
> --
> Ivan Shapovalov / intelfx /
>



-- 
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
---------------------------------------------------------------------------------------------
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On 2015-09-13 at 05:57 -0700, Jose R R wrote:
> Here is some additional info:
> 
> A while back, I installed Debian Jessie AMD64 into a KVM virtual
> machine and also included the initial non-systemd boot argument:
> preseed/late_command="in-target apt-get install -y sysvinit-core"
> < https://wiki.debian.org/systemd#Installing_without_systemd >
> 
> Afterwards a previous reiser4-patched Linux kernel 4.0.x was
> installed
> into the virtual machine and its root fs was subsequently formatted
> to
> reiser4.. The virtual machine was working fine:
> < https://pbs.twimg.com/media/CKIKgoZUAAIFx12.png:large >
> 
> Yesterday, I installed into the vm a newer 4.1.6 kernel built "the
> debian way" except that it was customized with the newer 4.0.1
> Reiser4
> patch. Upon rebooting the VM, I captured a sequence of 4 snapshots
> (by
> paging down) that basically recreate the fail that I experienced
> priorly in the physical machine:
> 
> < https://metztli.it/blog/index.php/ixiptli/non-systemd-debian-sid-re
> iser4 >
> 
> Accordingly, seems the *lack of systemd* is enough for a Debian Sid
> instance to create a bad initrd.img. I have no idea if issue only
> appears with Reiser4 root fs or if it includes other file systems as
> root. Work in progress...

It's presence/absence of crc32c module that matters. Reiser4 does not
specify that it needs one.

-- 
Ivan Shapovalov / intelfx /


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Jose R R]

On Sun, Sep 13, 2015 at 6:06 AM, Ivan Shapovalov <intelfx100@gmail.com> wrote:
> On 2015-09-13 at 05:57 -0700, Jose R R wrote:
>> Here is some additional info:
>>
>> A while back, I installed Debian Jessie AMD64 into a KVM virtual
>> machine and also included the initial non-systemd boot argument:
>> preseed/late_command="in-target apt-get install -y sysvinit-core"
>> < https://wiki.debian.org/systemd#Installing_without_systemd >
>>
>> Afterwards a previous reiser4-patched Linux kernel 4.0.x was
>> installed
>> into the virtual machine and its root fs was subsequently formatted
>> to
>> reiser4.. The virtual machine was working fine:
>> < https://pbs.twimg.com/media/CKIKgoZUAAIFx12.png:large >
>>
>> Yesterday, I installed into the vm a newer 4.1.6 kernel built "the
>> debian way" except that it was customized with the newer 4.0.1
>> Reiser4
>> patch. Upon rebooting the VM, I captured a sequence of 4 snapshots
>> (by
>> paging down) that basically recreate the fail that I experienced
>> priorly in the physical machine:
>>
>> < https://metztli.it/blog/index.php/ixiptli/non-systemd-debian-sid-re
>> iser4 >
>>
>> Accordingly, seems the *lack of systemd* is enough for a Debian Sid
>> instance to create a bad initrd.img. I have no idea if issue only
>> appears with Reiser4 root fs or if it includes other file systems as
>> root. Work in progress...
>
> It's presence/absence of crc32c module that matters. Reiser4 does not
> specify that it needs one.
>
Applied your 3 patches
1/3 < http://marc.info/?l=reiserfs-devel&m=144218573602435&w=2 >
2/3 < http://marc.info/?l=reiserfs-devel&m=144218573602436&w=2 >
3/3 < http://marc.info/?l=reiserfs-devel&m=144218573702437&w=2 >

into kernel.org Linux Kernel 4.1.7, but Non-systemd Debian still boots
into an emergency shell
[...]
mount: mounting /dev/sdaX on /root failed: no such file or directory
Target fileystem doesn't have requested /sbin/init
mount: mounting /dev on /root/dev failed: no such file or directory
No init found. Try passing init= bootarg.
[...]

Typing dmesg:
[...]
reiser4[exe(801)]: reiser4_init_csum_tfm
(fs/reiser4/checksum.c:11)[intelfx-81]:WARNING: Could not load crc32c
driver

In a couple of days I will build the kernel "the Debian way"; I will
specify -- in relevant module section, at file [kernel source
tree]debian/installer/package-list:
[...]

Package: reiser4-modules
Depends: kernel-image crc-modules # <--- will add that
Priority: extra
Description: Reiser4 filesystem support
 This package contains the Reiser4 filesystem module for the kernel.
[...]

As well as at /usr/share/kernel-wedge/package-list

We will see what happens.


> --
> Ivan Shapovalov / intelfx /
>



-- 
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
---------------------------------------------------------------------------------------------
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Edward Shishkin]

[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]

Does the attached patch help?

Edward.

On 09/17/2015 02:10 PM, Jose R R wrote:
> On Sun, Sep 13, 2015 at 6:06 AM, Ivan Shapovalov <intelfx100@gmail.com> wrote:
>> On 2015-09-13 at 05:57 -0700, Jose R R wrote:
>>> Here is some additional info:
>>>
>>> A while back, I installed Debian Jessie AMD64 into a KVM virtual
>>> machine and also included the initial non-systemd boot argument:
>>> preseed/late_command="in-target apt-get install -y sysvinit-core"
>>> < https://wiki.debian.org/systemd#Installing_without_systemd >
>>>
>>> Afterwards a previous reiser4-patched Linux kernel 4.0.x was
>>> installed
>>> into the virtual machine and its root fs was subsequently formatted
>>> to
>>> reiser4.. The virtual machine was working fine:
>>> < https://pbs.twimg.com/media/CKIKgoZUAAIFx12.png:large >
>>>
>>> Yesterday, I installed into the vm a newer 4.1.6 kernel built "the
>>> debian way" except that it was customized with the newer 4.0.1
>>> Reiser4
>>> patch. Upon rebooting the VM, I captured a sequence of 4 snapshots
>>> (by
>>> paging down) that basically recreate the fail that I experienced
>>> priorly in the physical machine:
>>>
>>> < https://metztli.it/blog/index.php/ixiptli/non-systemd-debian-sid-re
>>> iser4 >
>>>
>>> Accordingly, seems the *lack of systemd* is enough for a Debian Sid
>>> instance to create a bad initrd.img. I have no idea if issue only
>>> appears with Reiser4 root fs or if it includes other file systems as
>>> root. Work in progress...
>> It's presence/absence of crc32c module that matters. Reiser4 does not
>> specify that it needs one.
>>
> Applied your 3 patches
> 1/3 < http://marc.info/?l=reiserfs-devel&m=144218573602435&w=2 >
> 2/3 < http://marc.info/?l=reiserfs-devel&m=144218573602436&w=2 >
> 3/3 < http://marc.info/?l=reiserfs-devel&m=144218573702437&w=2 >
>
> into kernel.org Linux Kernel 4.1.7, but Non-systemd Debian still boots
> into an emergency shell
> [...]
> mount: mounting /dev/sdaX on /root failed: no such file or directory
> Target fileystem doesn't have requested /sbin/init
> mount: mounting /dev on /root/dev failed: no such file or directory
> No init found. Try passing init= bootarg.
> [...]
>
> Typing dmesg:
> [...]
> reiser4[exe(801)]: reiser4_init_csum_tfm
> (fs/reiser4/checksum.c:11)[intelfx-81]:WARNING: Could not load crc32c
> driver
>
> In a couple of days I will build the kernel "the Debian way"; I will
> specify -- in relevant module section, at file [kernel source
> tree]debian/installer/package-list:
> [...]
>
> Package: reiser4-modules
> Depends: kernel-image crc-modules # <--- will add that
> Priority: extra
> Description: Reiser4 filesystem support
>   This package contains the Reiser4 filesystem module for the kernel.
> [...]
>
> As well as at /usr/share/kernel-wedge/package-list
>
> We will see what happens.
>
>
>> --
>> Ivan Shapovalov / intelfx /
>>
>
>


[-- Attachment #2: reiser4-select-crc32c.patch --]
[-- Type: text/x-patch, Size: 435 bytes --]

Signed-off-by: Edward Shishkin <edward.shishkin@gmail.com>
---
 fs/reiser4/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- a/fs/reiser4/Kconfig
+++ b/fs/reiser4/Kconfig
@@ -5,6 +5,7 @@ config REISER4_FS
 	select LZO_COMPRESS
 	select LZO_DECOMPRESS
 	select CRYPTO
+	select CRYPTO_CRC32C
 	help
 	  Reiser4 is a filesystem that performs all filesystem operations
 	  as atomic transactions, which means that it either performs a

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]

On 2015-09-17 at 05:10 -0700, Jose R R wrote:
> On Sun, Sep 13, 2015 at 6:06 AM, Ivan Shapovalov <
> intelfx100@gmail.com> wrote:
> > On 2015-09-13 at 05:57 -0700, Jose R R wrote:
> > > Here is some additional info:
> > > 
> > > A while back, I installed Debian Jessie AMD64 into a KVM virtual
> > > machine and also included the initial non-systemd boot argument:
> > > preseed/late_command="in-target apt-get install -y sysvinit-core"
> > > < https://wiki.debian.org/systemd#Installing_without_systemd >
> > > 
> > > Afterwards a previous reiser4-patched Linux kernel 4.0.x was
> > > installed
> > > into the virtual machine and its root fs was subsequently
> > > formatted
> > > to
> > > reiser4.. The virtual machine was working fine:
> > > < https://pbs.twimg.com/media/CKIKgoZUAAIFx12.png:large >
> > > 
> > > Yesterday, I installed into the vm a newer 4.1.6 kernel built
> > > "the
> > > debian way" except that it was customized with the newer 4.0.1
> > > Reiser4
> > > patch. Upon rebooting the VM, I captured a sequence of 4
> > > snapshots
> > > (by
> > > paging down) that basically recreate the fail that I experienced
> > > priorly in the physical machine:
> > > 
> > > < https://metztli.it/blog/index.php/ixiptli/non-systemd-debian-si
> > > d-re
> > > iser4 >
> > > 
> > > Accordingly, seems the *lack of systemd* is enough for a Debian
> > > Sid
> > > instance to create a bad initrd.img. I have no idea if issue only
> > > appears with Reiser4 root fs or if it includes other file systems
> > > as
> > > root. Work in progress...
> > 
> > It's presence/absence of crc32c module that matters. Reiser4 does
> > not
> > specify that it needs one.
> > 
> Applied your 3 patches
> 1/3 < http://marc.info/?l=reiserfs-devel&m=144218573602435&w=2 >
> 2/3 < http://marc.info/?l=reiserfs-devel&m=144218573602436&w=2 >
> 3/3 < http://marc.info/?l=reiserfs-devel&m=144218573702437&w=2 >
> 
> into kernel.org Linux Kernel 4.1.7, but Non-systemd Debian still
> boots
> into an emergency shell
> [...]
> mount: mounting /dev/sdaX on /root failed: no such file or directory
> Target fileystem doesn't have requested /sbin/init
> mount: mounting /dev on /root/dev failed: no such file or directory
> No init found. Try passing init= bootarg.
> [...]

Correct; it's now a "cleanly" reported error instead of an oops.
You will have to manually add crc32c or crc32c_intel module to the
initramfs, though. I could not find a way to express an explicit
intermodule dependency in the code (to make module reiser4 depend on
module crc32c).

Edward's patch selects module crc32c when reiser4 is selected in the
build config, but it does not make sure that crc32c will end up in the
initramfs if reiser4 is there (that is, modules.dep will not be
altered). I'm still wondering how to do that properly.

-- 
Ivan Shapovalov / intelfx /


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 3685 bytes --]

On Thu, 2015-09-17 at 18:56 +0300, Ivan Shapovalov wrote:
> On 2015-09-17 at 05:10 -0700, Jose R R wrote:
> > On Sun, Sep 13, 2015 at 6:06 AM, Ivan Shapovalov <
> > intelfx100@gmail.com> wrote:
> > > On 2015-09-13 at 05:57 -0700, Jose R R wrote:
> > > > Here is some additional info:
> > > > 
> > > > A while back, I installed Debian Jessie AMD64 into a KVM virtual
> > > > machine and also included the initial non-systemd boot argument:
> > > > preseed/late_command="in-target apt-get install -y sysvinit-core"
> > > > < https://wiki.debian.org/systemd#Installing_without_systemd >
> > > > 
> > > > Afterwards a previous reiser4-patched Linux kernel 4.0.x was
> > > > installed
> > > > into the virtual machine and its root fs was subsequently
> > > > formatted
> > > > to
> > > > reiser4.. The virtual machine was working fine:
> > > > < https://pbs.twimg.com/media/CKIKgoZUAAIFx12.png:large >
> > > > 
> > > > Yesterday, I installed into the vm a newer 4.1.6 kernel built
> > > > "the
> > > > debian way" except that it was customized with the newer 4.0.1
> > > > Reiser4
> > > > patch. Upon rebooting the VM, I captured a sequence of 4
> > > > snapshots
> > > > (by
> > > > paging down) that basically recreate the fail that I experienced
> > > > priorly in the physical machine:
> > > > 
> > > > < https://metztli.it/blog/index.php/ixiptli/non-systemd-debian-si
> > > > d-re
> > > > iser4 >
> > > > 
> > > > Accordingly, seems the *lack of systemd* is enough for a Debian
> > > > Sid
> > > > instance to create a bad initrd.img. I have no idea if issue only
> > > > appears with Reiser4 root fs or if it includes other file systems
> > > > as
> > > > root. Work in progress...
> > > 
> > > It's presence/absence of crc32c module that matters. Reiser4 does
> > > not
> > > specify that it needs one.
> > > 
> > Applied your 3 patches
> > 1/3 < http://marc.info/?l=reiserfs-devel&m=144218573602435&w=2 >
> > 2/3 < http://marc.info/?l=reiserfs-devel&m=144218573602436&w=2 >
> > 3/3 < http://marc.info/?l=reiserfs-devel&m=144218573702437&w=2 >
> > 
> > into kernel.org Linux Kernel 4.1.7, but Non-systemd Debian still
> > boots
> > into an emergency shell
> > [...]
> > mount: mounting /dev/sdaX on /root failed: no such file or directory
> > Target fileystem doesn't have requested /sbin/init
> > mount: mounting /dev on /root/dev failed: no such file or directory
> > No init found. Try passing init= bootarg.
> > [...]
> 
> Correct; it's now a "cleanly" reported error instead of an oops.
> You will have to manually add crc32c or crc32c_intel module to the
> initramfs, though. I could not find a way to express an explicit
> intermodule dependency in the code (to make module reiser4 depend on
> module crc32c).
> 
> Edward's patch selects module crc32c when reiser4 is selected in the
> build config, but it does not make sure that crc32c will end up in the
> initramfs if reiser4 is there (that is, modules.dep will not be
> altered). I'm still wondering how to do that properly.

In initramfs-tools, hook-functions has some code to handle these hidden
dependencies.  But it doesn't make a lot of sense to embed this
information there rather than in the modules themselves.

The proper way to put extra dependencies in modules is:

/* Soft module dependencies. See man modprobe.d for details.
 * Example: MODULE_SOFTDEP("pre: module-foo module-bar post: module-baz")
 */
#define MODULE_SOFTDEP(_softdep) MODULE_INFO(softdep, _softdep)

However initramfs-tools still needs to be fixed to follow these
dependencies.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 4299 bytes --]

On 2015-09-17 at 23:51 +0200, Ben Hutchings wrote:
> On Thu, 2015-09-17 at 18:56 +0300, Ivan Shapovalov wrote:
> > On 2015-09-17 at 05:10 -0700, Jose R R wrote:
> > > On Sun, Sep 13, 2015 at 6:06 AM, Ivan Shapovalov <
> > > intelfx100@gmail.com> wrote:
> > > > On 2015-09-13 at 05:57 -0700, Jose R R wrote:
> > > > > Here is some additional info:
> > > > > 
> > > > > A while back, I installed Debian Jessie AMD64 into a KVM
> > > > > virtual
> > > > > machine and also included the initial non-systemd boot
> > > > > argument:
> > > > > preseed/late_command="in-target apt-get install -y sysvinit
> > > > > -core"
> > > > > < https://wiki.debian.org/systemd#Installing_without_systemd 
> > > > > >
> > > > > 
> > > > > Afterwards a previous reiser4-patched Linux kernel 4.0.x was
> > > > > installed
> > > > > into the virtual machine and its root fs was subsequently
> > > > > formatted
> > > > > to
> > > > > reiser4.. The virtual machine was working fine:
> > > > > < https://pbs.twimg.com/media/CKIKgoZUAAIFx12.png:large >
> > > > > 
> > > > > Yesterday, I installed into the vm a newer 4.1.6 kernel built
> > > > > "the
> > > > > debian way" except that it was customized with the newer
> > > > > 4.0.1
> > > > > Reiser4
> > > > > patch. Upon rebooting the VM, I captured a sequence of 4
> > > > > snapshots
> > > > > (by
> > > > > paging down) that basically recreate the fail that I
> > > > > experienced
> > > > > priorly in the physical machine:
> > > > > 
> > > > > < https://metztli.it/blog/index.php/ixiptli/non-systemd-debia
> > > > > n-si
> > > > > d-re
> > > > > iser4 >
> > > > > 
> > > > > Accordingly, seems the *lack of systemd* is enough for a
> > > > > Debian
> > > > > Sid
> > > > > instance to create a bad initrd.img. I have no idea if issue
> > > > > only
> > > > > appears with Reiser4 root fs or if it includes other file
> > > > > systems
> > > > > as
> > > > > root. Work in progress...
> > > > 
> > > > It's presence/absence of crc32c module that matters. Reiser4
> > > > does
> > > > not
> > > > specify that it needs one.
> > > > 
> > > Applied your 3 patches
> > > 1/3 < http://marc.info/?l=reiserfs-devel&m=144218573602435&w=2 >
> > > 2/3 < http://marc.info/?l=reiserfs-devel&m=144218573602436&w=2 >
> > > 3/3 < http://marc.info/?l=reiserfs-devel&m=144218573702437&w=2 >
> > > 
> > > into kernel.org Linux Kernel 4.1.7, but Non-systemd Debian still
> > > boots
> > > into an emergency shell
> > > [...]
> > > mount: mounting /dev/sdaX on /root failed: no such file or
> > > directory
> > > Target fileystem doesn't have requested /sbin/init
> > > mount: mounting /dev on /root/dev failed: no such file or
> > > directory
> > > No init found. Try passing init= bootarg.
> > > [...]
> > 
> > Correct; it's now a "cleanly" reported error instead of an oops.
> > You will have to manually add crc32c or crc32c_intel module to the
> > initramfs, though. I could not find a way to express an explicit
> > intermodule dependency in the code (to make module reiser4 depend
> > on
> > module crc32c).
> > 
> > Edward's patch selects module crc32c when reiser4 is selected in
> > the
> > build config, but it does not make sure that crc32c will end up in
> > the
> > initramfs if reiser4 is there (that is, modules.dep will not be
> > altered). I'm still wondering how to do that properly.
> 
> In initramfs-tools, hook-functions has some code to handle these
> hidden
> dependencies.  But it doesn't make a lot of sense to embed this
> information there rather than in the modules themselves.
> 
> The proper way to put extra dependencies in modules is:
> 
> /* Soft module dependencies. See man modprobe.d for details.
>  * Example: MODULE_SOFTDEP("pre: module-foo module-bar post: module
> -baz")
>  */
> #define MODULE_SOFTDEP(_softdep) MODULE_INFO(softdep, _softdep)
> 
> However initramfs-tools still needs to be fixed to follow these
> dependencies.
> 
> Ben.
> 

Hi Ben,

yeah, I've considered softdeps, but at least in arch linux the
mkinitcpio tool doesn't look at softdeps at all.

So, there is no way to append something to the "depends" field in the
module info (i. e. "hard" dependencies). Correct?

Thanks,
-- 
Ivan Shapovalov / intelfx /


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

On Fri, 2015-09-18 at 12:51 +0300, Ivan Shapovalov wrote:
> On 2015-09-17 at 23:51 +0200, Ben Hutchings wrote:
[...]
> > The proper way to put extra dependencies in modules is:
> > 
> > /* Soft module dependencies. See man modprobe.d for details.
> >  * Example: MODULE_SOFTDEP("pre: module-foo module-bar post: module
> > -baz")
> >  */
> > #define MODULE_SOFTDEP(_softdep) MODULE_INFO(softdep, _softdep)
> > 
> > However initramfs-tools still needs to be fixed to follow these
> > dependencies.
> > 
> > Ben.
> > 
> 
> Hi Ben,
> 
> yeah, I've considered softdeps, but at least in arch linux the
> mkinitcpio tool doesn't look at softdeps at all.
> 
> So, there is no way to append something to the "depends" field in the
> module info (i. e. "hard" dependencies). Correct?

Right, the hard dependencies are calculated by depmod based on symbol
usage.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Jose R R]

On Thu, Sep 17, 2015 at 8:56 AM, Ivan Shapovalov <intelfx100@gmail.com> wrote:
> On 2015-09-17 at 05:10 -0700, Jose R R wrote:
>> On Sun, Sep 13, 2015 at 6:06 AM, Ivan Shapovalov <
>> intelfx100@gmail.com> wrote:
>> > On 2015-09-13 at 05:57 -0700, Jose R R wrote:
>> > > Here is some additional info:
>> > >
>> > > A while back, I installed Debian Jessie AMD64 into a KVM virtual
>> > > machine and also included the initial non-systemd boot argument:
>> > > preseed/late_command="in-target apt-get install -y sysvinit-core"
>> > > < https://wiki.debian.org/systemd#Installing_without_systemd >
>> > >
>> > > Afterwards a previous reiser4-patched Linux kernel 4.0.x was
>> > > installed
>> > > into the virtual machine and its root fs was subsequently
>> > > formatted
>> > > to
>> > > reiser4.. The virtual machine was working fine:
>> > > < https://pbs.twimg.com/media/CKIKgoZUAAIFx12.png:large >
>> > >
>> > > Yesterday, I installed into the vm a newer 4.1.6 kernel built
>> > > "the
>> > > debian way" except that it was customized with the newer 4.0.1
>> > > Reiser4
>> > > patch. Upon rebooting the VM, I captured a sequence of 4
>> > > snapshots
>> > > (by
>> > > paging down) that basically recreate the fail that I experienced
>> > > priorly in the physical machine:
>> > >
>> > > < https://metztli.it/blog/index.php/ixiptli/non-systemd-debian-si
>> > > d-re
>> > > iser4 >
>> > >
>> > > Accordingly, seems the *lack of systemd* is enough for a Debian
>> > > Sid
>> > > instance to create a bad initrd.img. I have no idea if issue only
>> > > appears with Reiser4 root fs or if it includes other file systems
>> > > as
>> > > root. Work in progress...
>> >
>> > It's presence/absence of crc32c module that matters. Reiser4 does
>> > not
>> > specify that it needs one.
>> >
>> Applied your 3 patches
>> 1/3 < http://marc.info/?l=reiserfs-devel&m=144218573602435&w=2 >
>> 2/3 < http://marc.info/?l=reiserfs-devel&m=144218573602436&w=2 >
>> 3/3 < http://marc.info/?l=reiserfs-devel&m=144218573702437&w=2 >
>>
>> into kernel.org Linux Kernel 4.1.7, but Non-systemd Debian still
>> boots
>> into an emergency shell
>> [...]
>> mount: mounting /dev/sdaX on /root failed: no such file or directory
>> Target fileystem doesn't have requested /sbin/init
>> mount: mounting /dev on /root/dev failed: no such file or directory
>> No init found. Try passing init= bootarg.
>> [...]
>
> Correct; it's now a "cleanly" reported error instead of an oops.
> You will have to manually add crc32c or crc32c_intel module to the
> initramfs, though. I could not find a way to express an explicit
> intermodule dependency in the code (to make module reiser4 depend on
> module crc32c).
>
> Edward's patch selects module crc32c when reiser4 is selected in the
> build config, but it does not make sure that crc32c will end up in the
> initramfs if reiser4 is there (that is, modules.dep will not be
> altered). I'm still wondering how to do that properly.
>
I applied Ed's patch, as well
< http://marc.info/?l=reiserfs-devel&m=144250028326153&w=2 >
but the non-systemd Debian instance continued to generate a bad initrd.img-.

Notwithstanding, based on your suggestions, Ivan, the solution that
works for non-systemd system is to include module directive
crc32c_intel right *before* module reiser4 directive in debian's
/etc/initramfs-tools/modules file, thus:
[...]
crc32c_intel
reiser4
[...]

and those modules will be included during initramfs-tools creation of
initrd.img-<version> file.

Thus, for a new Reiser4(4.0.1)-patched kernel image created "the
debian way", having an initrd image like: initrd.img-4.1.0-2-amd64,

update-initramfs -dk 4.1.0-2-amd64  # Removes (-d) an existing version
(-k) initramfs
update-initramfs -ck 4.1.0-2-amd64   # Creates (-c) a new version (-k) initramfs

Thus, the non-systemd Debian will generate a proper
initrd.img-<version> which will contain *both* sequenced modules *and*
will be able to successfully boot the sysvinit-based system.

I have been running a small PoC non-systemd Debian Jessie, with
Reiser4-patched Linux kernel, on Google Compute Engine (GCE)
infrastructure for over two months now[1].

< https://pbs.twimg.com/media/CPWcGMQVEAElVdi.png:large >

And I was concerned about its survival if this issue persisted.

Thank you all.


Best Professional Regards.


[1]< http://marc.info/?l=reiserfs-devel&m=143237396102328&w=2 >


-- 
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
---------------------------------------------------------------------------------------------
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!

Re: Reiser4: Format 4.0.1: Meta(data) checksums

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

On 2015-09-20 at 06:48 -0700, Jose R R wrote:
> On Thu, Sep 17, 2015 at 8:56 AM, Ivan Shapovalov <
> intelfx100@gmail.com> wrote:
> > On 2015-09-17 at 05:10 -0700, Jose R R wrote:
> > > On Sun, Sep 13, 2015 at 6:06 AM, Ivan Shapovalov <
> > > intelfx100@gmail.com> wrote:
> > > > On 2015-09-13 at 05:57 -0700, Jose R R wrote:
> > > > > [...]
> > > > > 
> > > > > Accordingly, seems the *lack of systemd* is enough for a
> > > > > Debian
> > > > > Sid
> > > > > instance to create a bad initrd.img. I have no idea if issue
> > > > > only
> > > > > appears with Reiser4 root fs or if it includes other file
> > > > > systems
> > > > > as
> > > > > root. Work in progress...
> > > > 
> > > > It's presence/absence of crc32c module that matters. Reiser4
> > > > does
> > > > not
> > > > specify that it needs one.
> > > > 
> > > Applied your 3 patches
> > > 1/3 < http://marc.info/?l=reiserfs-devel&m=144218573602435&w=2 >
> > > 2/3 < http://marc.info/?l=reiserfs-devel&m=144218573602436&w=2 >
> > > 3/3 < http://marc.info/?l=reiserfs-devel&m=144218573702437&w=2 >
> > > 
> > > into kernel.org Linux Kernel 4.1.7, but Non-systemd Debian still
> > > boots
> > > into an emergency shell
> > > [...]
> > > mount: mounting /dev/sdaX on /root failed: no such file or
> > > directory
> > > Target fileystem doesn't have requested /sbin/init
> > > mount: mounting /dev on /root/dev failed: no such file or
> > > directory
> > > No init found. Try passing init= bootarg.
> > > [...]
> > 
> > Correct; it's now a "cleanly" reported error instead of an oops.
> > You will have to manually add crc32c or crc32c_intel module to the
> > initramfs, though. I could not find a way to express an explicit
> > intermodule dependency in the code (to make module reiser4 depend
> > on
> > module crc32c).
> > 
> > Edward's patch selects module crc32c when reiser4 is selected in
> > the
> > build config, but it does not make sure that crc32c will end up in
> > the
> > initramfs if reiser4 is there (that is, modules.dep will not be
> > altered). I'm still wondering how to do that properly.
> > 
> I applied Ed's patch, as well
> < http://marc.info/?l=reiserfs-devel&m=144250028326153&w=2 >
> but the non-systemd Debian instance continued to generate a bad
> initrd.img-.
> 
> Notwithstanding, based on your suggestions, Ivan, the solution that
> works for non-systemd system is to include module directive
> crc32c_intel right *before* module reiser4 directive in debian's
> /etc/initramfs-tools/modules file, thus:
> [...]
> crc32c_intel
> reiser4
> [...]

Good. So, it's indeed lack of hard dependency between reiser4 and
crc32c that caused this error. There are softdeps, as Ben advised, but
indeed they are not taken into account by common initramfs building
tools.

I guess that this fact needs to be added to READMEs: one has to add
crc32c to their initramfs manually if one uses reiser4 on their root
partition and it is built as a module.

BTW, how is this solved in other filesystems which need some crypto or
checksum algorithms for their operation? Say, ext4?

-- 
Ivan Shapovalov / intelfx /


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]