Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-09 Thread nickolasbug
2011/6/8 Matthias Andree matthias.and...@gmx.de:
 Am 08.06.2011 15:11, schrieb nickolas...@gmail.com:
 1. Change your root fstab record to /dev/ada0s4a (not label!), reboot
 to single mode and try to re-label partition.

 Indeed not mounting from the label was (apparently) the key to solve
 this.  Thank you.

 In fact the successful procedure was:

 - from boot menu, escape to loader prompt
 - set vfs.root.mountfrom=ufs:/dev/ada0s4a
 - boot -s
 - tunefs -L mylabel /dev/ada0s4a
 - mount -a
 - edit /etc/fstab to use /dev/ufs/mylabel as device for /
 - shutdown -r now


Right, you cannot re-label partition because you've mount filesystem
through label device. So this device is already in use and re-labeling
would destroy label device.


-
wbr,
Nickolas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-09 Thread nickolasbug
2011/6/8 Josh Carroll josh.carr...@gmail.com:
 That would mean the only time a
 person can use tunefs on a root filesystem is when they either do it
 manually during the FreeBSD installation (adding -t to the list of
 newfs flags in the filesystem creation UI), or if they boot off of some
 other medium (USB flash drive, CD, PXE, etc.).

 Or when your root fs is mounted r/o, which is not as bad as what you listed 
 above.

Or when you've booted form device (not label), e.g. /dev/ada0s1a and
have set sysctl kern.geom.debugflags=16


 Perhaps I'm doing something wrong, but in my experience, at least with
 glabel, the label will not stick even if you have the root fs mounted
 ro. I have had to boot from an alternative media (boot cd, alternate
 root fs, etc) in order to create a label for the root fs with glabel.
 To be specific, I'm talking about the automatic labels created with
 glabel label name dev.

 I just tested this again in a VM, and sure enough if I boot single
 user mode but use ad0s1a as the ro root file system during single user
 mode, it still doesn't stick and upon reboot I don't have a /dev/label
 entry. Here is the exact sequence I used:

 1. boot single user with the default root fs (ad0s1a).
 2. leave / mounted read only
 3. glabel label -v root ad0s1a   # reports successful addition of metadata
 4. /dev/label/root exists as expected
 5. reboot
 6. /dev/label/root does not exist

You should mount fs from label device  - /dev/label/root in your case,
which must be in /etc/fstab, e.g.:
/dev/label/root/ufs   rw1   1

Otherwise if you mount fs from device directly (not from label) label
entry (/dev/label/root) would be removed from /dev file system as
unused device. This action will be reported in dmesg (you may check
it)

So, afrer labeling device you should add fstab record. After that you
can reboot.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-09 Thread Matthias Andree
Am 08.06.2011 19:59, schrieb Rob Farmer:

 Also, I've seen the sysctl kern.geom.debugflags=16 thing in zfs
 tutorials and such, but haven't seen where it's actually necessary. I
 think this is outdated and changed circa 8.0.

Possibly - it's still a de-facto standard reflex action whenever a newer
FreeBSD kernel refuses to write a superblock or MBR or partition stuff. 8-)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


[SOLVED] Re: labelling root file system (RELENG_8)

2011-06-08 Thread Matthias Andree
Am 08.06.2011 15:11, schrieb nickolas...@gmail.com:
 1. Change your root fstab record to /dev/ada0s4a (not label!), reboot
 to single mode and try to re-label partition.

Indeed not mounting from the label was (apparently) the key to solve
this.  Thank you.

In fact the successful procedure was:

- from boot menu, escape to loader prompt
- set vfs.root.mountfrom=ufs:/dev/ada0s4a
- boot -s
- tunefs -L mylabel /dev/ada0s4a
- mount -a
- edit /etc/fstab to use /dev/ufs/mylabel as device for /
- shutdown -r now

