how to boot or access problem file system
PJ
af.gourmet at videotron.ca
Fri Jul 31 20:10:41 UTC 2009
Roland Smith wrote:
> On Fri, Jul 31, 2009 at 03:12:21PM -0400, PJ wrote:
>
>> Roland Smith wrote:
>>
>>> On Thu, Jul 30, 2009 at 03:20:55PM -0400, PJ wrote:
>>>
>>>
>>>> Roland Smith wrote:
>>>>
>>>>
>>>>> On Thu, Jul 30, 2009 at 01:40:58PM -0400, PJ wrote:
>>>>>
>>>>>
>>>>>
>>>>>> What can be done to access a file system that seems to have the boot
>>>>>> sector screwed up?
>>>>>>
>>>>>>
>>> I forgot to mention that your boot sector is fine. If it were screwed
>>> up, you wouldn't get to the boot prompt.
>>>
>>> Since the boot code cannot locate your kernel, there are several things
>>> that could have gone wrong. See below.
>>>
>>> <snip>
>>>
>>>
>>>>>> The /usr files should be ok but how to access?
>>>>>>
>>>>>>
>>>>> Use fsck_ffs to try and repair the filesystem.
>>>>>
>>>>>
>>>>>
>>>> how can I use it if I can't boot or access the file system?
>>>>
>>>>
>>> Use a livefs cd or use the Fixit option in the main menu of sysinstall
>>> on an install disk. That should get you a shell where you can run
>>> fsck_ffs on your disk partitions.
>>>
>>> If you have booted from CD, list the disk devices with e.g. 'ls
>>> /dev/ad*'. If you have SCSI drives, use 'da' instead of 'ad'.
>>> What does that command list? On my machine, I'll get
>>> something like this:
>>>
>>> /dev/ad4 /dev/ad4s1d /dev/ad6 /dev/ad6s1d
>>> /dev/ad4s1 /dev/ad4s1e /dev/ad6s1 /dev/ad6s1e
>>> /dev/ad4s1a /dev/ad4s1f /dev/ad6s1a /dev/ad6s1f
>>> /dev/ad4s1b /dev/ad4s1g /dev/ad6s1b /dev/ad6s1g
>>> /dev/ad4s1c /dev/ad4s1g.eli /dev/ad6s1c /dev/ad6s1g.eli
>>>
>>> If you only see e.g. /dev/ad4 and /dev/ad6, your slice table has been
>>> overwritten (with fdisk) and your data is lost. If you see /dev/ad4s1
>>> but not /dev/ad4s1a-g, the BSD partitions have been removed and your
>>> data is lost as well.
>>>
>>> Since there is only one slice on both ad4 and ad6 (otherwise you'd see
>>> /dev/ad4s2x) The next step is to examine the disk labels:
>>>
>>> bsdlabel /dev/ad4s1
>>> # /dev/ad4s1:
>>> 8 partitions:
>>> # size offset fstype [fsize bsize bps/cpg]
>>> a: 1024000 16 4.2BSD 2048 16384 64008
>>> b: 16777216 1024016 swap
>>> c: 976768002 0 unused 0 0 # "raw" part, don't edit
>>> d: 4194304 17801232 4.2BSD 2048 16384 28528
>>> e: 104857600 21995536 4.2BSD 2048 16384 28528
>>> f: 41943040 126853136 4.2BSD 2048 16384 28528
>>> g: 807971826 168796176 4.2BSD 2048 16384 0
>>>
>>> This tells us that the a, d, e, f and g partition are carrying a BSD
>>> filesystem, and should be checked with fsck_ffs.
>>>
>>> Try these steps and report back what you find.
>>>
>>>
>>>
>>>>>> I don't have a problem with irrecoverable files, I would just finally
>>>>>> understand how things work and what can be done on FBSD.
>>>>>>
>>>>>>
>>>>> Make regular backups. Especially before big upgrades.
>>>>>
>>>>>
>>>>>
>>>> Maybe the real problem is that the manual is too screwed up (why are
>>>> there so many problems being brought up on the mailing lists? we can't
>>>> all be that stupid.)
>>>>
>>>>
>>> It is a mailing list for questions. Ipso facto you'll see questions and
>>> problems on this list. People who are not having problems will not be
>>> posting very much. :-)
>>>
>>> As to the handbook, this is by necessity written by people who are
>>> knowledgeable on the subject they write on. Unfortunately this sometimes
>>> lead to really basic steps/assumptions being skipped because they are
>>> self-evident for the writer. If you gain enough knowledge about a
>>> subject it becomes really hard to write for people new to the system
>>> because you've internalized a lot of stuff by then.
>>>
>>> If you have specific questions about parts of the handbook, ask.
>>>
>>>
>> I get the impression that my disks have all been overwritten; it's
>>
>
> Don't have impressions. Get the data. Boot from a livefs CD and start a
> shell as explained in in some of my previous messages. Then use the commands
> listed above to check your filesystems. *And report back wat you found*.
>
>
>> rather strange that in the instructions to upgrade it says to not change
>> anything on the Newfs... and that files would not be overwritten... is
>> that at fact?
>>
>
> What instructions are you referring to? Neither the handbook section
> [http://www.freebsd.org/doc/en/books/handbook/updating-freebsdupdate.html]
> nor the manual page for freebsd-update mention newfs at all! Nor should they.
>
>
Well, it sounds like we should be ok, but the instructions I am speaking
of are those on the installation disks ... when one selects the update
to a newer version and then as asked to set the slice names /; swap;
/tmp; and /var.
If I have made an error in this, then I can only put the full blame on
whoever created the installation system... there should be the most
obvious checks & balances about such an installation/upgrade as -
warnings about what the installation is going to do, and are you sure
this is what you want to do; and warnings that any existing files will
be overwritten... I have always cringed a bit when installing as there
were never any decent confirmations as to what was happening... even
Microsoft is pretty good with warning.
So, as I mentioned, I cannot access any disks as "Permission denied"
This seems to be a dead end. :-(
>> If that is true, then surely it should be possible to recover files in
>> the /usr /var and /tmp directories. If the disks have not been
>> overwritten... I think there was a huge misinformation gap here if this
>> is not so...
>>
>
> For an upgrade, the filesystems are not overwritten. Only a new install
> creates new filesystems.
>
> Please boot from a livefs CD and check the filesystems on the harddisk
> as explained before and report the results.
>
> Roland
>
--
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-------------------------------------------------------------
Phil Jourdan --- pj at ptahhotep.com
http://www.ptahhotep.com
http://www.chiccantine.com/andypantry.php
More information about the freebsd-questions
mailing list