Andrew Morton ([email protected]) wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.66/2.5.66-mm1/
LVM or device mapper seems to be broken in -mm. I've only tried the
following kernels so far:
2.5.64 - works
2.5.65-mm2 - doesn't work
2.5.66 - works
2.5.66-mm1 - doesn't work
I'm getting these messages while setting up LVM from my bootscripts (I've
included the actual commands prefixed with a > ):
Remounting root file system (/) read/write for vgscan...
> mount -n -o remount,rw /
Removing old device inodes...
> rm /dev/system/* /dev/mapper/*
Setting up devices...
> /usr/local/sbin/devmap_mknod.sh
Creating /dev/mapper/control character device with major:10 minor:63.
Scanning for LVM volume groups...
> /usr/local/sbin/vgscan
Reading all physical volumes. This may take a while...
Found volume group "system" using metadata type lvm1
Activating LVM volume groups...
> /usr/local/sbin/vgchange -a y system
device-mapper: allocating minor 0.
device-mapper: allocating minor 1.
device-mapper: destroying md
device-mapper: destroying table
device-mapper: allocating minor 0.
device-mapper: destroying md
device-mapper: destroying table
1 logical volume(s) in volume group "system" now active
The only active volume is the most recently created volume.
On 2.5.6x-vanilla the output of vgchange is:
device-mapper: allocating minor 0.
device-mapper: allocating minor 1.
device-mapper: allocating minor 2.
3 logical volume(s) in volume group "system" now active
--
Erik Hensema <[email protected]>
Hi,
Andrew Morton ([email protected]) wrote:
>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.66/2.5.66-mm1/
LVM or device mapper seems to be broken in -mm. I've only tried the
following kernels so far:
2.5.64 - works
2.5.65-mm2 - doesn't work
2.5.66 - works
2.5.66-mm1 - doesn't work
Just another data point. LVM in -mm stopped working for me at
2.5.65-mm2, it did work in 2.5.65-mm1. 2.5.65-mm[234] did not work
either.
Regards,
Shane
On Wed, Mar 26, 2003 at 12:26:37PM +0000, Erik Hensema wrote:
> Andrew Morton ([email protected]) wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.66/2.5.66-mm1/
> LVM or device mapper seems to be broken in -mm. I've only tried the
> following kernels so far:
> 2.5.64 - works
> 2.5.65-mm2 - doesn't work
> 2.5.66 - works
> 2.5.66-mm1 - doesn't work
Probably you are hit by
dev_t-32-bit.patch
[for playing only] change type of dev_t
This is hidden somewhat in the 100+ patches in -mm,
but the kernel is not quite ready yet - that is
why this is labeled "not to be applied, for
playing only". Mostly things work, but some stuff
related to lvm, md, dm, nfs, loop will break
because ioctls use structs with a dev_t field.
You can revert this single patch and probably all will be fine.
More interesting would be to apply
http://marc.theaimsgroup.com/?l=linux-kernel&m=103956089203199&w=3
if possible, and see whether that helps.
You can see some earlier discussion today under a subject
containing the word dm_ioctl.
Andries
Andries Brouwer ([email protected]) wrote:
> On Wed, Mar 26, 2003 at 12:26:37PM +0000, Erik Hensema wrote:
>> Andrew Morton ([email protected]) wrote:
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.66/2.5.66-mm1/
>
>> LVM or device mapper seems to be broken in -mm. I've only tried the
>> following kernels so far:
>> 2.5.64 - works
>> 2.5.65-mm2 - doesn't work
>> 2.5.66 - works
>> 2.5.66-mm1 - doesn't work
>
> Probably you are hit by
>
> dev_t-32-bit.patch
> [for playing only] change type of dev_t
[...]
> You can revert this single patch and probably all will be fine.
For now I've reverted this patch and LVM is working again.
> More interesting would be to apply
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103956089203199&w=3
I'd rather not change the ioctl interface, since that would make dual
booting with 2.5-vanilla harder.
--
Erik Hensema <[email protected]>
On Wed, Mar 26, 2003 at 03:33:26PM +0100, Erik Hensema wrote:
> > You can revert this single patch and probably all will be fine.
>
> For now I've reverted this patch and LVM is working again.
Good.
> > More interesting would be to apply
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=103956089203199&w=3
>
> I'd rather not change the ioctl interface, since that would make dual
> booting with 2.5-vanilla harder.
The ioctl has a version field:
struct dm_ioctl {
uint32_t version[3];
...
and the above patch changes version 1.6.0 into 2.0.0.
With sufficiently recent user space utilities all
should work: they can find out the interface version
using the DM_VERSION ioctl, and then adapt what
they send to the kernel.
(I don't know whether such up-to-date utilities exist.)
Andries
On Wednesday, March 26, 2003, at 04:03 PM, Andries Brouwer wrote:
> (I don't know whether such up-to-date utilities exist.)
Alasdair Kergon should be making a new release of the dm utilities in
the next couple of days. Once this has been done we will be free to
fix the broken ioctl interface in 2.5.
- Joe
On Wed, Mar 26, 2003 at 05:03:50PM +0100, Andries Brouwer wrote:
> With sufficiently recent user space utilities all
> should work: they can find out the interface version
> using the DM_VERSION ioctl, and then adapt what
> they send to the kernel.
We need to start tracking down what userspace needs fixing
still. We also should iron out our representations. eg, hpa's
recommendation for 64bits, or the 12/20 split for 32bit, or etc.
Joel
--
Life's Little Instruction Book #451
"Don't be afraid to say, 'I'm sorry.'"
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
On Wed, Mar 26, 2003 at 10:47:23AM -0800, Joel Becker wrote:
> We need to start tracking down what userspace needs fixing.
My current series of patches is for the ioctls that use a
structure with dev_t field. If someone has time to burn,
or has automated tools that can identify these, that would
be good.
There is a double audit: find these ioctls, and then find
the userspace tools that use them.
For example, struct umsdos_ioctl has twice dev_t followed
by padding. Probably these should become unsigned longs.
I'll send a patch later tonight.
Is it used anywhere? That requires detective work.
It is used by the utilities udosctl (a useless demo utility),
umssync and umssetup. I do not know of any others.
No doubt people will tell me what I overlooked.
Less conservative people will tell me that umsdos has to
be killed entirely.
In old posts and other letters I have mentioned some more ioctls.
The list is not long but they have to be examined one by one,
and in some cases correspondence with authors/maintainers
is required.
> We also should iron out our representations. eg, hpa's
> recommendation for 64bits, or the 12/20 split for 32bit, or etc.
There is no hurry. These changes are just editing a few lines
in kdev_t.h. I tend to prefer 64 bits, like hpa.
Maybe I should send another patch tonight, just for playing.
Andries
On Wed, Mar 26, 2003 at 09:52:28PM +0100, Andries Brouwer wrote:
> > We also should iron out our representations. eg, hpa's
> > recommendation for 64bits, or the 12/20 split for 32bit, or etc.
>
> There is no hurry. These changes are just editing a few lines
> in kdev_t.h. I tend to prefer 64 bits, like hpa.
> Maybe I should send another patch tonight, just for playing.
Please, I'd like that. It does actually matter, because glibc
and mknod (to name a couple) have to pass a proper dev_t for the new
format (glibc actually does an explicit conversion to 8:8 in
sysdeps/sysv/linux/xmkmod.c, which we need to fix to the proper
mapping).
Stuff like that.
Joel
--
"This is the end, beautiful friend.
This is the end, my only friend the end
Of our elaborate plans, the end
Of everything that stands, the end
No safety or surprise, the end
I'll never look into your eyes again."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
On Wed, Mar 26, 2003 at 09:52:28PM +0100, Andries Brouwer wrote:
> For example, struct umsdos_ioctl has twice dev_t followed
> by padding. Probably these should become unsigned longs.
> I'll send a patch later tonight.
>
> Is it used anywhere? That requires detective work.
> It is used by the utilities udosctl (a useless demo utility),
> umssync and umssetup. I do not know of any others.
> No doubt people will tell me what I overlooked.
> Less conservative people will tell me that umsdos has to
> be killed entirely.
Isn't it still horribly broken ? I remember Al putting it on
the "To be fixed later" burner, but never saw anything happen
to it after that asides from janitor style fixes.
Dave
From: Dave Jones <[email protected]>
> For example, struct umsdos_ioctl has twice dev_t followed
> by padding. Probably these should become unsigned longs.
> I'll send a patch later tonight.
>
> Is it used anywhere? That requires detective work.
> It is used by the utilities udosctl (a useless demo utility),
> umssync and umssetup. I do not know of any others.
> No doubt people will tell me what I overlooked.
> Less conservative people will tell me that umsdos has to
> be killed entirely.
Isn't it still horribly broken ? I remember Al putting it on
the "To be fixed later" burner, but never saw anything happen
to it after that asides from janitor style fixes.
Yes, umsdos is victim of bitrot.
Al broke it with his patch called MA37-break-umsdos-C3-pre3.
Afterwards people doing global changes failed to do them on
umsdos, so the amount of work required to get umsdos in the
shape it was before (working, but with races and other problems)
increases in time.
I failed to cc the list on the patch referred to above.
It is rather useless since umsdos is broken, but at least
prevents increased bitrot. Let me include it here.
Andries
diff -u --recursive --new-file -X /linux/dontdiff a/include/linux/umsdos_fs.h b/include/linux/umsdos_fs.h
--- a/include/linux/umsdos_fs.h Fri Nov 22 22:40:12 2002
+++ b/include/linux/umsdos_fs.h Wed Mar 26 22:31:14 2003
@@ -49,7 +49,7 @@
# else
# define Printk(x)
# endif
-#endif
+#endif /* __KERNEL__ */
struct umsdos_fake_info {
@@ -70,8 +70,7 @@
time_t atime; /* Access time */
time_t mtime; /* Last modification time */
time_t ctime; /* Creation time */
- dev_t rdev; /* major and minor number of a device */
- /* special file */
+ unsigned short rdev; /* major and minor of a device special file */
umode_t mode; /* Standard UNIX permissions bits + type of */
char spare[12]; /* unused bytes for future extensions */
/* file, see linux/stat.h */
@@ -129,34 +128,32 @@
struct umsdos_ioctl {
struct dirent dos_dirent;
struct umsdos_dirent umsdos_dirent;
- /* The following structure is used to exchange some data
- * with utilities (umsdos_progs/util/umsdosio.c). The first
- * releases were using struct stat from "sys/stat.h". This was
- * causing some problem for cross compilation of the kernel
- * Since I am not really using the structure stat, but only some field
- * of it, I have decided to replicate the structure here
- * for compatibility with the binaries out there
+ /* The following structure is used to exchange some data with
+ * utilities (umsdos_progs/util/umsdosio.c). The first releases
+ * were using struct stat from "sys/stat.h". This was causing
+ * some problem for cross compilation of the kernel.
+ * Since I am not really using the structure stat, but only
+ * some fields of it, I have decided to replicate the structure
+ * here for compatibility with the binaries out there.
* FIXME PTW 1998, this has probably changed
*/
struct {
- dev_t st_dev;
- unsigned short __pad1;
- ino_t st_ino;
- umode_t st_mode;
+ unsigned long st_dev;
+ ino_t st_ino; /* used */
+ umode_t st_mode; /* used */
nlink_t st_nlink;
__kernel_uid_t st_uid;
__kernel_gid_t st_gid;
- dev_t st_rdev;
- unsigned short __pad2;
- off_t st_size;
+ unsigned long st_rdev;
+ off_t st_size; /* used */
unsigned long st_blksize;
unsigned long st_blocks;
- time_t st_atime;
+ time_t st_atime; /* used */
unsigned long __unused1;
- time_t st_mtime;
+ time_t st_mtime; /* used */
unsigned long __unused2;
- time_t st_ctime;
+ time_t st_ctime; /* used */
unsigned long __unused3;
uid_t st_uid32;
gid_t st_gid32;
[all fields without comment /* used */ might just as well
be called dummy; in particular, only the size of st_dev,
st_rdev matters, the value is not used]