today I did an update from 7.2-RELEASE-p4 to 8.0-RELEASE using
freebsd-update.
Everything went smooth, apart from the fact that I can't mount my second
disk.
It's all a bit puzzling...
Here are the facts:
[root@talisker ~]# cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/ad4s2b none swap sw O O
/dev/ad4s1a / ufs rw 1 1
/dev/ad4s2a /tmp ufs rw 2 2
/dev/ad4s2d /var ufs rw 2 2
/dev/ad4s2e /usr ufs rw 2 2
/dev/ad8s1a /BACKUP ufs rw 2 2
/dev/acd0 /cdrom cd9660 ro,noauto 0 0
linproc /compat/linux/proc linprocfs rw 0 0
The offending entry which isn't mountable anymore is ad8s1.
[root@talisker ~]# sysctl kern.disks
kern.disks: ad8 ad4
fdisk and bsdlabel are showing my s1a partition/slice:
[root@talisker ~]# fdisk ad8
******* Working on device /dev/ad8 *******
parameters extracted from in-core disklabel are:
cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 781422705 (381554 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 52/ head 15/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
[root@talisker ~]# bsdlabel ad8
# /dev/ad8:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 781422752 16 unused 0 0
c: 781422768 0 unused 0 0 # "raw" part,
don't edit
but:
[root@talisker ~]# mount /dev/ad8s1a /BACKUP/
mount: /dev/ad8s1a : No such file or directory
And in fact:
[root@talisker ~]# ls -l /dev/ad8*
crw-r----- 1 root operator 0, 91 Dec 15 17:58 /dev/ad8
crw-r----- 1 root operator 0, 96 Dec 15 17:58 /dev/ad8a
Huu? What's going on here? Where is s1?
Never seen that before... (and I'm using FreeBSD since 4.0-RELEASE).
and this mount obviously won't work either:
[root@talisker ~]# mount /dev/ad8a /BACKUP/
mount: /dev/ad8a : Invalid argument
Anybody any idea how to recover here?
The server is unluckily remote and in production. A downgrade back to
7.2 would be kinda difficult. I'd like to avoid that.
Ideas anyone?
Thanks in advance,
Marian
PS.:
dmesg: http://crivens.terrorteam.de/~rabauke/FreeBSD/dmesg-8.0-release.txt
[root@talisker ~]# uname -rms
FreeBSD 8.0-RELEASE i386
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
This is not true. The problem is that sysinstall creates an invalid
"dangerously dedicated" disk, as demonstrated by doing:
# fdisk ad8
(shows FreeBSD slice information)
# bsdlabel ad8
(shows valid but empty disk label)
Marian just needs to wipe out the second sector on the disk to
remove the BSD disklabel that prevents the kernel from using
the master boot record in the 1st sector. This exposes ad8s1.
This then will pick up the BSD disklabel in sector 65 (i.e.
the second sector in slice 1) to give ad8s1a...
> fdisk output appears to indicate that your disk has a partition table, but I
> never looked at one with fdisk that was "dedicated"...
fdisk may or may not show partitions. Typically there should not
be any, because it's the disklabel in sector 2 that holds the
partition information. The "MBR" in the first sector is there only
for the BIOS: you can't boot without one.
--
Marcel Moolenaar
xcl...@mac.com
Are you able to clarify exactly what is no longer working in 8? I've
read things here and there about dangerously dedicated disks no longer
being supported, but no detail about what exactly had changed. You seem
to be implying here that there is only a problem if there are invalid
and/or overlapping labels on the disk; elsewhere I have read that disks
without an MBR aren't supported at all (I presume the faked-up MBR on a
GPT disk counts). If I currently have a working ad2{b,c,d,e}, will they
be picked up by 8, or would I have to repartition slightly smaller with
a useless MBR slice in front?
Ben
My $0.02: what about labelling them, say, tunefs -L on UFS partitions,
and glabel for swap, then change corresponding entry in fstab. Say:
- Start into single user
- tunefs -L root /
- reboot into single user <--- reboot required after tuning /
- mount -u /; mount -a
- vi /etc/fstab and change "/dev/ad0a" to "/dev/ufs/root"
- umount -a
- tunefs -L other partitions
- mount -a
- vi /etc/fstab and change the rest
- reboot
Cheers,
--
Xin LI <del...@delphij.net> http://www.delphij.net
> Quoth Marcel Moolenaar <xcl...@mac.com>:
>> On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote:
>>>>
>>> FreeBSD 8.0 no longer supports "dangerously dedicated" disks.
>>
>> This is not true. The problem is that sysinstall creates an invalid
>> "dangerously dedicated" disk, as demonstrated by doing:
>> # fdisk ad8
>> (shows FreeBSD slice information)
>>
>> # bsdlabel ad8
>> (shows valid but empty disk label)
>>
>> Marian just needs to wipe out the second sector on the disk to
>> remove the BSD disklabel that prevents the kernel from using
>> the master boot record in the 1st sector. This exposes ad8s1.
>> This then will pick up the BSD disklabel in sector 65 (i.e.
>> the second sector in slice 1) to give ad8s1a...
>
> Are you able to clarify exactly what is no longer working in 8?
Everything is working, but behaviour has changed for invalid
disks. Invalid disks are disks with conflicting partitioning
information. In FreeBSD 8.x the behaviour is deterministic
and for the broken dangerously dedicated disks that sysinstall
creates this means that we use the partition information in
the BSD disklabel. In FreeBSD 7.x this could come from either
the MBR or the BSD disklabel, with the MBR the more common
scenario.
> You seem
> to be implying here that there is only a problem if there are invalid
> and/or overlapping labels on the disk; elsewhere I have read that disks
> without an MBR aren't supported at all (I presume the faked-up MBR on a
> GPT disk counts).
Disks without an MBR are supported.
> If I currently have a working ad2{b,c,d,e}, will they
> be picked up by 8, or would I have to repartition slightly smaller with
> a useless MBR slice in front?
Yes, if you have ad2a and not ad2s1a, then you have a
proper dangerously dedicated disk and FreeBSD 8.x will
work correctly with your disk.
If you installed "dangerously dedicated" and ended up
with ad0s1a (note the "s1"), then you have an invalid
partitioning and FreeBSD 8.x will not give you what
you've been getting on FreeBSD 7.x. Most of the time
you only need to wipe out the second sector on the
disk to clean it up and have FreeBSD 8.x also give
you ad0s1a.
--
Marcel Moolenaar
xcl...@mac.com
Yes, I've already done that. However, if gpart doesn't pick up the
underlying ad2d partition glabel won't know to look for a label, so the
entry in /dev/ufs won't show up either.
Ben
Right. However, if I were to take a system that worked with 7.x and
upgrade, and found that the disks were no longer detected, I would
consider that to be 'not working' :).
> Invalid disks are disks with conflicting partitioning
> information. In FreeBSD 8.x the behaviour is deterministic
> and for the broken dangerously dedicated disks that sysinstall
> creates this means that we use the partition information in
> the BSD disklabel. In FreeBSD 7.x this could come from either
> the MBR or the BSD disklabel, with the MBR the more common
> scenario.
OK, so this is all actually about a bug in sysinstall. It might be nice
if the UPDATING entry mentioned this: as it stands it is not clear this
doesn't affect people who created proper disklabels by hand (including
the obligatory dd to wipe out old MBR labels before starting).
> > If I currently have a working ad2{b,c,d,e}, will they
> > be picked up by 8, or would I have to repartition slightly smaller with
> > a useless MBR slice in front?
>
> Yes, if you have ad2a and not ad2s1a, then you have a
> proper dangerously dedicated disk and FreeBSD 8.x will
> work correctly with your disk.
Thank you for explaining.
If you use the UFS ID label instead you don't need to reboot because you
don't modify the superblock :)
You can find the ID with..
line=`dumpfs 2> /dev/null $1 | head | grep superblock\ location`
# dumpfs doesn't print leading 0s
echo $line | sed -nEe 's/superblock location.*id.*\[ (.*)(.*)\ ]/printf %0x $((0x\1 << 32 | 0x\2))/p'
(in an sh like shell)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
On Tue, 15 Dec 2009 16:46:27 -0800, Marcel Moolenaar <xcl...@mac.com>
wrote:
>
> Yes, if you have ad2a and not ad2s1a, then you have a
> proper dangerously dedicated disk and FreeBSD 8.x will
> work correctly with your disk.
>
> If you installed "dangerously dedicated" and ended up
> with ad0s1a (note the "s1"), then you have an invalid
> partitioning and FreeBSD 8.x will not give you what
> you've been getting on FreeBSD 7.x. Most of the time
> you only need to wipe out the second sector on the
> disk to clean it up and have FreeBSD 8.x also give
> you ad0s1a.
>
okay... but how do I wipe out the second sector?
dd if=/dev/zero of=/dev/ad8 count=1
would wipe out the first 512 bytes. I'm always confused with sectors vs.
bytes.
hm... since this disk is my second disk and was only used for backups, I
might as well bsdlabel and newfs it again. Losing all data then, but well,
sounds easier so far to me.
And I'd like to avoid reboots, if possible.
Again, I'm booting from ad4 and this works fine. I should be able to toy
around with ad8 without rebooting or going into single user.
Thanks so far,
Marian
You need to add seek=1 (or oseek=1, which is the same but a little bit more
obvious) to that command.
> I'm always confused with sectors vs.
> bytes.
You are not confused this time, HDD sector is 512 bytes. This is the default dd
block size too.
--
Andriy Gapon
So what's an easy recipe we can run on 7.x hosts to see whether we
would have problems with 8.x?
Steinar Haug, Nethelp consulting, sth...@nethelp.no
On Wed, 16 Dec 2009 12:55:38 +0200, Andriy Gapon <a...@icyb.net.ua> wrote:
> on 16/12/2009 11:28 Marian Hettwer said the following:
>> Hej Marcel,
>>
>>
>> On Tue, 15 Dec 2009 16:46:27 -0800, Marcel Moolenaar <xcl...@mac.com>
>> wrote:
>>> Yes, if you have ad2a and not ad2s1a, then you have a
>>> proper dangerously dedicated disk and FreeBSD 8.x will
>>> work correctly with your disk.
>>>
>>> If you installed "dangerously dedicated" and ended up
>>> with ad0s1a (note the "s1"), then you have an invalid
>>> partitioning and FreeBSD 8.x will not give you what
>>> you've been getting on FreeBSD 7.x. Most of the time
>>> you only need to wipe out the second sector on the
>>> disk to clean it up and have FreeBSD 8.x also give
>>> you ad0s1a.
>>>
>> okay... but how do I wipe out the second sector?
>> dd if=/dev/zero of=/dev/ad8 count=1
>> would wipe out the first 512 bytes.
>
> You need to add seek=1 (or oseek=1, which is the same but a little bit
> more
> obvious) to that command.
>
gee, thanks!
That worked.
root@talisker:/root# ls /dev/ad8*
/dev/ad8 /dev/ad8s1 /dev/ad8s1a
root@talisker:/root# mount /dev/ad8s1a /BACKUP/
root@talisker:/root# umount /BACKUP/
but, hm, whats that?
root@talisker:/root# fsck /dev/ad8s1a
fsck: Could not determine filesystem type
>> I'm always confused with sectors vs.
>> bytes.
>
> You are not confused this time, HDD sector is 512 bytes. This is the
> default dd
> block size too.
>
Good to know!
Cheers,
Marian
>From what's been said so far: If you have adXsY devices in 7, *and*
bsdlabel adX
finds a valid label (*note*: that is the whole disk, not the slice),
then you have conflicting BSD and MBR labels at the start of the disk
and you will have a problem in 8.
Ben
So presumably if I have root on ad4s1a today, and bsdlabel shows
# bsdlabel ad4
bsdlabel: /dev/ad4: no valid label found
then I am ready for FreeBSD 8.x?
Steinar Haug, Nethelp consulting, sth...@nethelp.no
If you don't have an entry for /dev/ad8s1a in your fstab, you need to
specify the filesystem type with -t.
Jeff
I minor inconvenience for the time being. fsck hasn't
been thought about getting partition types from gpart,
so that it can do a best-effort attempt at guessing
which variant to run. For now, you need to be explicit:
fsck -t ufs /dev/ad0s1a
Alternatively, add an entry to /etc/fstab.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
>> If you installed "dangerously dedicated" and ended up
>> with ad0s1a (note the "s1"), then you have an invalid
>> partitioning and FreeBSD 8.x will not give you what
>> you've been getting on FreeBSD 7.x. Most of the time
>> you only need to wipe out the second sector on the
>> disk to clean it up and have FreeBSD 8.x also give
>> you ad0s1a.
>
> So what's an easy recipe we can run on 7.x hosts to see whether we
> would have problems with 8.x?
If
1. fdisk ${D} shows FreeBSD slices, and
2. your mount points are within these slices (i.e your device name
has a prefix of ${D}s1, ${D}s2, ${D}s3, etc *OR* they have a
prefix of ${D}cs1 ${D}cs2 ${D}cs3, etc), and
3. bsdlabel ${D} shows that there's a (possibly empty) BSD disklabel
then you have an invalidly created danerously dedicated disk.
You can wipe out the second sector on the disk to clear the bogus
BSD disklabel.
The most important thing to look at is how you currently mount.
If fdisk ${D} and bsdlabel ${D} show valid information and you
mount from ${D}a, ${D}d, etc -- then your disk is not necessarily
invalid in the same sense that having a PMBR with slices in front
of a GPT is not considered invalid.
I for one would rather *not* see fsck extended in this way. The whole
point of fsck is that you're running it on a potentially-broken disk;
guessing is not helpful at that point :).
Ben
I think so (but I'm no expert). This setup isn't in any way 'dangerously
dedicated', though, so there's no reason to think it wouldn't work. My
question was whether mounting from ad2d (with no MBR on ad2 at all)
would work; apparently it will, as long as there isn't an invalid BSD
disklabel in sector 2 of the first track.