Re: udev memory problem when trying to plug a disk with corrupted partition table
Le 02.12.2014 19:27, tv.deb...@googlemail.com a écrit : On 02/12/2014 20:48, berenger.mo...@neutralite.org wrote: [cut] Also, what is EBR (or EPBR, which seems to be some sort of enhanced whatever may be a EBR)? Extended Boot Record on DOS disks ? Where information about extended partition is stored. https://en.wikipedia.org/wiki/Extended_boot_record To fix things, I tried to take a look at testdisk, which was able to find partitions. Lot of them, in facts, included lot of... removed partitions (I did a lot of experiments on that disk before). Plus, I have no idea about how to ask it (testdisk) to fix, apply things? Any document about how to use it? Not the man, I already have read it, and it's plain useless. I think you read French, if not the page is available in English too. I do. http://www.cgsecurity.org/wiki/TestDisk_FR It's from TestDisk author. Hope it helps. It does, thanks. For now, I'll keep that disk in that state, in case informations and testing might be useful to maintainers. I'll try to repair things in few weeks, probably. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1915fb753c0f30e56bf720c82d006...@neutralite.org
Re: udev memory problem when trying to plug a disk with corrupted partition table
On 02/12/2014 20:48, berenger.mo...@neutralite.org wrote: [cut] Also, what is EBR (or EPBR, which seems to be some sort of enhanced whatever may be a EBR)? Extended Boot Record on DOS disks ? Where information about extended partition is stored. https://en.wikipedia.org/wiki/Extended_boot_record To fix things, I tried to take a look at testdisk, which was able to find partitions. Lot of them, in facts, included lot of... removed partitions (I did a lot of experiments on that disk before). Plus, I have no idea about how to ask it (testdisk) to fix, apply things? Any document about how to use it? Not the man, I already have read it, and it's plain useless. I think you read French, if not the page is available in English too. http://www.cgsecurity.org/wiki/TestDisk_FR It's from TestDisk author. Hope it helps. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547e0491.7080...@googlemail.com
Re: udev memory problem when trying to plug a disk with corrupted partition table
Le 20.11.2014 22:26, Scott Ferguson a écrit : On 21/11/14 06:45, Pascal Hambourg wrote: Scott Ferguson a écrit : Might be worth fscking the disk first in case that's where the problem lies. Why ? fsck works on filesystems, not disks or partition tables. Good question - because I didn't spend much time thinking about it, or, because I haven't used ms-dos partition tables for a very long time? :/ Regardless - maybe badblocks would be a better way of checking if the problem is a result of damage to where the E(P)BRs are written? Certainly simpler than examining the E(P)BRs for errors which would be my next course of action if I had no backups of the disk. (I suspect) There are at least two possible scenarios(?) which would result in a problem that the OP is experiencing[*1]:- ;the OP accidentally overwrote an EBR i.e. created another extended partition at some later point (1st sector of the extended partition?) ;a damaged sector containing an EBR In the first case parted rescue may/should be able to fix the problem. The OP could probably get more info by checking the E(P)BRs. The problem 'might' be in the first or last E(P)BR (again, I 'suspect' Martin is right about the looping) Perhaps (from unreliable memory):- dd if=/dev/sdc bs=512 count=1 skip=22026238 | hexdump -C likewise with the last extended partition, and then the same on the E(P)BRs 'might' show the error? I note that's a lot of suspicions, mights, and guesses - but again, I welcome input and correction. [*1] I'm guessing, and welcome input - as I suspect would the OP An interesting problem, sadly the person most likely to know the answer hasn't been seen on the lists for some time. Kind regards First, sorry for delay and thanks for replies. I won't have time to fix this for now, I will try to find time ASAP. Not that I really mind the data which were on that disk, but it will allow me to tinker with partition tables and such things on which I do not have a good knowledge. I had even no idea that logical partitions were a chained list, but now that you say it, it makes sense. Also, what is EBR (or EPBR, which seems to be some sort of enhanced whatever may be a EBR)? To fix things, I tried to take a look at testdisk, which was able to find partitions. Lot of them, in facts, included lot of... removed partitions (I did a lot of experiments on that disk before). Plus, I have no idea about how to ask it (testdisk) to fix, apply things? Any document about how to use it? Not the man, I already have read it, and it's plain useless. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e68e09075ad78cad0db7cb232b53f...@neutralite.org
Re: udev memory problem when trying to plug a disk with corrupted partition table
On 21/11/14 06:45, Pascal Hambourg wrote: > Scott Ferguson a écrit : >> >> Might be worth fscking the disk first in case that's where the problem lies. > > Why ? fsck works on filesystems, not disks or partition tables. > > Good question - because I didn't spend much time thinking about it, or, because I haven't used ms-dos partition tables for a very long time? :/ Regardless - maybe badblocks would be a better way of checking if the problem is a result of damage to where the E(P)BRs are written? Certainly simpler than examining the E(P)BRs for errors which would be my next course of action if I had no backups of the disk. (I suspect) There are at least two possible scenarios(?) which would result in a problem that the OP is experiencing[*1]:- ;the OP accidentally overwrote an EBR i.e. created another extended partition at some later point (1st sector of the extended partition?) ;a damaged sector containing an EBR In the first case parted rescue may/should be able to fix the problem. The OP could probably get more info by checking the E(P)BRs. The problem 'might' be in the first or last E(P)BR (again, I 'suspect' Martin is right about the looping) Perhaps (from unreliable memory):- dd if=/dev/sdc bs=512 count=1 skip=22026238 | hexdump -C likewise with the last extended partition, and then the same on the E(P)BRs 'might' show the error? I note that's a lot of suspicions, mights, and guesses - but again, I welcome input and correction. [*1] I'm guessing, and welcome input - as I suspect would the OP An interesting problem, sadly the person most likely to know the answer hasn't been seen on the lists for some time. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546e5c7e.9010...@gmail.com
Re: udev memory problem when trying to plug a disk with corrupted partition table
Scott Ferguson a écrit : > > Might be worth fscking the disk first in case that's where the problem lies. Why ? fsck works on filesystems, not disks or partition tables. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546e44d7.7040...@plouf.fr.eu.org
Re: udev memory problem when trying to plug a disk with corrupted partition table
On 20/11/14 20:13, Pascal Hambourg wrote: > Scott Ferguson a écrit : >> On 20/11/14 12:45, Martin Read wrote: >>> On 20/11/14 01:03, Scott Ferguson wrote: >> On 20/11/14 04:06, "Morel Bérenger" wrote: >>> I think it's msdos. AFAIK mdos partition tables don't support anywhere near that number of slices. :( > > MS-DOS partition tables support any number of logical partitions. ... using E(P)BRs - limited only by disk space for them. Thanks for the correction Pascal, apologies to the OP for the misinformation. > >>> MSDOS extended partitions contain a linked list of logical partitions. >>> It looks, from the pattern of that table, like the linked list has been >>> corrupted so as to form a cycle. > > Indeed, after logical partition 8 it seems to loop back to logical > partition 6. > >> A dd of the first 512 bytes will show you whether you've overextended >> your MBR. If you have - that will explain the corruption (dos is limited >> to 512b). > > No, the MBR does not contain the chained extended partition tables. correct (again), they can be located anywhere on the disk > >> The somewhat good news is that it's fixable. > > Yes. If recovery tools such as testdisk or gpart cannot fix the loop, my > tool of choice would be sfdisk to export, edit by hand (keep partitions > 1 to 8 only) and recreate the partition table. Might be worth fscking the disk first in case that's where the problem lies. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546dc4a8.8070...@gmail.com
Re: udev memory problem when trying to plug a disk with corrupted partition table
Scott Ferguson a écrit : > On 20/11/14 12:45, Martin Read wrote: >> On 20/11/14 01:03, Scott Ferguson wrote: > On 20/11/14 04:06, "Morel Bérenger" wrote: >> I think it's msdos. >>> AFAIK mdos partition tables don't support anywhere near that number of >>> slices. :( MS-DOS partition tables support any number of logical partitions. >> MSDOS extended partitions contain a linked list of logical partitions. >> It looks, from the pattern of that table, like the linked list has been >> corrupted so as to form a cycle. Indeed, after logical partition 8 it seems to loop back to logical partition 6. > A dd of the first 512 bytes will show you whether you've overextended > your MBR. If you have - that will explain the corruption (dos is limited > to 512b). No, the MBR does not contain the chained extended partition tables. > The somewhat good news is that it's fixable. Yes. If recovery tools such as testdisk or gpart cannot fix the loop, my tool of choice would be sfdisk to export, edit by hand (keep partitions 1 to 8 only) and recreate the partition table. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546db0ab.40...@plouf.fr.eu.org
Re: udev memory problem when trying to plug a disk with corrupted partition table
Le Mon, 17 Nov 2014 16:56:51 +0100, berenger.mo...@neutralite.org a écrit : > Now, fact is that the hard-disk partition table is no longer correct, > and when I plug it (it is an USB HD) into a Debian system, it makes > udev eating all my memory, and more. Could you please open a bugreport against udev with all the information like the fdisk output and such? I feel that even if the partition table is invalid, it shouldn't DoS udev. Thanks! Laurent Bigonville -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120100825.562a7...@fornost.bigon.be
Re: udev memory problem when trying to plug a disk with corrupted partition table
On 20/11/14 12:45, Martin Read wrote: > On 20/11/14 01:03, Scott Ferguson wrote: On 20/11/14 04:06, "Morel Bérenger" wrote: > I think it's msdos. >> >> AFAIK mdos partition tables don't support anywhere near that number of >> slices. :( > > MSDOS extended partitions contain a linked list of logical partitions. > It looks, from the pattern of that table, like the linked list has been > corrupted so as to form a cycle. > > A dd of the first 512 bytes will show you whether you've overextended your MBR. If you have - that will explain the corruption (dos is limited to 512b). The somewhat good news is that it's fixable. You can, provided you duplicate the original beginning and ends, to convert the MBR to GPT (use parted) - but it's highly recommended that you backup your data first. Having said that - if you can back-up the data I'd recommend using GPT and LVM. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546d4ef8.5090...@gmail.com
Re: udev memory problem when trying to plug a disk with corrupted partition table
On 20/11/14 01:03, Scott Ferguson wrote: On 20/11/14 04:06, "Morel Bérenger" wrote: I think it's msdos. AFAIK mdos partition tables don't support anywhere near that number of slices. :( MSDOS extended partitions contain a linked list of logical partitions. It looks, from the pattern of that table, like the linked list has been corrupted so as to form a cycle. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546d47a2.2080...@zen.co.uk
Re: udev memory problem when trying to plug a disk with corrupted partition table
On 20/11/14 11:14, "Morel Bérenger" wrote: > Le Mer 19 novembre 2014 21:16, Scott Ferguson a écrit : >> On 20/11/14 04:06, "Morel Bérenger" wrote: >> >>> Le Lun 17 novembre 2014 19:32, Henrique de Moraes Holschuh a écrit : >>> On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote: > So, what part of that disk should I extract, which could be usable > and sharable? Partition table, of course, which is probably at > disk's beginning, but how long might it be? That depends. What kind of partition table? >>> >>> >>> I think it's msdos. AFAIK mdos partition tables don't support anywhere near that number of slices. :( I 'believe' it's possible to convert a dos partition table to GPT, but can't find any guide in my notes. Perhaps some other list reader or a search engine can help?? >>> >> >> >> Could you post the output of "fdisk -l /dev/$ProblematicDisk" please >> (you'll need to run the command as root)? > > Note that I think this output is actuall not complete, I suspect fdisk to > not trying to show the whole one. > > > # fdisk -l /dev/sdc > Warning: omitting partitions after #60. > They will be deleted if you save this partition table. > Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546d3df0.6060...@gmail.com
Re: udev memory problem when trying to plug a disk with corrupted partition table
Le Mer 19 novembre 2014 21:16, Scott Ferguson a écrit : > On 20/11/14 04:06, "Morel Bérenger" wrote: > >> Le Lun 17 novembre 2014 19:32, Henrique de Moraes Holschuh a écrit : >> >>> On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote: >>> >>> So, what part of that disk should I extract, which could be usable and sharable? Partition table, of course, which is probably at disk's beginning, but how long might it be? >>> >>> That depends. What kind of partition table? >>> >> >> >> I think it's msdos. >> > > > Could you post the output of "fdisk -l /dev/$ProblematicDisk" please > (you'll need to run the command as root)? Note that I think this output is actuall not complete, I suspect fdisk to not trying to show the whole one. # fdisk -l /dev/sdc Warning: omitting partitions after #60. They will be deleted if you save this partition table. Disk /dev/sdc: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x80b686b1 Device Boot Start End Blocks Id System /dev/sdc1 *2048 1050623 524288 83 Linux /dev/sdc2 10506242202419110486784b W95 FAT32 /dev/sdc322026238 520376319 2491750415 Extended /dev/sdc4 520376320 976773119 228198400 83 Linux /dev/sdc5220262408389222330932992 83 Linux /dev/sdc683894272 14680883131457280 a9 NetBSD /dev/sdc7 373573632 39454515110485760 83 Linux /dev/sdc8 394547200 52037631962914560 83 Linux /dev/sdc983894272 14680883131457280 a9 NetBSD /dev/sdc10 373573632 39454515110485760 83 Linux /dev/sdc11 394547200 52037631962914560 83 Linux /dev/sdc12 83894272 14680883131457280 a9 NetBSD /dev/sdc13 373573632 39454515110485760 83 Linux /dev/sdc14 394547200 52037631962914560 83 Linux /dev/sdc15 83894272 14680883131457280 a9 NetBSD /dev/sdc16 373573632 39454515110485760 83 Linux /dev/sdc17 394547200 52037631962914560 83 Linux /dev/sdc18 83894272 14680883131457280 a9 NetBSD /dev/sdc19 373573632 39454515110485760 83 Linux /dev/sdc20 394547200 52037631962914560 83 Linux /dev/sdc21 83894272 14680883131457280 a9 NetBSD /dev/sdc22 373573632 39454515110485760 83 Linux /dev/sdc23 394547200 52037631962914560 83 Linux /dev/sdc24 83894272 14680883131457280 a9 NetBSD /dev/sdc25 373573632 39454515110485760 83 Linux /dev/sdc26 394547200 52037631962914560 83 Linux /dev/sdc27 83894272 14680883131457280 a9 NetBSD /dev/sdc28 373573632 39454515110485760 83 Linux /dev/sdc29 394547200 52037631962914560 83 Linux /dev/sdc30 83894272 14680883131457280 a9 NetBSD /dev/sdc31 373573632 39454515110485760 83 Linux /dev/sdc32 394547200 52037631962914560 83 Linux /dev/sdc33 83894272 14680883131457280 a9 NetBSD /dev/sdc34 373573632 39454515110485760 83 Linux /dev/sdc35 394547200 52037631962914560 83 Linux /dev/sdc36 83894272 14680883131457280 a9 NetBSD /dev/sdc37 373573632 39454515110485760 83 Linux /dev/sdc38 394547200 52037631962914560 83 Linux /dev/sdc39 83894272 14680883131457280 a9 NetBSD /dev/sdc40 373573632 39454515110485760 83 Linux /dev/sdc41 394547200 52037631962914560 83 Linux /dev/sdc42 83894272 14680883131457280 a9 NetBSD /dev/sdc43 373573632 39454515110485760 83 Linux /dev/sdc44 394547200 52037631962914560 83 Linux /dev/sdc45 83894272 14680883131457280 a9 NetBSD /dev/sdc46 373573632 39454515110485760 83 Linux /dev/sdc47 394547200 52037631962914560 83 Linux /dev/sdc48 83894272 14680883131457280 a9 NetBSD /dev/sdc49 373573632 39454515110485760 83 Linux /dev/sdc50 394547200 52037631962914560 83 Linux /dev/sdc51 83894272 14680883131457280 a9 NetBSD /dev/sdc52 373573632 39454515110485760 83 Linux /dev/sdc53 394547200 52037631962914560 83 Linux /dev/sdc54 83894272 14680883131457280 a9 NetBSD /dev/sdc55 373573632 39454515110485760 83 Linux /dev/sdc56 394547200 52037631962914560 83 Linux /dev/sdc57 83894272 14680883131457280 a9 NetBSD /dev/sdc58 373573632 39454515110485760 83 Linux /dev/sdc59 394547200 52037631962914560 83 Linux /dev/sdc60 83894272 14680883131457280 a9 NetBSD Partition
Re: udev memory problem when trying to plug a disk with corrupted partition table
On 20/11/14 04:06, "Morel Bérenger" wrote: > Le Lun 17 novembre 2014 19:32, Henrique de Moraes Holschuh a écrit : >> On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote: >> >>> So, what part of that disk should I extract, which could be usable >>> and sharable? Partition table, of course, which is probably at disk's >>> beginning, but how long might it be? >> >> That depends. What kind of partition table? > > > I think it's msdos. Could you post the output of "fdisk -l /dev/$ProblematicDisk" please (you'll need to run the command as root)? Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546cfa85.7050...@gmail.com
Re: udev memory problem when trying to plug a disk with corrupted partition table
Le Lun 17 novembre 2014 19:32, Henrique de Moraes Holschuh a écrit : > On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote: > >> So, what part of that disk should I extract, which could be usable >> and sharable? Partition table, of course, which is probably at disk's >> beginning, but how long might it be? > > That depends. What kind of partition table? I think it's msdos. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/809e8ede7e86b324f49cf9511e455fa4.squir...@www.sud-ouest.org
Re: udev memory problem when trying to plug a disk with corrupted partition table
On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote: > So, what part of that disk should I extract, which could be usable > and sharable? Partition table, of course, which is probably at > disk's beginning, but how long might it be? That depends. What kind of partition table? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117183207.ge24...@khazad-dum.debian.net
Re: udev memory problem when trying to plug a disk with corrupted partition table
Le 17.11.2014 17:55, Henrique de Moraes Holschuh a écrit : On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote: Now, fact is that the hard-disk partition table is no longer correct, and when I plug it (it is an USB HD) into a Debian system, it makes udev eating all my memory, and more. Please image the partition table so that someone can reproduce the issue and fix it... looks like an useful test case :-) I think that udev crashes, instead of simply acknowledging that it It is likely triggering a bug somewhere in the load of stuff we run when a disk is hotplugged to create the links in /dev/by-uuid, etc. I.e. maybe the bug is not in udev itself. So, does anyone know how to make udev stopping gracefully to detect the full list of partitions, and restrict itself to real hardware? The kernel itself parses the partition table. Did it output any error messages? Also, I should probably report that bug, but how could I find more informations to provide, since I strongly doubt that it can be reproduced, and so fixed, without the "correct" partition table? Indeed. Either preserve enough of that partition table to be able to reproduce the bug, or give up on it ever being found at the moment you decide to clean up the disk to be able to use it :-( I've already built an image of the disk, but it's a 500GB disk. I doubt you'll want to download it hehe. So, what part of that disk should I extract, which could be usable and sharable? Partition table, of course, which is probably at disk's beginning, but how long might it be? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d997408f450877b3ee228348b0ed9...@neutralite.org
Re: udev memory problem when trying to plug a disk with corrupted partition table
On Mon, 17 Nov 2014, berenger.mo...@neutralite.org wrote: > Now, fact is that the hard-disk partition table is no longer > correct, and when I plug it (it is an USB HD) into a Debian system, > it makes udev eating all my memory, and more. Please image the partition table so that someone can reproduce the issue and fix it... looks like an useful test case :-) > I think that udev crashes, instead of simply acknowledging that it It is likely triggering a bug somewhere in the load of stuff we run when a disk is hotplugged to create the links in /dev/by-uuid, etc. I.e. maybe the bug is not in udev itself. > So, does anyone know how to make udev stopping gracefully to detect > the full list of partitions, and restrict itself to real hardware? The kernel itself parses the partition table. Did it output any error messages? > Also, I should probably report that bug, but how could I find more > informations to provide, since I strongly doubt that it can be > reproduced, and so fixed, without the "correct" partition table? Indeed. Either preserve enough of that partition table to be able to reproduce the bug, or give up on it ever being found at the moment you decide to clean up the disk to be able to use it :-( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117165515.gb24...@khazad-dum.debian.net