Best regards,
Matthias

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-08 Thread Jeremy Chadwick
On Wed, Jun 08, 2011 at 04:02:43PM +0200, Matthias Andree wrote:
 Am 08.06.2011 15:11, schrieb nickolas...@gmail.com:
  1. Change your root fstab record to /dev/ada0s4a (not label!), reboot
  to single mode and try to re-label partition.
 
 Indeed not mounting from the label was (apparently) the key to solve
 this.  Thank you.
 
 In fact the successful procedure was:
 
 - from boot menu, escape to loader prompt
 - set vfs.root.mountfrom=ufs:/dev/ada0s4a
 - boot -s
 - tunefs -L mylabel /dev/ada0s4a
 - mount -a
 - edit /etc/fstab to use /dev/ufs/mylabel as device for /
 - shutdown -r now

I have the exact same question except not with regards to labels but
toggling TRIM capability on the root filesystem.

- Start system
- At loader, boot single-user (option 4)
- At prompt choose /bin/sh
- mount -a
- tunefs -t enable /dev/ada0s1a --- fails
- sysctl kern.geom.debugflags=16
- tunefs -t enable /dev/ada0s1a --- works
- tunefs -p /dev/ada0s1a -- shows TRIM enabled
- reboot
- Boot into single-user, multi-user, whatever
- tunefs -p /dev/ada0s1a -- shows TRIM disabled

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, US |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-08 Thread Andriy Gapon
on 08/06/2011 19:26 Jeremy Chadwick said the following:
 I have the exact same question except not with regards to labels but
 toggling TRIM capability on the root filesystem.
 
 - Start system
 - At loader, boot single-user (option 4)
 - At prompt choose /bin/sh
 - mount -a

I think that this is a culprit.

 - tunefs -t enable /dev/ada0s1a --- fails

Shouldn't you have / mounted r/o here?
BTW, AFAIR, *re*-mounting root read-only won't help; it needs to have never been
mounted r/w.

 - sysctl kern.geom.debugflags=16
 - tunefs -t enable /dev/ada0s1a --- works
 - tunefs -p /dev/ada0s1a -- shows TRIM enabled
 - reboot

I think that at this step your superblock on disk gets re-written with its copy 
in
memory which has never been updated.  But not sure.

 - Boot into single-user, multi-user, whatever
 - tunefs -p /dev/ada0s1a -- shows TRIM disabled

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-08 Thread Jeremy Chadwick
On Wed, Jun 08, 2011 at 07:40:03PM +0300, Andriy Gapon wrote:
 on 08/06/2011 19:26 Jeremy Chadwick said the following:
  I have the exact same question except not with regards to labels but
  toggling TRIM capability on the root filesystem.
  
  - Start system
  - At loader, boot single-user (option 4)
  - At prompt choose /bin/sh
  - mount -a
 
 I think that this is a culprit.

I'll try removing this step.

  - tunefs -t enable /dev/ada0s1a --- fails
 
 Shouldn't you have / mounted r/o here?
 BTW, AFAIR, *re*-mounting root read-only won't help; it needs to have never 
 been
 mounted r/w.

I'm a little confused by this sentence, so my apologise in advance.  /
is mounted read-only in single-user by default.  Did you mean I should
make it r/w by doing mount -u -o rw / ?  I may have omitted this step.

I will re-verify the exact procedure and exact steps in a moment, and
reply here.

  - sysctl kern.geom.debugflags=16
  - tunefs -t enable /dev/ada0s1a --- works
  - tunefs -p /dev/ada0s1a -- shows TRIM enabled
  - reboot
 
 I think that at this step your superblock on disk gets re-written with its 
 copy in
 memory which has never been updated.  But not sure.

