linux-kernel - Re: plain 2.6.21-rc5 (1) vs amanda (0)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 09 Apr 2007 11:33:42 -0400
From:	Gene Heskett <gene.heskett@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Dave Dillow <dave@...dillows.org>, ray-gmail@...rabbit.org,
	Ingo Molnar <mingo@...e.hu>, amanda-hackers@...nda.org,
	amanda-users@...nda.org
Subject: Re: plain 2.6.21-rc5 (1) vs amanda (0)

On Wednesday 04 April 2007, Dave Dillow wrote:
>On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
>> On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
>
>[snipped for brevity]
>
>> > [root@...ote music]# stat .
>> > Device: fd00h/64768d    Inode: 10354963    Links: 39
>> >
>> > Now rebooted to 2.6.21-rc5:
>> > Device: ee00h/60928d    Inode: 10354963    Links: 39
>>
>> For those playing along at home, I believe the issue is that GNU tar
>> sees a different device number for the directories than what is listed
>> in the listed-incremental snapshot file, and thinks all of the
>> directories are new. I've asked Gene to make a few back-to-back runs
>> of the tar command under the same kernel to see if the subsequent runs
>> figure out that there's nothing to do, as expected.
>
>Gene has confirmed that GNU tar figures it out as expected.
>
>> Then it is a matter of figuring out why the device number changed --
>> I'm thinking it is device-mapper, but will look closer tomorrow.
>
>This commit is the one that changed it:
>
>commit fdf892be32d84a1745fa0aee5fc60517421b8038
>Author: Andrew Morton <akpm@...l.org>
>Date:   Mon Feb 12 00:51:44 2007 -0800
>
>    [PATCH] register_blkdev(): don't hand out the LOCAL/EXPERIMENTAL
> majors
>
>    As pointed out in http://bugzilla.kernel.org/show_bug.cgi?id=7922,
> dynamic blockdev major allocation can hand out majors which LANANA has
> defined as being for local/experimental use.
>
>
>I'm not sure I could argue for that to be reverted, so here's a possible
>workaround for Fedora -- completely untested.
>
>Add the following to /etc/modprobe.conf:
>options dm_mod major=253

This does not work.

>And make a new initrd for the problematic kernel. This assumes that
>you're using device mapper as a module.
>
>If you're building it in, then either dm.major=253 or dm_mod.major=253
>should work on the kernel command line, but I'm not sure which it is.

I'll try this, I just put both in the kernel command line for 2.6.21-rc6, 
except I set it for the 238 it was at before the patch was reverted.  I'd 
put the patch back in myself, but my searching of the lkml corpus here 
hasn't turned it up.

>Dave



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Do not drink coffee in early A.M.  It will keep you awake until noon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/