On Mon, Nov 19, 2012 at 9:44 AM, Eitan Adler <li...@eitanadler.com> wrote:
> Hey all,
> The FAQ for FreeBSD needs a significant amount of updating and
> changing. The first step in that process is to figure out what needs
> to be changed.
> If you can a take a moment and thoroughly review just one
> question and add your comments and concerns it
> would be immensely helpful.
9.2. How do I move my system over to my huge new disk?
9.3. Will a "dangerously dedicated" disk endanger my health?
9.6. Why can I not edit the disk label on my ccd(4)?
Requires some rewrite with respect do bsdinstall , because sysinstall is
not used any more in new
distributions .
11.7. What is a virtual console and how do I make more?
11.8. How do I access the virtual consoles from X?
On Mon, Nov 19, 2012 at 9:44 AM, Eitan Adler <li...@eitanadler.com> wrote:
> Hey all,
> The FAQ for FreeBSD needs a significant amount of updating and
> changing. The first step in that process is to figure out what needs
> to be changed.
> If you can a take a moment and thoroughly review just one
> question and add your comments and concerns it
> would be immensely helpful.
> The FAQ for FreeBSD needs a significant amount of updating and
> changing. The first step in that process is to figure out what needs
> to be changed.
> If you can a take a moment and thoroughly review just one
> question and add your comments and concerns it
> would be immensely helpful.
> The FAQ for FreeBSD needs a significant amount of updating and
> changing. The first step in that process is to figure out what needs
> to be changed.
> If you can a take a moment and thoroughly review just one
> question and add your comments and concerns it
> would be immensely helpful.
Would it be worth mentioning no /dev/xxxs1 is created when the device is plugged in after boot?
E.G. 1:
I have a Zip Drive which is /dev/da1.
Everything is fine if a disk is in when I boot, but if I insert the media after boot, /dev/da1s1 is not there.
I need to "mount /dev/da1 /mnt": this also fails, but now I have /dev/da1s1 and can mount it.
E.G. 2:
I connect my Android phone with an USB cable: it will be /dev/da7.
Again I have no /dev/da7s1 until I "dd count=0 if=/dev/random of=/dev/da7".
>>> The FAQ for FreeBSD needs a significant amount of updating and
>>> changing. The first step in that process is to figure out what needs
>>> to be changed.
>>> If you can a take a moment and thoroughly review just one
>>> question and add your comments and concerns it
>>> would be immensely helpful.
I've migrated the comments on the mailing list to the wiki and will
working on fixing them shortly. Content patches are appreciated but
not required. Ideally every row on the wiki will be either green or
red.
> On 11/23/12 10:25, Lars Engels wrote:
>> I've seen that on almost every USB MP3 player, Android mobile phones >> and
>> on other USB devices that export an internal memory card.
> BTW, my disk drive is SCSI attached, so it's not an USB-only issue.
So, it's probably a cam layer issue.
_______________________________________________
freebsd-sta...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
"As long as you make sure you follow the steps above, you can build your
kernel normally, and you should notice a fairly large size decrease; most
kernels tend to be around 1.5 MB to 2 MB."
Not really, stripped amd64 kernel is about 9 MB currently...
"The usual answer is that DNS on your system is misconfigured. Opera perform
DNS checks when starting up. The browser will not appear on your desktop
until the program either gets a response or determines that the system has
no network connection."
On 25 November 2012 13:28, Jakub Lach <jakub_l...@mailplus.pl> wrote:
> Why is my kernel so big?
> "As long as you make sure you follow the steps above, you can build your
> kernel normally, and you should notice a fairly large size decrease; most
> kernels tend to be around 1.5 MB to 2 MB."
> Not really, stripped amd64 kernel is about 9 MB currently...
> Absolutely not, it's a heavily stripped custom kernel on this machine on
> /boot/.
Do you call this heavily stripped? :)
> ls -la /boot/kernel/kernel
-r-xr-xr-x 1 root wheel 5757970 Nov 26 10:57 /boot/kernel/kernel
However it's very hard to strip kernel further and make it usable for all machines.
> I was pointing to that, if my kernel is 9 MB, there's no way GENERIC could
> be
> 1.5-2.5 MB.
That's true...
-- Sphinx of black quartz, judge my vow.
_______________________________________________
freebsd-sta...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 26.11.2012 16:49, Jakub Lach:
>> Absolutely not, it's a heavily stripped custom kernel on this machine on
>> /boot/.
> Do you call this heavily stripped? :)
> > ls -la /boot/kernel/kernel
> -r-xr-xr-x 1 root wheel 5757970 Nov 26 10:57 /boot/kernel/kernel
> However it's very hard to strip kernel further and make it usable for all > machines.
>> I was pointing to that, if my kernel is 9 MB, there's no way GENERIC could
>> be
>> 1.5-2.5 MB.
> That's true...
i386 kernel with the only devices I need without debug symbols is 4.5MB on 7.4-STABLE
fb1:/home/Freebee % uname -a
FreeBSD fb1 7.4-STABLE FreeBSD 7.4-STABLE #7: Mon Nov 26 11:27:42 CET 2012 root@fb1:/usr/obj/usr/src/sys/FB1 i386
fb1:/home/Freebee % ls -lh /boot/kernel/kernel
-r-xr-xr-x 1 root wheel 4.6M Nov 26 11:27 /boot/kernel/kernel
amd64 same story on 9.1-RC3 is 6.3MB
[Freebee@sys:~] $ uname -a
FreeBSD sys 9.1-RC3 FreeBSD 9.1-RC3 #0: Wed Oct 31 11:56:55 CET 2012 root@sys:/usr/obj/usr/src/sys/SYS amd64
[Freebee@sys:~] $ ls -hl /boot/kernel/kernel
-r-xr-xr-x 1 root wheel 6.3M Oct 31 11:56 /boot/kernel/kernel
On 26 November 2012 11:25, Jakub Lach <jakub_l...@mailplus.pl> wrote:
> Thanks!
> Regarding FAQ, some info about journalling should be added to
> "Chapter 9 Disks, File Systems, and Boot Loaders", especially now,
> when SU+J is default.
which question does this apply to, or is this a request for new questions?
> Regarding FAQ, some info about journalling should be added to
> "Chapter 9 Disks, File Systems, and Boot Loaders", especially now,
> when SU+J is default.
Add to FAQ 9.4 Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems.
This can also be enabled/disabled with tunefs -j enable | disable
For more information see man 8 tunefs
----------------
New FAQ 9.28 I have heard about TRIM for Solid State Drives (SSD), is it supported by FreeBSD?
The TRIM filesystem flag is very useful for devices that use flash-memory (SSD for instance) and support the BIO_DELETE command.
This flag is not enabled by default and can be enabled/disabled with tunefs -t enable | disable
For more information see man 8 tunefs
-t enable | disable
Turn on/off the TRIM enable flag. If enabled, and if the under-
lying device supports the BIO_DELETE command, the file system
will send a delete request to the underlying device for each
freed block. The trim enable flag is typically set when the
underlying device uses flash-memory as the device can use the
delete command to pre-zero or at least avoid copying blocks that
have been deleted.
Important when using tunefs:
This utility does not work on active file systems. To change the root
file system, the system must be rebooted after the file system is tuned.
FIlesystems have to be mounted read-only or not mounted at all
> As a reminder, this isn't a contest in kernel size :)
Didn't mean to, I just put it there to state that 1.5 - 2.5 MB for a GENERIC kernel is not appropriate anymore.
> More useful would be if somebody would check GENERIC
> on i386/amd64 for FAQ update.
Thanks Miroslav Lachman for the reply with the correct sizes for GENERIC kernels.
Change FAQ 8.3 Why is my kernel so big?
Nowadays kernels are compiled in /debug mode by default/. Kernels built in debug mode contain many symbols that are used for debugging, thus greatly increasing the size of the kernel. Note that there will be little or no performance decrease from running a debug kernel, and it is useful in case of a system panic.
>> Regarding FAQ, some info about journalling should be added to
>> "Chapter 9 Disks, File Systems, and Boot Loaders", especially now,
>> when SU+J is default.
Please also add:
SU+J does not work (yet) with dump on a live filesystem i.e. use snapshot.
If you want to use snapshot (dump -L) then disable the soft updates journal for that filesystem
> This can also be enabled/disabled with tunefs -j enable | disable
> For more information see man 8 tunefs
> ----------------
> New FAQ 9.28 I have heard about TRIM for Solid State Drives (SSD), is > it supported by FreeBSD?
> The TRIM filesystem flag is very useful for devices that use > flash-memory (SSD for instance) and support the BIO_DELETE command.
> This flag is not enabled by default and can be enabled/disabled with > tunefs -t enable | disable
> For more information see man 8 tunefs
> -t enable | disable
> Turn on/off the TRIM enable flag. If enabled, and if the > under-
> lying device supports the BIO_DELETE command, the file > system
> will send a delete request to the underlying device for each
> freed block. The trim enable flag is typically set when the
> underlying device uses flash-memory as the device can use > the
> delete command to pre-zero or at least avoid copying > blocks that
> have been deleted.
> Important when using tunefs:
> This utility does not work on active file systems. To change the > root
> file system, the system must be rebooted after the file system is > tuned.
> FIlesystems have to be mounted read-only or not mounted at all
This may be request for new questions, or this can be supplemented partially in hardware ones I think;
- new default partition layout and it's justification (single partition nowadays, I believe?)
- default block size and it's justification (is it 4K? why?)
- NCQ support with ada/ahci - ahci power managment [*]
- why or why not default settings are just fine with SSD (regarding journaling, SU, trim and what not).
Sorry for requesting content rather than reviewing existing one, but I think this info important for modern FAQ.
* power-management-support description is lacking, apm is obsolete, no mention of ahci.
I think this is more of less complete sketch of power saving facilities in FreeBSD-
> On 11/26/12 21:27, Bas Smeelen wrote:
>> On 11/26/12 17:25, Jakub Lach wrote:
>>> Thanks!
>>> Regarding FAQ, some info about journalling should be added to
>>> "Chapter 9 Disks, File Systems, and Boot Loaders", especially now,
>>> when SU+J is default.
> Please also add:
> SU+J does not work (yet) with dump on a live filesystem i.e. use snapshot.
> If you want to use snapshot (dump -L) then disable the soft updates journal for that filesystem
It would be helpful to include information on how to do that during install (still trying to figure that out myself), and using the recover CD for when you forget to do it during install.
_______________________________________________
freebsd-sta...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