Hmm, I sure hope that isn't the case.  That would mean the only time a
person can use tunefs on a root filesystem is when they either do it
manually during the FreeBSD installation (adding -t to the list of
newfs flags in the filesystem creation UI), or if they boot off of some
other medium (USB flash drive, CD, PXE, etc.).

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, US |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-08 Thread Jeremy Chadwick
On Wed, Jun 08, 2011 at 09:55:15AM -0700, Jeremy Chadwick wrote:
 On Wed, Jun 08, 2011 at 07:40:03PM +0300, Andriy Gapon wrote:
  on 08/06/2011 19:26 Jeremy Chadwick said the following:
   I have the exact same question except not with regards to labels but
   toggling TRIM capability on the root filesystem.
   
   - Start system
   - At loader, boot single-user (option 4)
   - At prompt choose /bin/sh
   - mount -a
  
  I think that this is a culprit.
 
 I'll try removing this step.
 
   - tunefs -t enable /dev/ada0s1a --- fails
  
  Shouldn't you have / mounted r/o here?
  BTW, AFAIR, *re*-mounting root read-only won't help; it needs to have never 
  been
  mounted r/w.
 
 I'm a little confused by this sentence, so my apologise in advance.  /
 is mounted read-only in single-user by default.  Did you mean I should
 make it r/w by doing mount -u -o rw / ?  I may have omitted this step.
 
 I will re-verify the exact procedure and exact steps in a moment, and
 reply here.
 
   - sysctl kern.geom.debugflags=16
   - tunefs -t enable /dev/ada0s1a --- works
   - tunefs -p /dev/ada0s1a -- shows TRIM enabled
   - reboot
  
  I think that at this step your superblock on disk gets re-written with its 
  copy in
  memory which has never been updated.  But not sure.
 
 Hmm, I sure hope that isn't the case.  That would mean the only time a
 person can use tunefs on a root filesystem is when they either do it
 manually during the FreeBSD installation (adding -t to the list of
 newfs flags in the filesystem creation UI), or if they boot off of some
 other medium (USB flash drive, CD, PXE, etc.).

Interestingly enough, the long procedure I originally described is
probably what was causing the problem.  Not sure how to phrase it.

The exact procedure which worked was:

- Start system
- Boot into single-user
- Hit enter at prompt (choose /bin/sh)
- mount --- shows root filesystem mounted read-only (normal)
- tunefs -t enable /dev/ada0s1a --- says it enabled TRIM support
- tunefs -p /dev/ada0s1a --- shows TRIM support enabled
- reboot
- After system starts, as root: tunefs -p /dev/ada0s1a --- shows TRIM
  enabled

So the extra rigmarole I was doing somehow caused the problem.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, US |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-08 Thread Rob Farmer
On Wed, Jun 8, 2011 at 10:05 AM, Jeremy Chadwick
free...@jdc.parodius.com wrote:
 Interestingly enough, the long procedure I originally described is
 probably what was causing the problem.  Not sure how to phrase it.


I don't have a reference for this, but I'm pretty sure it was on one
of the mailing lists at some point.

The kernel reads the super-block into memory and uses that copy when
the file system is mounted. If you have the it mounted rw, then at
unmount it is written back out to the disk. If it's mounted ro, the
in-memory copy is thrown out and the disk isn't changed. If you
upgrade a file system from ro to rw, it does not re-read the on disk
copy.

tunefs directly modifies on the on-disk copy regardless of mount
status, so when you unmount a rw file system, anything it has done is
overwritten. The only way to modify / (without alternate boot media)
is what you've described below: boot single user, leave it ro, tunefs,
then reboot while still ro.

Also, I've seen the sysctl kern.geom.debugflags=16 thing in zfs
tutorials and such, but haven't seen where it's actually necessary. I
think this is outdated and changed circa 8.0.

-- 
Rob Farmer

 The exact procedure which worked was:

 - Start system
 - Boot into single-user
 - Hit enter at prompt (choose /bin/sh)
 - mount --- shows root filesystem mounted read-only (normal)
 - tunefs -t enable /dev/ada0s1a --- says it enabled TRIM support
 - tunefs -p /dev/ada0s1a --- shows TRIM support enabled
 - reboot
 - After system starts, as root: tunefs -p /dev/ada0s1a --- shows TRIM
  enabled

 So the extra rigmarole I was doing somehow caused the problem.

 --
 | Jeremy Chadwick                                   j...@parodius.com |
 | Parodius Networking                       http://www.parodius.com/ |
 | UNIX Systems Administrator                   Mountain View, CA, US |
 | Making life hard for others since 1977.               PGP 4BD6C0CB |

 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-08 Thread Andriy Gapon
