Re: [**solved by a reboot**] moving (and losing?) partitions with cfdisk
Daniel B. wrote:
Levi Waldron wrote:
3. after changing your partition table, you really do have to reboot
- at least this is my best guess as to what the problem was.
Sometimes you can avoid the need to reboot:
If you can unmount every other partition that is on the disk whose
partition table you are modifying, then when you write the partition
table with fdisk or whatever, the kernel can re-load the partition
table and you won't get the message about needing to reboot for the
changed partitioning to take effect.
I wondered if something like that were the case.
Of course, that doesn't work for the disk containing your root
filesystem partition (because you won't be able to unmount that
partition because it's in use), but it can save rebooting if you're
repartitioning a different disk.
How about doing a mount -o remount?
There might be some work-around.
But here's a question: Why can't the kernel handle some types of
changes to a partition table (e.g., a new partition) while some
partitions are mounted?
I can think of two reasons: swap and cache.
OH, another one... The NAMES of the partitions may change.
What was, e.g. hda2 may become hda4.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [**solved by a reboot**] moving (and losing?) partitions with cfdisk
Daniel B. wrote:
Levi Waldron wrote:
3. after changing your partition table, you really do have to reboot
- at least this is my best guess as to what the problem was.
Sometimes you can avoid the need to reboot:
If you can unmount every other partition that is on the disk whose
partition table you are modifying, then when you write the partition
table with fdisk or whatever, the kernel can re-load the partition
table and you won't get the message about needing to reboot for the
changed partitioning to take effect.
I wondered if something like that were the case.
Of course, that doesn't work for the disk containing your root
filesystem partition (because you won't be able to unmount that
partition because it's in use), but it can save rebooting if you're
repartitioning a different disk.
How about doing a mount -o remount?
There might be some work-around.
But here's a question: Why can't the kernel handle some types of
changes to a partition table (e.g., a new partition) while some
partitions are mounted?
I can think of two reasons: swap and cache.
It seems that the kernel could compare the current partition table
with the previous state of the partition table (using its in-memory
data structues derived from the partition table) and determine
whether any in-use partitions have changed. If there have only been
deletions of partitions that are not mounted and/or additions of
partitions, then couldn't the kernel assimilate the changes (deleting
data structures for deleted partitions and creating data structures
for new partitions)?
You're asking for a fairly substantial change which would, IMO,
introduce (a) risk of not being "quite" right, and (b) would
only fix a rarely occurring situation (c) which only takes a
minute or two to do an extra reboot.
So why doesn't the kernel do that? Is it just that no one felt it
was a useful enough feature to implement? Is it that the kernel's
data structures (or code using them) aren't set up for deleting and
adding partitions incrementally? Or is there some bigger limitation?
I'd guess that the usefulness is outweighed by the complexity/likelihood
of getting it wrong and the little cost (except possibly to servers)
in time to reboot.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [**solved by a reboot**] moving (and losing?) partitions with cfdisk
Levi Waldron wrote: 3. after changing your partition table, you really do have to reboot - at least this is my best guess as to what the problem was. Sometimes you can avoid the need to reboot: If you can unmount every other partition that is on the disk whose partition table you are modifying, then when you write the partition table with fdisk or whatever, the kernel can re-load the partition table and you won't get the message about needing to reboot for the changed partitioning to take effect. Of course, that doesn't work for the disk containing your root filesystem partition (because you won't be able to unmount that partition because it's in use), but it can save rebooting if you're repartitioning a different disk. But here's a question: Why can't the kernel handle some types of changes to a partition table (e.g., a new partition) while some partitions are mounted? It seems that the kernel could compare the current partition table with the previous state of the partition table (using its in-memory data structues derived from the partition table) and determine whether any in-use partitions have changed. If there have only been deletions of partitions that are not mounted and/or additions of partitions, then couldn't the kernel assimilate the changes (deleting data structures for deleted partitions and creating data structures for new partitions)? So why doesn't the kernel do that? Is it just that no one felt it was a useful enough feature to implement? Is it that the kernel's data structures (or code using them) aren't set up for deleting and adding partitions incrementally? Or is there some bigger limitation? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [**solved by a reboot**] moving (and losing?) partitions with cfdisk
On Fri, Feb 17, 2006 at 10:40:27AM -0800, Levi Waldron wrote: > So I got up this morning (on the west coast, as you hoped), booted up > into knoppix again, and started backing up my MBR and first sector of > each partition. Then I noticed an icon on the knoppix desktop listing > hda7 as a mountable partition, so I thought I'd try it again. Exactly > the same way as last night, > > sudo mount /dev/hda7 /mnt > > but it mounted!!! No errors. So I immediately backed up off-site > everything I might possibly need, including the MBR and first sectors Hi Levi, congrats on the success. A disaster averted. here is what happened to me once. I did dd if=/dev/hda of=/dev/hdb where 'a' was a small hd and 'b' was a bigger hd. I was cfdisk'ing the newer one sometime later when I made a mistake. I thought I screwed it up but did not format anything. so I used sfdisk to make a copy of the 'a' disk partion table and used it to make a copy on 'b' and this restored the 'b' hd to its former partions. Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: [**solved by a reboot**] moving (and losing?) partitions with cfdisk
Levi Waldron wrote:
So I got up this morning (on the west coast, as you hoped), booted up
into knoppix again, and started backing up my MBR and first sector of
each partition. Then I noticed an icon on the knoppix desktop listing
hda7 as a mountable partition, so I thought I'd try it again. Exactly
the same way as last night,
sudo mount /dev/hda7 /mnt
but it mounted!!! No errors. So I immediately backed up off-site
Oh, frabjous day! Calloo! Callay!
I'm happy for you. Also explains why I couldn't find anything wrong
with your new setup.
I also passed this along to the Fedora Core list where I am
(some think way too) active, so you may be getting some
messages from some over there.
everything I might possibly need, including the MBR and first sectors
of each partition. Then rebooted without knoppix, making no changes,
and success! I even have the two new partitions I wanted.
I remember now that cfdisk warns you that you may need to reboot in
order to read the new partition table properly, but it just didn't
occur to me this time. I'm sure glad I didn't start deleting and
re-creating the partition table.
Worked out for the best, even better than one would hope.
Several lessons learned, a _relatively_ easy way:
1. backups don't count unless you have them on hand
Apropos of this: they also don't count if they don't survive
the disaster that destroyed the original. Keep a copy of your
critical backups off-site, at least a few miles away. Then if your
house burns down or Hurricane Katrina floods your house,
you still have your data.
2. in addition to data, back up the MBR and first sector of each
partition before messing with the partition table:
dd if=/dev/hda of=hda.mbr bs=512 count=1
dd if=/dev/hdax of=hdax.mbr bs=512 count=1
3. after changing your partition table, you really do have to reboot
- at least this is my best guess as to what the problem was.
Thank you for all your efforts Mike! I'll return the favour to
someone if I can't to you :)
That's been called "pay forward" by, IIRC, Heinlein.
Next time I go off on an OT rant here, and get into trouble,
with people calling me a flamer and requesting I be booted
off the list, you jump in and say "Hey, wait a minute! He's
really a nice guy! Sometimes, anyway!"
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[**solved by a reboot**] moving (and losing?) partitions with cfdisk
So I got up this morning (on the west coast, as you hoped), booted up into knoppix again, and started backing up my MBR and first sector of each partition. Then I noticed an icon on the knoppix desktop listing hda7 as a mountable partition, so I thought I'd try it again. Exactly the same way as last night, sudo mount /dev/hda7 /mnt but it mounted!!! No errors. So I immediately backed up off-site everything I might possibly need, including the MBR and first sectors of each partition. Then rebooted without knoppix, making no changes, and success! I even have the two new partitions I wanted. I remember now that cfdisk warns you that you may need to reboot in order to read the new partition table properly, but it just didn't occur to me this time. I'm sure glad I didn't start deleting and re-creating the partition table. Several lessons learned, a _relatively_ easy way: 1. backups don't count unless you have them on hand 2. in addition to data, back up the MBR and first sector of each partition before messing with the partition table: dd if=/dev/hda of=hda.mbr bs=512 count=1 dd if=/dev/hdax of=hdax.mbr bs=512 count=1 3. after changing your partition table, you really do have to reboot - at least this is my best guess as to what the problem was. Thank you for all your efforts Mike! I'll return the favour to someone if I can't to you :)
Re: moving (and losing?) partitions with cfdisk
Levi Waldron wrote:
I had some unused space at the beginning of my hard drive, with my
partition table looking something like:
Well, I hoped to see a bunch of messages and one of them
being a RESOLVED.
The only new thing I can think of is that, since this partition
was at the bottom of the old extended partition, it's BR
got overwritten when the extended got expanded down. I don't
know why that would be. The old MSDOS fdisk was notorious
for overwriting the BPB when modifying partitions when it
was not necessary.
If you send me a copy of the first sector of that partition,
I can get out some old docs I have on the layout of the BR,
and see whether it looks clobbered. Can anyone say whether
the layout is consistent with the old days? My docs are all
for MSDOS. I'd guess that the portions of the old BPB which
describe the partition and give the start of the file system
are unchanged, so as to be compatible with Win..
Well, it's 09:00 here in Texas. I hope that you are on the
West Coast or something so you have more time to get some
help.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: moving (and losing?) partitions with cfdisk
Levi Waldron wrote:
2006/2/16, Mike McCarty <[EMAIL PROTECTED]>:
Remember, before doing anything to try to fix this, copy off
your MBR, and the first sector of each partition you need to
^^
[snip]
Will do, tomorrow. My laptop is still networked (thanks knoppix!) so
Yes, KNOPPIX is a wonderful tool. I use Fedora Core on my machine, but
I support my girlfriend's machine, whom I talked into installing
Linux instead of WinXP. I downloaded several LiveCDs for her to try,
and KNOPPIX was the one she liked best, so I got her to use Debian.
So I came here the better to support her.
I can email partition/sector data. I presume that I should backup the
the first sector of each partition using dd?
Umm, I guess you are asking technique? Yes, dd is what I had
in mind.
You get the MBR using /dev/hda, you get the first sector
of the partitions from /dev/hda1, /dev/hda7, etc.
But you knew that.
Shoot us an e-mail about what happened when you can.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: moving (and losing?) partitions with cfdisk
Levi Waldron wrote:
Mike, I'm going to have to add you to my holiday card list, regardless
of what happens :)
I just wish I could help.
Everything looks like it ought to. I don't see why there would be
a problem.
[snip]
I'm going to call it a night and see if if there's any more advice by
morning, then start making changes to hda in the morning when I'm more
awake. Yeah, I do need the machine for work, and have learned a good
Back before I got laid off so long ago (telecom) I used to have a
piece of paper stuck on my office wall which I got from a book
about building some musical equipment at home from wood. Most mistakes
are made when one is doing "one last thing" while tired and just
before going to bed. The solution is "never do the last thing".
Always put it off until tomorrow, when you'll be rested.
I think this is a good decision.
rule 0 as you pointed out: don't mess with the partition table while
on the road. It seems like I've messed with quite a few partition
tables without any problems, and I guess I got brash :(.
It's happened to all of us, me included. No one is unsusceptible to
making a SUD (seemingly unimportant decision) which later turns
out to be an important decision that gets him into trouble. I don't
know how many times I've said to myself "I've done this before,
I can do it again. There won't be a problem." when in my heart
of hearts I know I'm taking a risk.
I will certainly keep you posted.
Good luck, good night, and I hope you rest well. I hope someone
can tell you exactly what to do to get fixed up, and if not then
I hope you can use KNOPPIX to get some of your work done.
I wish I could have helped :-(
On the brighter side, you *do* have a backup, so everything will
eventually be ok. :-)
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: moving (and losing?) partitions with cfdisk
2006/2/16, Mike McCarty <[EMAIL PROTECTED]>: > Remember, before doing anything to try to fix this, copy off > your MBR, and the first sector of each partition you need to > save. I know you don't have a floppy, but do you have a USB > stick? Something? Anything? How about this: copy them off to > your KNOPPIX RAM disc, and e-mail them to the debian user group > as attachments, or at least to yourself. Then if things get > worse, you can pull them back to your RAM disc again, and > perhaps reinstall them. If you want a little insurance, > e-mail me directly, and I'll copy them off. Then if you > really need them back, I can e-mail them or send you a floppy. Will do, tomorrow. My laptop is still networked (thanks knoppix!) so I can email partition/sector data. I presume that I should backup the the first sector of each partition using dd?
Re: moving (and losing?) partitions with cfdisk
Mike, I'm going to have to add you to my holiday card list, regardless of what happens :) I triple-checked that I'm trying to mount the correct partition and did it without using fstab, and that's not the problem, for example: [EMAIL PROTECTED] sudo umount /mnt (to unmount the root partition) [EMAIL PROTECTED] sudo mount /dev/hda7 /mnt/home mount: error while guessing filesystem type mount: you must specify the filesystem type -t ext2 or -t ext3 doesn't help (it's ext3). I'm going to call it a night and see if if there's any more advice by morning, then start making changes to hda in the morning when I'm more awake. Yeah, I do need the machine for work, and have learned a good rule 0 as you pointed out: don't mess with the partition table while on the road. It seems like I've messed with quite a few partition tables without any problems, and I guess I got brash :(. I will certainly keep you posted.
Re: moving (and losing?) partitions with cfdisk
Levi Waldron wrote:
I had some unused space at the beginning of my hard drive, with my
partition table looking something like:
Remember, before doing anything to try to fix this, copy off
your MBR, and the first sector of each partition you need to
save. I know you don't have a floppy, but do you have a USB
stick? Something? Anything? How about this: copy them off to
your KNOPPIX RAM disc, and e-mail them to the debian user group
as attachments, or at least to yourself. Then if things get
worse, you can pull them back to your RAM disc again, and
perhaps reinstall them. If you want a little insurance,
e-mail me directly, and I'll copy them off. Then if you
really need them back, I can e-mail them or send you a floppy.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: moving (and losing?) partitions with cfdisk
Levi Waldron wrote:
I had some unused space at the beginning of my hard drive, with my
partition table looking something like:
Ok, what is possible is that the geometry written to the beginning
of the new partitions is not correct, and so the start of /home
is now being miscomputed somehow. I don't see how there was
any need to write to any of the active locations (except possibly
you messed up something with the GRUB update, but that shouldn't
clobber the FS, only the first sector of the partition). I don't
know enough about ext2/ext3 to know how to find the superblock
and verify that it's ok. But my guess is that if you delete the
two new partitions, then you might just be ok. My guess is that
you've not lost any actual data, but it might be difficult
to reconstruct the superblock for the ext2/3 partition you have
/home on. I know that I can't do it for you.
I recommend you wait for a better expert. I've given it my
best shot here, and I can't explain why you can't do that
mount, nothing should have happened to that partition at all.
(Except possibly you messed up fstab, though that's a weak
guess.)
If you just feel the need to do *something*, then you should try
deleting the two new partitions, attempting to revert the
PT to its original state, cross your fingers, and reboot
KNOPPIX. You might luck out and find that /home will just
mount, or if the label causes a problem, at least it will
pass fsck. If so, then you could try to recover bootable
state by backing out the changes to fstab.
It depends on how lucky you feel. I dunno where you are,
but where I am it's 01:30 and I'd guess you might need
to get some sleep and be able to work tomorrow.
Er, unless you need your machine to do your work.
Step 0 before messing with partitions: don't do it
on the road.
:-(
Sorry about your situation. I wish I could help you more.
I just can't see anything that would clobber that. (I made
the two guesses above, but they're pretty weak and not very
likely guesses.)
I'm going to be up for a while yet. If something occurs to
me, I'll send another message just in case you are hanging
on still, or if you just want to send some more info or
need a shoulder to cry on. If you make progress or do something
let me know how it came out.
Good luck. I'm still pullin' for you.
I really wish I could figure out what's wrong. :-(
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: moving (and losing?) partitions with cfdisk
I've read up a bit from the Partition-Rescue mini-howto, and am not feeling so panicked any more. My understanding is that cfdisk would have *only* changed the partition table, which resides on the MBR. And since I haven't accessed the portion of the disk for which I changed the partition table, there should be no data loss. All I have to do is restore the partition table to its original state, and everything will be just as it was. Its recommended course of action, *if* you have a copy of your original partition table, is to delete all your partitions and re-create them using fdisk. I am tempted to use cfdisk to delete the two logical partitions I created then try to mount /home, (still from knoppix) to see if that reverses the changes. If not, there are instructions in that howto for figuring out where your partition starts and ends, which looks annoying but possible. I think the smartest thing for me to do right now is sleep on it, see what advice those on this list have, then do it with a fresh mind in the morning. Mike, thank you for your replies - they are coming only to me, not to the list, just in case that is unintentional. It didn't take any time at all to write the changes I made in cfdisk, just a second or two. So perhaps it moved the location of the partitions without moving the data? Here is the output of fdisk -u and fdisk -u -l: [EMAIL PROTECTED] sudo fdisk -l Disk /dev/hda: 15 heads, 63 sectors, 62016 cylinders Units = cylinders of 945 * 512 bytes Device BootStart EndBlocks Id System /dev/hda1 * 54181 62015 3702037+ c Win95 FAT32 (LBA) /dev/hda2 * 43847 54180 4882815 83 Linux /dev/hda3 1 43846 20717203+ 5 Extended /dev/hda5 * 1 9720 4592195+ 83 Linux /dev/hda6 * 9720 11787976626 83 Linux /dev/hda7 11787 42788 14648413+ 83 Linux /dev/hda8 42789 43846499873+ 82 Linux swap Partition table entries are not in disk order [EMAIL PROTECTED] sudo fdisk -u -l Disk /dev/hda: 15 heads, 63 sectors, 62016 cylinders Units = sectors of 1 * 512 bytes Device BootStart EndBlocks Id System /dev/hda1 * 51200100 58604174 3702037+ c Win95 FAT32 (LBA) /dev/hda2 * 41434470 51200099 4882815 83 Linux /dev/hda363 41434469 20717203+ 5 Extended /dev/hda5 * 126 9184516 4592195+ 83 Linux /dev/hda6 * 9184580 11137831976626 83 Linux /dev/hda7 11137833 40434659 14648413+ 83 Linux /dev/hda8 40434723 41434469499873+ 82 Linux swap Partition table entries are not in disk order [EMAIL PROTECTED] (I'm including Mike's last message below for the archives, as it has some useful info in it) 2006/2/17, Mike McCarty <[EMAIL PROTECTED]>: > Levi Waldron wrote: > > 2006/2/17, Mike McCarty <[EMAIL PROTECTED]>: > > > >>First step before messing with partitions: do a backup. > >>Second step before messing with partitions: save your MBR on a floppy. > >>Third step before messing with partitions: save the first sector > >>of each partition on a floppy. > > > > > > I have backups at home of everything important on the home partition, > > but I'm on the road right now and it will be very annoying if I have > > to resort to that... more info than needed though :). Point taken, > > backup backup backup. The MBR didn't seem like a big deal to me > > because I don't have a floppy, and figured I could always rebuild it > > from Knoppix. I didn't know about saving the first sector of each > > partition - thank you an I will in the future. > > The first sector of each partition is the Boot Record > for that partition, sometimes also called the BPB, > though that's rather dated and not actually applicable > for non-MSDOS partitions. > > First thing I did with my machine after I got it home > was add a floppy disc drive. Dunno why they don't come > with 'em any more. > > >>I dunno what you have in your MBR for boot code, but > >>I don't see how you created two more if you have a > >>"normal" setup. With a normal setup, you can only > >>have up to four partitions, one of which can be > >>"extended" and have logical partitions in it. > >>You already had three partitions, so how did you > >>add two more? I suppose that hda5 and hda6 are inside > >>of an extended partition you created before. Or are > >>you using LVM? If you use LVM, I can't help you much > >>if at all. > >> > >>What does fdisk say? > >>What were the start/end addresses before you changed the PT? > > The stuff to look at is the start/end disc addresses for the > partitions, and the types. What I see here does not indicate > that you simply moved some partitions down, unless cfdisk > actually copied a bunch of data. That would have taken a > significant amount of time. E.g. to copy /home to hda7 would > require copying 15 GB which would take several minutes. > > I hope you understand that I'm sitting here reading this stuff > and
moving (and losing?) partitions with cfdisk
Ok, I've drawn a map of your disc, both presumed before and
after, and I think I know what cfdisk did.
Before you did anything, you had either three or four
entries in your PT, it's hard to tell, as cfdisk is
not actually showing your PT. But anyway, you had
Primary Bootable Win95 FAT32 (hda1)
Primary Bootable Linux ext3 (hda2) /
Extended
Inside the extended you had two logical partitions
(*) Linux swap (hda6)
(*) Linux ext3 (hda5) /home
What happened is that the extended partition got it's
bottom end moved down, from the bottom of what was hda5
to the beginning of the disc, and two more partitions
were created inside the new extended partition space.
Nothing of the original partitions got copied or moved.
There should have been no need to overwrite anything in
any of the existing partitions. Ok. The first sector of
each partition inside a logical partition contains its
"geometry" (BPB). Creating partitions causes writes to
the beginnings of new partitions. But I don't see any
need to write to the beginning of partitions clobbering
anything in the middle of the existing partitions. (This
geometry stuff is why I mentioned saving the first sector
of each partition. Your grub update overwrote the first
sector, possibly, of one of the partitions.)
Do you have GRUB installed into the MBR? I guess so.
Your new setup looks like it preserves all the old
partitions intact, just expanded the extended.
So it looks like the names of the partitions are:
New Old Type
=== ===
hda1hda1Win95
hda2hda2ext3 (/)
hda5
hda6
hda7hda5ext3 (/home)
hda8hda6swap
Hmm. I can't see anything wrong. That partition should not have
been touched at all. I don't see that anything needed to be
written except to these disc addresses
0 new PT
63 geometry of new logical partition
9184517 geometry of new logical partition
I don't see why any other writes needed to be done.
Even if the grub update overwrote one of the partition
beginnings, it shouldn't clobber the FS, since the FS
should be *after* GRUB.
Hmm. I'm going to have to ponder, but I can't explain
why you have problems with the mount. Have you tried
a direct mount, not using the fstab entry? Possibly
the fstab is messed up. What is in there now?
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
moving (and losing?) partitions with cfdisk
You still there?
Things don't look too bad to me, so far.
Still here, making some progress...
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: moving (and losing?) partitions with cfdisk
> of an extended partition you created before. Or are > you using LVM? If you use LVM, I can't help you much > if at all. Sorry, I didn't answer this before: no, I'm not using LVM. [EMAIL PROTECTED] ls /mnt bin cdrom etc initrd lib media opt root srv tmp var boot devhome initrd.img lost+found mntproc sbin sys usr vmlinuz [EMAIL PROTECTED] find /mnt/usr/share/doc | grep lvm [EMAIL PROTECTED]
Re: moving (and losing?) partitions with cfdisk
2006/2/17, Mike McCarty <[EMAIL PROTECTED]>: > First step before messing with partitions: do a backup. > Second step before messing with partitions: save your MBR on a floppy. > Third step before messing with partitions: save the first sector > of each partition on a floppy. I have backups at home of everything important on the home partition, but I'm on the road right now and it will be very annoying if I have to resort to that... more info than needed though :). Point taken, backup backup backup. The MBR didn't seem like a big deal to me because I don't have a floppy, and figured I could always rebuild it from Knoppix. I didn't know about saving the first sector of each partition - thank you an I will in the future. > I dunno what you have in your MBR for boot code, but > I don't see how you created two more if you have a > "normal" setup. With a normal setup, you can only > have up to four partitions, one of which can be > "extended" and have logical partitions in it. > You already had three partitions, so how did you > add two more? I suppose that hda5 and hda6 are inside > of an extended partition you created before. Or are > you using LVM? If you use LVM, I can't help you much > if at all. > > What does fdisk say? > What were the start/end addresses before you changed the PT? Here's my partition table now, in a couple different formats: cfdisk 2.11u Disk Drive: /dev/hda Size: 30005821440 bytes, 30.0 GB Heads: 15 Sectors per Track: 63 Cylinders: 62016 NameFlags Part Type FS Type [Label]Size (MB) -- hda5BootLogical Linux 4702.45* hda6BootLogical Linux 1000.10* hda7NC Logical Linux ext3 [/home] 14999.98* hda8Logical Linux swap 511.91 hda2BootPrimary Linux ext3 [/] 5000.01 hda1BootPrimary Win95 FAT32 (LBA) 3790.89 Primary Free Space 0.49 Partition Table for /dev/hda FirstLast # Type Sector Sector Offset Length Filesystem Type (ID) Flags -- --- - -- - -- - 3 Primary0 41434469 63 41434470 Extended (05) None (00) 5 Logical 63* 9184516* 63 9184454* Linux (83) Boot (80) 6 Logical 9184517*11137831* 63 1953315 Linux (83) Boot (80) 7 Logical 11137832*40434659 1#29296828* Linux (83) None (00) 8 Logical 40434660 41434469 63 999810 Linux swap (82)None (00) 2 Primary 41434470 51200099 0 9765630 Linux (83) Boot (80) 1 Primary 51200100 58604174 0 7404075 Win95 FAT32 (LBA) (0C) Boot (80) Primary 58604175 58605119 0 945 Free Space None (00) I didn't print the partition table before the changes, but it would have looked like this, gotten by deleting the two new partitions in cfdisk (without saving the changes): cfdisk 2.11u Disk Drive: /dev/hda Size: 30005821440 bytes, 30.0 GB Heads: 15 Sectors per Track: 63 Cylinders: 62016 NameFlags Part Type FS Type [Label]Size (MB) -- Pri/Log Free Space5702.57* hda5NC Logical Linux ext3 [/home] 14999.98* hda6Logical Linux swap 511.91 hda2BootPrimary Linux ext3 [/] 5000.01 hda1BootPrimary Win95 FAT32 (LBA) 3790.89 Primary Free Space 0.49 Partition Table for /dev/hda FirstLast # Type Sector Sector Offset Length Filesystem Type (ID) Flags -- --- - -- - -- - Pri/Log0 11137831* 0#11137832* Free Space None (00) 3 Primary 11137832*41434469 0 30296638* Extended (05) None (00) 5 Logical 11137832*40434659 1#29296828* Linux (83) None (00) 6 Logical 40434660 41434469 63 999810 Linux swap (82)None (00) 2 Primary 41434470 51200099 0 9765630 Linux (83) Boot (80) 1 Primary 51200100 58604174 0 7404075 Win95 FAT32 (LBA) (0C) Boot (80) Primary 58604175 58605119 0 945 Free Space None (00) > Well, yo
moving (and losing?) partitions with cfdisk
I had some unused space at the beginning of my hard drive, with my partition table looking something like: 5700MB free space hda5 logical linux ext3 [/home] hda6 logical linux swap hda2 primary linux ext3 [/] hda1 primary other OS I wanted to use the free space, so I booted up Knoppix and used cfdisk created two new partitions, putting th. But this moved my existing hda5 and hda6 to hda7 and hda8. No problem, I thought, I mounted the root fs and updated fstab and grub. Then I tried mounting home, and got a very scary error: (nb. I chrooted into hda2 first) #mount /home mount: wrong fs tyupe, bad option, bad superblock on /dev/hda7. missing codepage or other error (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?) In some cases useful info is found in syslog - try dmesg | tail or so And e2fsck doesn't recognize it: #e2fsck /dev/hda7 e2fsck 1.39-WIP (31-Dec-2005) e2fsck: Invalid argument while trying to open /dev/hda7 The superblock could not be read or does not describe a correct ext23 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 I'm still in Knoppix and haven't touched the modified partitions, so can I get my home partition back? Why did t his happen?
