Russell Coker writes:
> On Sat, 10 Nov 2001 06:32, James Bromberger wrote:
> > I was just updating my RAID1 box to 2.4.12 from 2.4.8, and came across
> > some problems. DevFS was not creating the files
> > /dev/ide/host0/bus0/target0/lun0/part1, part2, ..etc...
> >
> > However, there was part 11, part 12, part 5, part 6. Doing a cfdisk
> > on /dev/ide/host0/bus0/target0/lun0/disc showed very clearly that
> > all original paritions were there (1-7, where 4 does't really
> > exist because of the logical/physical/extended parition situation).
> >
> > Anyway, when I went back to 2.4.8, these partN partitions returned.
>
> rjc@lyta:/tmp$ ls -l /dev/ide/host0/bus0/target0/lun0/
> total 0
> brw-rw---- 1 root disk 3, 0 Jan 1 1970 disc
> brw-rw---- 1 root disk 3, 1 Jan 1 1970 part1
> brw-rw---- 1 root disk 3, 2 Jan 1 1970 part2
> brw-rw---- 1 root disk 3, 3 Jan 1 1970 part3
> brw-rw---- 1 root disk 3, 4 Jan 1 1970 part4
> brw-rw---- 1 root disk 3, 5 Jan 1 1970 part5
> brw-rw---- 1 root disk 3, 6 Jan 1 1970 part6
> brw-rw---- 1 root disk 3, 7 Jan 1 1970 part7
> rjc@lyta:/tmp$ uname -a
> Linux lyta 2.4.14-lsm #1 Tue Nov 6 16:16:39 CET 2001 i686 unknown
> rjc@lyta:/tmp$
>
> It also worked for me on 2.4.9, 10, 12, and 13.
>
> > My guess is a bug in the devfs kernel code. But this is a hazard.
>
> It sounds most likely. I've CC'd this message to the devfs list,
> hopefully someone there will have some useful suggestions.
Recently there was a bug introduced in the partition handling
code. Try a more recent kernel (2.4.14 or later) and see if the
problem persists. If it does, then you'll need to start putting in
debugging printk()'s to narrow down the problem. I'm concentrating on
the new devfs core, and would prefer to keep focussed on that.
BTW, Russell: I haven't seen a response from you yet to my most recent
reply to the "annoying symlink messages" thread from earlier this
week.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|