on 08/06/2011 19:55 Jeremy Chadwick said the following:
 On Wed, Jun 08, 2011 at 07:40:03PM +0300, Andriy Gapon wrote:
 on 08/06/2011 19:26 Jeremy Chadwick said the following:
 I have the exact same question except not with regards to labels but
 toggling TRIM capability on the root filesystem.

 - Start system
 - At loader, boot single-user (option 4)
 - At prompt choose /bin/sh
 - mount -a

 I think that this is a culprit.
 
 I'll try removing this step.
 
 - tunefs -t enable /dev/ada0s1a --- fails

 Shouldn't you have / mounted r/o here?
 BTW, AFAIR, *re*-mounting root read-only won't help; it needs to have never 
 been
 mounted r/w.
 
 I'm a little confused by this sentence, so my apologise in advance.  /
 is mounted read-only in single-user by default.  Did you mean I should
 make it r/w by doing mount -u -o rw / ?  I may have omitted this step.

No.  My English is not perfect it seems - my point was that you should never
mount your root fs r/w if you want to do tunefs on it.

 I will re-verify the exact procedure and exact steps in a moment, and
 reply here.
 
 - sysctl kern.geom.debugflags=16
 - tunefs -t enable /dev/ada0s1a --- works
 - tunefs -p /dev/ada0s1a -- shows TRIM enabled
 - reboot

 I think that at this step your superblock on disk gets re-written with its 
 copy in
 memory which has never been updated.  But not sure.
 
 Hmm, I sure hope that isn't the case.

I think that this is the case.

 That would mean the only time a
 person can use tunefs on a root filesystem is when they either do it
 manually during the FreeBSD installation (adding -t to the list of
 newfs flags in the filesystem creation UI), or if they boot off of some
 other medium (USB flash drive, CD, PXE, etc.).

Or when your root fs is mounted r/o, which is not as bad as what you listed 
above.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: [SOLVED] Re: labelling root file system (RELENG_8)

2011-06-08 Thread Josh Carroll
 That would mean the only time a
 person can use tunefs on a root filesystem is when they either do it
 manually during the FreeBSD installation (adding -t to the list of
 newfs flags in the filesystem creation UI), or if they boot off of some
 other medium (USB flash drive, CD, PXE, etc.).

 Or when your root fs is mounted r/o, which is not as bad as what you listed 
 above.

Perhaps I'm doing something wrong, but in my experience, at least with
glabel, the label will not stick even if you have the root fs mounted
ro. I have had to boot from an alternative media (boot cd, alternate
root fs, etc) in order to create a label for the root fs with glabel.
To be specific, I'm talking about the automatic labels created with
glabel label name dev.

I just tested this again in a VM, and sure enough if I boot single
user mode but use ad0s1a as the ro root file system during single user
mode, it still doesn't stick and upon reboot I don't have a /dev/label
entry. Here is the exact sequence I used:

1. boot single user with the default root fs (ad0s1a).
2. leave / mounted read only
3. glabel label -v root ad0s1a   # reports successful addition of metadata
4. /dev/label/root exists as expected
5. reboot
6. /dev/label/root does not exist

If I boot from a boot cd for example and do it from there, it works
fine. So it seems (at least for glabel) that you can't have the fs
mounted at all when adding a glabel.

If that's the expected behavior, perhaps we can add a mention of this
in the man page(s)? Otherwise, I'm curious what I'm doing wrong and
how I can get it to stick and still not need a boot CD/etc.

Thanks,
Josh
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org