Re: FreeBSD slices and the Boot Manager
Why wouldn't you simply update your 8.1 to 8.4? 2013/7/27 Conny Andersson atar...@telia.com Hi, I have a workstation with two factory installed hard disks. The first disk, ada0, is occupied by a Windows 7 Pro OS (mainly kept for the three year warranty of the workstation as Dell techs mostly speak the Microsoft language). Instead I have configured the BIOS to boot from the MBR on the second disk as I most of the time (99%) use FreeBSD. The MBR on ada1 was installed with sysinstall's option Install the FreeBSD Boot Manager, when I installed the FreeBSD 8.3-RELEASE. (The latest BIOS version 2.4.0 for Dell T1500 does not support UEFI/GPT/GUID.) The second disk ada1, now has three FreeBSD slices: 1) ada1s1 with FreeBSD 8.1-RELEASE 2) ada1s2 with FreeBSD 8.2-RELEASE 3) ada1s3 with FreeBSD 8.3-RELEASE I want to install the new FreeBSD 8.4-RELEASE on ada1s1 by overwriting the now existing two first slices. This means that ada1s3, must become ada1s2 instead. Is this possible to do? A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) If the answer to these questions is yes, then the next two questions arise. Can I mount ada1s2a (FreeBSD 8.3) from the newly installed FreeBSD 8.4 and edit my FreeBSD's 8.3-R /etc/fstab according to the new disk layout, and occasionally run FreeBSD 8.3 without problems? Or do I have to do more to get it to work? The idea behind this kind of 'reverse' disk layout of mine is to have FreeBSD 8.4 as my new default OS. And have FreeBSD 8.3 untouched for configuring FreeBSD 8.4 and booting into it when ever needed. If I can do this as described above, I will have plenty of space on the disk for the future and a new FreeBSD release. Thanks for your interest in my questions, Conny Andersson =-=-=-=-=-=-=-=-=-= Conny Andersson atar...@telia.com =-=-=-=-=-=-=-=-=-= __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org -- Is there any problem Exterminatus cannot solve? I have not found one yet. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
On Sat, 27 Jul 2013 19:39:30 +0200 (CEST), Conny Andersson wrote: Hi, I have a workstation with two factory installed hard disks. The first disk, ada0, is occupied by a Windows 7 Pro OS (mainly kept for the three year warranty of the workstation as Dell techs mostly speak the Microsoft language). It's just a series of pictures, not a language. ;-) Instead I have configured the BIOS to boot from the MBR on the second disk as I most of the time (99%) use FreeBSD. The MBR on ada1 was installed with sysinstall's option Install the FreeBSD Boot Manager, when I installed the FreeBSD 8.3-RELEASE. (The latest BIOS version 2.4.0 for Dell T1500 does not support UEFI/GPT/GUID.) The second disk ada1, now has three FreeBSD slices: 1) ada1s1 with FreeBSD 8.1-RELEASE 2) ada1s2 with FreeBSD 8.2-RELEASE 3) ada1s3 with FreeBSD 8.3-RELEASE I want to install the new FreeBSD 8.4-RELEASE on ada1s1 by overwriting the now existing two first slices. This means that ada1s3, must become ada1s2 instead. Is this possible to do? Why do you want to do this? If you keep the s1 slice, you can easily install FreeBSD 8.4 into that slice, leading to this result: 1) ada1s1 with FreeBSD 8.4-RELEASE 2) ada1s2 with FreeBSD 8.2-RELEASE 3) ada1s3 with FreeBSD 8.3-RELEASE Or is the numbering order important to you? You could even keep the partitioning inside s1, but there is no problem re-partitioning inside s1. A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? I'm not sure I'm following you correctly. The sysinstall program is considered obsolete, the new system installer is bsdinstall. So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) That is a _good_ consideration! To make sure things work independently from boot-time recognition, use labels for the file system and then mount them by using the labels. Encode the OS version number in the labels, so it's even easier to deal with them. Use newfs -L on un-mounted partitions (you can do that from the install media). From the install media, you can easily go to the CLI and use the bsdlabel program to re-write the boot blocks and boot manager if needed. Can I mount ada1s2a (FreeBSD 8.3) from the newly installed FreeBSD 8.4 and edit my FreeBSD's 8.3-R /etc/fstab according to the new disk layout, and occasionally run FreeBSD 8.3 without problems? Or do I have to do more to get it to work? Yes, that should be possible. I don't see any problem because this is a UFS partition. As I mentioned earlier, if you apply labels to the partitions on the slices, it's even easier to determine _which_ 'a' partition (root partition) you are currently dealing with. And if you continue your installation scheme in further versions, you will be freed from remembering what OS version resides on what slice. You then simply do mount /dev/ufs/root83 /mnt; vi /mnt/etc/fstab and you _immediately_ know which installation you're currently dealing with. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Delete a directory, crash the system
On 28/07/2013 06:54, Polytropon wrote:
And here, kids, you can see the strength of open source
operating system: You can see _why_ something happens. :-)
Too true!
On Sat, 27 Jul 2013 20:35:09 +0100, Frank Leonhardt wrote:
On 27/07/2013 19:57, David Noel wrote:
So the system panics in ufs_rmdir(). Maybe the filesystem is
corrupt? Have you tried to fsck(8) it manually?
fsck worked, though I had to boot from a USB image because I couldn't
get into single user.. for some odd reason.
Even if the filesystem is corrupt, ufs_rmdir() shouldn't
panic(), IMHO, but fail gracefully. Hmmm...
Yeah, I was pretty surprised. I think I tried it like 3 times to be
sure... and yeah, each time... kaboom! Who'd have thought. Do I just
post this to the mailing list and hope some benevolent developer
stumbles upon it and takes it upon him/herself to fix this, or where
do I find the FreeBSD Suggestion Box? I guess I should file a Problem
Report and see what happens from there.
I was going to raise an issue when the discussion had died down to a
concensus. I also don't think it's reasonable for the kernel to bomb
when it encounters corruption on a disk.
If you want to patch it yourself, edit sys/ufs/ufs/ufs_vnops.c at around
line 2791 change:
if (dp-i_effnlink 3)
panic(ufs_dirrem: Bad link count %d on parent,
dp-i_effnlink);
To
if (dp-i_effnlink 3) {
error = EINVAL;
goto out;
}
The ufs_link() call has a similar issue.
I can't see why my mod will break anything, but there's always
unintended consequences.
One of the core policies usually is to stop _any_ action that
had failed due to a reason that cannot be and make sure it
won't get worse. This can be seen for example in fsck's behaviour:
If there is a massive file system error that cannot be repaired
without further intervention that _could_ destroy data or make
its retrieval harder or impossible, the operator will be requested
to make the decision. There are options to automate this process,
but on the other hand, always assume 'yes' can then be a risk,
as it could prevent recovery. My assumtion is that the developers
chose a similar approach here: We found a situation that should
not be possible, so we stop the system for messing up the file
system even more. This carries the attitude of not hiding a
problem for the sake of convenience by being silent and going
back to the usual work. Of course it is debatable if this is the
right decision in _this_ particular case.
The problem I have with this is the assumption that the inode was at
fault. I said this was the most likely, but it's not the absolute
reason. At the risk of repeating, it's the /effective/ link count (in
the vnode) that's out of line here, not the inode count.
If the inode was wrong it could be down to minor FS corruption; an
interrupted directory creation or deletion would do the trick. The vnode
could go wrong for all sorts of reasons, probably associated with a race
during the directory removal, which is not an atomic operation by any
means. See The Design of the UNIX operating system p 5.16.1, Bach,
Prentice-Hall, 1986.
My guess is that we're looking at an old debugging pragma here, put in
to cope with a race going wrong if the code wasn't quite right (note
that the function has since been renamed but the message not updated).
You're right about stopping on internal errors (corruption to the kernel
data structures in this case) but this case is indeed debatable. On the
one hand, now the system is stable (i.e. we can probably trust rmdir
code after all this time), the most likely cause is inode corruption
polluting the vnode. On the other hand the pragma may be useful if
people are tinkering with the kernel and you get even more opportunities
for a race with (say) SMP.
I don't expect the kernel to panic on a user-land I/O error, or anything
else that's expected or recoverable - and a wonky FS meets these
criteria in my book. David was lucky to find this - I tend to run
FreeBSD on servers, not laptops, and I'd never have seen this server
panic live and therefore not been able to discover the cause very
easily. That's worrying.
So it boils down to:
a) Leave is is, as it can detect when the kernel has trashed its vnode
table; or
b) It's probably caused by expected FS corruption, so handle it
gracefully.
Incidentally, if you look at the code you'll see this is only heuristic
check, and a weak one at that. Most of the time it WILL NOT pick up the
case where the parent directory's link is missing. As far as I can tell
it will go on to unlink the target successfully, with no ill effects. If
this situation really did lead to catastrophe (as suggested by the use
of a panic) then the check used ought to be a lot more reliable! As it
is, removing it entirely except for debug kernels, is a third option.
Regards, Frank.
Re: Delete a directory, crash the system
Ok folks, thanks again for all the help. Using the feedback I submitted a PR (#180894) -- http://www.freebsd.org/cgi/query-pr.cgi?pr=180894. I also submitted a follow-up to it with Frank's code and notes. What next? I don't really know what happens from here, but I'm guessing/hoping that someone's monitoring the PR system and will move this forward. Crossing my fingers, though if anyone knows any better methods of getting PR's addressed I'm all ears. -David ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Delete a directory, crash the system
On 28/07/2013 06:38, David Noel wrote: Ok folks, thanks again for all the help. Using the feedback I submitted a PR (#180894) -- http://www.freebsd.org/cgi/query-pr.cgi?pr=180894. I also submitted a follow-up to it with Frank's code and notes. What next? I don't really know what happens from here, but I'm guessing/hoping that someone's monitoring the PR system and will move this forward. Crossing my fingers, though if anyone knows any better methods of getting PR's addressed I'm all ears. You've already done the right things: raising a PR and posing about your problem on freebsd...@freebsd.org, where it is going to come to the attention of developers working on that area of the system. You're next move should be to provide whatever additional information the developers might need to diagnose or reproduce the problem. This is really the crucial bit: unless a dev can understand what happened and how your system came to break in that particular way, it's unlikely they'll be able to fix it. If you don't understand what's being asked for, or how to roduce any required information, don't be shy about asking -- either here, or over on freebsd-fs@... It's sometimes hard to remember that the sort of debugging things you'ld do routinely and without a second thought as a developer can appear as pretty arcane mysteries to the uninitiated. You may find these bits of documentation useful: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/debugging.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html (especially section 10.1 about obtaining a kernel core dump, and 10.2 about using kgdb.) Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk signature.asc Description: OpenPGP digital signature
Re: Delete a directory, crash the system
On Sun, 28 Jul 2013, Frank Leonhardt wrote: So it boils down to: a) Leave is is, as it can detect when the kernel has trashed its vnode table; or b) It's probably caused by expected FS corruption, so handle it gracefully. It would be good to log a system error message like filesystem may be corrupt to give the user some clue other than a seemingly impossible error with no explanation. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
On Sun, 28 Jul 2013, Polytropon wrote: On Sat, 27 Jul 2013 19:39:30 +0200 (CEST), Conny Andersson wrote: A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? I'm not sure I'm following you correctly. The sysinstall program is considered obsolete, the new system installer is bsdinstall. AFAIK, sysinstall is still used in FreeBSD 8.X, and bsdinstall does not have a boot manager option anyway. So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) Sorry, I don't understand this at all. AHCI should not be involved with identifying slices. That is a _good_ consideration! To make sure things work independently from boot-time recognition, use labels for the file system and then mount them by using the labels. Encode the OS version number in the labels, so it's even easier to deal with them. Use newfs -L on un-mounted partitions (you can do that from the install media). For existing filesystems, that would be tunefs -L. And agreed, filesystem labels make relocation much easier. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
On Sun, 28 Jul 2013 08:18:39 -0600 (MDT), Warren Block wrote: On Sun, 28 Jul 2013, Polytropon wrote: On Sat, 27 Jul 2013 19:39:30 +0200 (CEST), Conny Andersson wrote: A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? I'm not sure I'm following you correctly. The sysinstall program is considered obsolete, the new system installer is bsdinstall. AFAIK, sysinstall is still used in FreeBSD 8.X, and bsdinstall does not have a boot manager option anyway. Sometimes I'm confusing them, because I usually don't use the installer and usually use fdisk (if needed), bsdlabel and newfs. :-) So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) Sorry, I don't understand this at all. AHCI should not be involved with identifying slices. Maybe the required device driver is not part of the 8.x GENERIC kernel? So for example a drive could come up either as /dev/ada0 or as /dev/ad6, depending on how the recognition order and PATA / SATA thing is handled by the system and its BIOS. Labels will work independently from wheather the device will be recognized as ATA disk (for example /dev/ad6s1a being the root disk) or SATA disk (where /dev/ada6s1 would be the root disk). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Delete a directory, crash the system
On 07/27/13 21:12, cpghost wrote: A more robust file system would halt all processes, and perform an in-kernel fsck on the filesystem and its internal (in-memory) structures to repair the damage... and THEN resume the processes. However, this is a major project, and we don't have a self-healing filesystem / kernel (... yet). ;-) -cpghost. If we think this further, we may as well start introducing some elements of self-healing or at least self-inspecting in the kernel. How about, for example, a kernel thread that wakes up periodically, walks through VFS structures, and checks their integrity? Perhaps also verifying the underlying inodes as well? Think background fsck, but within the kernel and for kernel structures themselves. Others parts of the kernel could as well self-inspect for consistency with a periodic kernel thread. Some parts are easier than others, so I don't think we could also walk the VM structures (if those are corrupt, even the repair-thread will be running amok). But save for that, most parts of the kernel could use some periodic consistency checking. Make that checking optional via a sysctl(8), and it won't even cost performance. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
On Sun, 28 Jul 2013, Polytropon wrote: On Sun, 28 Jul 2013 08:18:39 -0600 (MDT), Warren Block wrote: On Sun, 28 Jul 2013, Polytropon wrote: On Sat, 27 Jul 2013 19:39:30 +0200 (CEST), Conny Andersson wrote: A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? I'm not sure I'm following you correctly. The sysinstall program is considered obsolete, the new system installer is bsdinstall. AFAIK, sysinstall is still used in FreeBSD 8.X, and bsdinstall does not have a boot manager option anyway. Sometimes I'm confusing them, because I usually don't use the installer and usually use fdisk (if needed), bsdlabel and newfs. :-) gpart does a lot more than both fdisk and bsdlabel, and is easier to use. :) So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) Sorry, I don't understand this at all. AHCI should not be involved with identifying slices. Maybe the required device driver is not part of the 8.x GENERIC kernel? So for example a drive could come up either as /dev/ada0 or as /dev/ad6, depending on how the recognition order and PATA / SATA thing is handled by the system and its BIOS. Really, it should always be ada, unless someone has built a custom kernel that intentionally uses the old form. That's usually a mistake. (AHCI is a separate, unrelated thing.) Labels will work independently from wheather the device will be recognized as ATA disk (for example /dev/ad6s1a being the root disk) or SATA disk (where /dev/ada6s1 would be the root disk). Yes. Labels don't care about the hardware connection. So they'll continue to work when you take a drive out of a machine and put it in a USB enclosure, for example. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
In freebsd-questions Digest, Vol 477, Issue 8, Message: 10 On Sat, 27 Jul 2013 19:39:30 +0200 (CEST) Conny Andersson atar...@telia.com wrote: Hi, I have a workstation with two factory installed hard disks. The first disk, ada0, is occupied by a Windows 7 Pro OS (mainly kept for the three year warranty of the workstation as Dell techs mostly speak the Microsoft language). Yes, best humour adherents of the Almighty Bill - keeps them sweet. Instead I have configured the BIOS to boot from the MBR on the second disk as I most of the time (99%) use FreeBSD. The MBR on ada1 was installed with sysinstall's option Install the FreeBSD Boot Manager, when I installed the FreeBSD 8.3-RELEASE. Right. sysinstall(8) - or at least the fdisk and bsdlabel modules that constitute sade(8) - remains the only safe and sane way to handle MBR disks. bsdinstall seems fine for GPT, but its paradigm doesn't play so well with trying to do the sorts of manipulations you're talking about here. Why noone's tried to update sade(8) for GPT I don't understand; it's a far better, more forgiving interface, in my old-fashioned? view. (The latest BIOS version 2.4.0 for Dell T1500 does not support UEFI/GPT/GUID.) The second disk ada1, now has three FreeBSD slices: 1) ada1s1 with FreeBSD 8.1-RELEASE 2) ada1s2 with FreeBSD 8.2-RELEASE 3) ada1s3 with FreeBSD 8.3-RELEASE I want to install the new FreeBSD 8.4-RELEASE on ada1s1 by overwriting the now existing two first slices. This means that ada1s3, must become ada1s2 instead. Is this possible to do? Yes and no. Using sysinstall|sade on my 9.1 laptop -- without setting sysctl kern.geom.debugflags=16 so it can't write any inadvertent changes to my disk :) -- in the fdisk screen you can delete the first two slices freeing their space for a new slice (or two) and you can then allocate s1 ok, but the existing s3 is still called s3. Would that be a problem? If you only created one slice there you'd have s1 and s3, with s2 and s4 marked as empty in the MBR shown by fdisk(8). MBR slice order need not follow disk allocations, eg s4 might point to an earlier disk region. sysinstall|sade has undo options for both fdisk and bsdlabel modules; it's easy to play with, no chance of damage - even with foot-shooting flag set, unless/until you commit to changes. If in doubt hit escape until it backs right out, nothing will be written. A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) If you're running 8.4 sysinstall as init, ie booted into the installer, and you've told it to install to s1, then it should set s1 as the active partition in the disk table and in boot0cfg's active slice table. I've never tried it with a second disk so I can't confirm that will all play nice, but you seem to have installed 3 versions ok before :) If not, you can run boot0cfg(8) anytime to set the active slice etc, so that shouldn't be a worry. Likely need to set debugflags=16 to do that on a running system also .. don't forget to set them back to 0 later! (For anyone) still nervous about sade for setting up MBR disks, play with a spare memstick, setup a couple of slices, boot0cfg etc, allocate and delete slices and partitions. Jordan got that together 15years ago so noone would ever need to do those icky slice/partition maths again. My theory: few have been brave enough to dare mess with $deity's work, though it just needs some updates for modern realities, not abandonment. [ Polytropon, it's not 'obsolete' at all; still in 9 anyway. It'll be obsolete when there are no more MBR-only systems in use - say 7 years - OR when bsdinstall incorporates all the missing good sade(8) features, which requires it making a clear distinction between GPT and MBR and working accordingly, including cleaning up GPT stuff if MBR chosen. At 9.1-R anyway, it doesn't do it so well for MBR. Try installing over an existing desired slice partitioning, newfs'ing everything EXCEPT your valuable /home partition. Not for beginners, yet simple in sade(8) ] If the answer to these questions is yes, then the next two questions arise. Can I mount ada1s2a (FreeBSD 8.3) from the newly installed FreeBSD 8.4 and edit my FreeBSD's 8.3-R /etc/fstab according to the new disk layout, and occasionally run FreeBSD 8.3 without problems? Or do I have to do more to get it to work? Except it likely will still be called ada1s3a, it should be no problem. Once boot0cfg(8) is working right, you can boot from any bootable slice; it 'knows' but doesn't care what (if any) OS is on any other slices. The idea behind this kind of 'reverse' disk layout of mine is to have
Re: FreeBSD slices and the Boot Manager
Hi Ian, Thank you for all of your advices regarding my questions. I have been using FreeBSD for more than ten years, but I never heard of sade (sysadmins disk editor). That is one of the joyful things with running FreeBSD/Unix; there is always something earlier unheard of to explore. And, there is always more than one way to approach a problem. Thank you Ian, Conny On Mon, 29 Jul 2013, Ian Smith wrote: In freebsd-questions Digest, Vol 477, Issue 8, Message: 10 On Sat, 27 Jul 2013 19:39:30 +0200 (CEST) Conny Andersson atar...@telia.com wrote: Hi, I have a workstation with two factory installed hard disks. The first disk, ada0, is occupied by a Windows 7 Pro OS (mainly kept for the three year warranty of the workstation as Dell techs mostly speak the Microsoft language). Yes, best humour adherents of the Almighty Bill - keeps them sweet. Instead I have configured the BIOS to boot from the MBR on the second disk as I most of the time (99%) use FreeBSD. The MBR on ada1 was installed with sysinstall's option Install the FreeBSD Boot Manager, when I installed the FreeBSD 8.3-RELEASE. Right. sysinstall(8) - or at least the fdisk and bsdlabel modules that constitute sade(8) - remains the only safe and sane way to handle MBR disks. bsdinstall seems fine for GPT, but its paradigm doesn't play so well with trying to do the sorts of manipulations you're talking about here. Why noone's tried to update sade(8) for GPT I don't understand; it's a far better, more forgiving interface, in my old-fashioned? view. (The latest BIOS version 2.4.0 for Dell T1500 does not support UEFI/GPT/GUID.) The second disk ada1, now has three FreeBSD slices: 1) ada1s1 with FreeBSD 8.1-RELEASE 2) ada1s2 with FreeBSD 8.2-RELEASE 3) ada1s3 with FreeBSD 8.3-RELEASE I want to install the new FreeBSD 8.4-RELEASE on ada1s1 by overwriting the now existing two first slices. This means that ada1s3, must become ada1s2 instead. Is this possible to do? Yes and no. Using sysinstall|sade on my 9.1 laptop -- without setting sysctl kern.geom.debugflags=16 so it can't write any inadvertent changes to my disk :) -- in the fdisk screen you can delete the first two slices freeing their space for a new slice (or two) and you can then allocate s1 ok, but the existing s3 is still called s3. Would that be a problem? If you only created one slice there you'd have s1 and s3, with s2 and s4 marked as empty in the MBR shown by fdisk(8). MBR slice order need not follow disk allocations, eg s4 might point to an earlier disk region. sysinstall|sade has undo options for both fdisk and bsdlabel modules; it's easy to play with, no chance of damage - even with foot-shooting flag set, unless/until you commit to changes. If in doubt hit escape until it backs right out, nothing will be written. A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) If you're running 8.4 sysinstall as init, ie booted into the installer, and you've told it to install to s1, then it should set s1 as the active partition in the disk table and in boot0cfg's active slice table. I've never tried it with a second disk so I can't confirm that will all play nice, but you seem to have installed 3 versions ok before :) If not, you can run boot0cfg(8) anytime to set the active slice etc, so that shouldn't be a worry. Likely need to set debugflags=16 to do that on a running system also .. don't forget to set them back to 0 later! (For anyone) still nervous about sade for setting up MBR disks, play with a spare memstick, setup a couple of slices, boot0cfg etc, allocate and delete slices and partitions. Jordan got that together 15years ago so noone would ever need to do those icky slice/partition maths again. My theory: few have been brave enough to dare mess with $deity's work, though it just needs some updates for modern realities, not abandonment. [ Polytropon, it's not 'obsolete' at all; still in 9 anyway. It'll be obsolete when there are no more MBR-only systems in use - say 7 years - OR when bsdinstall incorporates all the missing good sade(8) features, which requires it making a clear distinction between GPT and MBR and working accordingly, including cleaning up GPT stuff if MBR chosen. At 9.1-R anyway, it doesn't do it so well for MBR. Try installing over an existing desired slice partitioning, newfs'ing everything EXCEPT your valuable /home partition. Not for beginners, yet simple in sade(8) ] If the answer to these questions is yes, then the next two questions arise. Can I mount ada1s2a (FreeBSD 8.3) from the newly installed FreeBSD 8.4 and edit my FreeBSD's 8.3-R /etc/fstab according to the new disk layout, and occasionally run FreeBSD 8.3 without problems? Or do I have
Re: FreeBSD slices and the Boot Manager
Hi Peter, I need much more disk space for the FreeBSD 8.4-RELEASE, so I will need the space of the two 'old' slices. Thanks, Conny On Sun, 28 Jul 2013, Peter Andreev wrote: Why wouldn't you simply update your 8.1 to 8.4? 2013/7/27 Conny Andersson atar...@telia.com Hi, I have a workstation with two factory installed hard disks. The first disk, ada0, is occupied by a Windows 7 Pro OS (mainly kept for the three year warranty of the workstation as Dell techs mostly speak the Microsoft language). Instead I have configured the BIOS to boot from the MBR on the second disk as I most of the time (99%) use FreeBSD. The MBR on ada1 was installed with sysinstall's option Install the FreeBSD Boot Manager, when I installed the FreeBSD 8.3-RELEASE. (The latest BIOS version 2.4.0 for Dell T1500 does not support UEFI/GPT/GUID.) The second disk ada1, now has three FreeBSD slices: 1) ada1s1 with FreeBSD 8.1-RELEASE 2) ada1s2 with FreeBSD 8.2-RELEASE 3) ada1s3 with FreeBSD 8.3-RELEASE I want to install the new FreeBSD 8.4-RELEASE on ada1s1 by overwriting the now existing two first slices. This means that ada1s3, must become ada1s2 instead. Is this possible to do? A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) If the answer to these questions is yes, then the next two questions arise. Can I mount ada1s2a (FreeBSD 8.3) from the newly installed FreeBSD 8.4 and edit my FreeBSD's 8.3-R /etc/fstab according to the new disk layout, and occasionally run FreeBSD 8.3 without problems? Or do I have to do more to get it to work? The idea behind this kind of 'reverse' disk layout of mine is to have FreeBSD 8.4 as my new default OS. And have FreeBSD 8.3 untouched for configuring FreeBSD 8.4 and booting into it when ever needed. If I can do this as described above, I will have plenty of space on the disk for the future and a new FreeBSD release. Thanks for your interest in my questions, Conny Andersson =-=-=-=-=-=-=-=-=-= Conny Andersson atar...@telia.com =-=-=-=-=-=-=-=-=-= ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
Hi Warren and Polytropon, A few minutes ago I booted up from a FreeBSD-8.4-RELEASE-amd64-memstick.img to experience that it is sysinstall that is used in that release. Next, I did a 'dummy' custom installation. And, as I supposed sysinstall recognized disk ada0 as ad4 and disk ada1 as ad6. Then I aborted sysinstall and rebooted in to my FreeBSD 8.3-Release. Well, AHCI (Serial ATA Advanced Host Controller Interface driver) seems involved when identifying disks and slices. But, only on newer computers who has this option set to on in the BIOS. Maybe, bsdinstall in FreeBSD 9.0 and onwards can make use of AHCI directly. When I bought this workstation and installed FreeBSD I thought something was very much wrong with the wiring of the hardware/disks and I phoned Dell's support ... without being much wiser. My old Dell workstation on which I have used all the FreeBSD's from release 4.8 up to 8.0 I always got ad0 and ad1 as the disks in use. So, I had to search the Internet for an answer why my new computer numbered disks oddly. And I found your web page Warren (http://www.wonkity.com/~wblock/docs/html/ahci.html) and I also read the ahci man page. I also had to edit my /etc/fstab accordingly. My FreeBSD 8.3 /etc/fstab: # DeviceMountpoint FStype Options Dump Pass# /dev/ada1s3bnoneswapsw 0 0 /dev/ada1s3a/ ufs rw 1 1 /dev/ada1s3d/home ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto0 0 proc/proc procfs rw 0 0 linproc /compat/linux/proc linprocfs rw 0 0 Apropos labels, I only have two filesystems (+swap) on each slice, as I only run a desktop workstation. I do that following Greg Lehey's advise in his book The Complete FreeBSD 4th Edition. More apropos labels: The latest BIOS version 2.4.0 for Dell T1500 does not support UEFI/GPT/GUID. As far as I know, Dell only have the Unified Extensible Firmware Interface on its PowerEdge servers. (The reason why I want to merge two slices into one big ada1s1 is the need for more disk space for FreeBSD 8.4 and keep 8.3 as it is, but then as slice 2). Thank you, Conny On Sun, 28 Jul 2013, Warren Block wrote: On Sun, 28 Jul 2013, Polytropon wrote: On Sat, 27 Jul 2013 19:39:30 +0200 (CEST), Conny Andersson wrote: A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? I'm not sure I'm following you correctly. The sysinstall program is considered obsolete, the new system installer is bsdinstall. AFAIK, sysinstall is still used in FreeBSD 8.X, and bsdinstall does not have a boot manager option anyway. So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) Sorry, I don't understand this at all. AHCI should not be involved with identifying slices. That is a _good_ consideration! To make sure things work independently from boot-time recognition, use labels for the file system and then mount them by using the labels. Encode the OS version number in the labels, so it's even easier to deal with them. Use newfs -L on un-mounted partitions (you can do that from the install media). For existing filesystems, that would be tunefs -L. And agreed, filesystem labels make relocation much easier. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Help! Cannot boot after freebsd-update update to 9.1-p5
Help! I just used freebsd-update to upgrade a system to FreeBSD 9.1-RELEASE-p5 to close the latest security holes. I then rebuilt my custom kernel and tried to reboot. I'm now getting the message Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: at boot time. The strange thing is that when I boot the system from a FreeBSD 9.1 (AMD64) USB key, I can mount and read the file system on the hard drive that will not boot. There doesn't seem to be any problem with it. I've tried copying /boot/loader over from the USB key; still can't boot. Tried moving the GENERIC kernel over from the USB key into /boot/kernel, just in case there was a problem with my custom one; still can't boot. Not sure what to try next. Any ideas would be much appreciated! --Brett Glass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
On Sun, 28 Jul 2013, Conny Andersson wrote: Hi Warren and Polytropon, A few minutes ago I booted up from a FreeBSD-8.4-RELEASE-amd64-memstick.img to experience that it is sysinstall that is used in that release. Next, I did a 'dummy' custom installation. And, as I supposed sysinstall recognized disk ada0 as ad4 and disk ada1 as ad6. Then I aborted sysinstall and rebooted in to my FreeBSD 8.3-Release. Well, AHCI (Serial ATA Advanced Host Controller Interface driver) seems involved when identifying disks and slices. But, only on newer computers who has this option set to on in the BIOS. Maybe, bsdinstall in FreeBSD 9.0 and onwards can make use of AHCI directly. At some point, the old ad(4) driver was replaced with the new ada(4) driver. To provide backwards compatability, the old ad devices names are still available in /dev. I don't know when FreeBSD 8.X switched to the ada(4) driver. Neither ad nor ada devices require AHCI. If it is available, it gives a small but noticeable speed increase. Otherwise, it should make no difference. More apropos labels: The latest BIOS version 2.4.0 for Dell T1500 does not support UEFI/GPT/GUID. As far as I know, Dell only have the Unified Extensible Firmware Interface on its PowerEdge servers. There is more than one kind of label. There are filesystem labels like we are talking about, there are GPT labels, there are generic labels. The ones being suggested are filesystem labels: http://www.wonkity.com/~wblock/docs/html/labels.html FreeBSD supports GPT without UEFI. It doesn't matter in this case, since you already have MBR. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
On Jul 28, 2013, at 12:55 PM, Conny Andersson wrote: Hi Ian, Thank you for all of your advices regarding my questions. I have been using FreeBSD for more than ten years, but I never heard of sade (sysadmins disk editor). That is one of the joyful things with running FreeBSD/Unix; there is always something earlier unheard of to explore. And, there is always more than one way to approach a problem. In this case, sade is (or was) a direct by-product of the death of sysinstall(8). It only exists in 9 or higher. In-fact... sade was (up until recently in HEAD) actual code removed from sysinstall(8). NOTE: In HEAD, sade(8) is now a direct path to bsdinstall partedit I don't know what the long-term goals are for sade, but it's a nice 4-letter acronym that's a nice keystroke saver (at the very least). -- Devin On Mon, 29 Jul 2013, Ian Smith wrote: In freebsd-questions Digest, Vol 477, Issue 8, Message: 10 On Sat, 27 Jul 2013 19:39:30 +0200 (CEST) Conny Andersson atar...@telia.com wrote: Hi, I have a workstation with two factory installed hard disks. The first disk, ada0, is occupied by a Windows 7 Pro OS (mainly kept for the three year warranty of the workstation as Dell techs mostly speak the Microsoft language). Yes, best humour adherents of the Almighty Bill - keeps them sweet. Instead I have configured the BIOS to boot from the MBR on the second disk as I most of the time (99%) use FreeBSD. The MBR on ada1 was installed with sysinstall's option Install the FreeBSD Boot Manager, when I installed the FreeBSD 8.3-RELEASE. Right. sysinstall(8) - or at least the fdisk and bsdlabel modules that constitute sade(8) - remains the only safe and sane way to handle MBR disks. bsdinstall seems fine for GPT, but its paradigm doesn't play so well with trying to do the sorts of manipulations you're talking about here. Why noone's tried to update sade(8) for GPT I don't understand; it's a far better, more forgiving interface, in my old-fashioned? view. (The latest BIOS version 2.4.0 for Dell T1500 does not support UEFI/GPT/GUID.) The second disk ada1, now has three FreeBSD slices: 1) ada1s1 with FreeBSD 8.1-RELEASE 2) ada1s2 with FreeBSD 8.2-RELEASE 3) ada1s3 with FreeBSD 8.3-RELEASE I want to install the new FreeBSD 8.4-RELEASE on ada1s1 by overwriting the now existing two first slices. This means that ada1s3, must become ada1s2 instead. Is this possible to do? Yes and no. Using sysinstall|sade on my 9.1 laptop -- without setting sysctl kern.geom.debugflags=16 so it can't write any inadvertent changes to my disk :) -- in the fdisk screen you can delete the first two slices freeing their space for a new slice (or two) and you can then allocate s1 ok, but the existing s3 is still called s3. Would that be a problem? If you only created one slice there you'd have s1 and s3, with s2 and s4 marked as empty in the MBR shown by fdisk(8). MBR slice order need not follow disk allocations, eg s4 might point to an earlier disk region. sysinstall|sade has undo options for both fdisk and bsdlabel modules; it's easy to play with, no chance of damage - even with foot-shooting flag set, unless/until you commit to changes. If in doubt hit escape until it backs right out, nothing will be written. A very important question is if sysinstall's option Install the FreeBSD Boot Manager detects that I have a FreeBSD 8.3 and detect it as slice 2 on disk 1? So it becomes a boot option when I am rebooting? (Maybe the slice may come up as ad6s2, because AHCI in FreeBSD 8.4 isn't enabled at the time of the install.) If you're running 8.4 sysinstall as init, ie booted into the installer, and you've told it to install to s1, then it should set s1 as the active partition in the disk table and in boot0cfg's active slice table. I've never tried it with a second disk so I can't confirm that will all play nice, but you seem to have installed 3 versions ok before :) If not, you can run boot0cfg(8) anytime to set the active slice etc, so that shouldn't be a worry. Likely need to set debugflags=16 to do that on a running system also .. don't forget to set them back to 0 later! (For anyone) still nervous about sade for setting up MBR disks, play with a spare memstick, setup a couple of slices, boot0cfg etc, allocate and delete slices and partitions. Jordan got that together 15years ago so noone would ever need to do those icky slice/partition maths again. My theory: few have been brave enough to dare mess with $deity's work, though it just needs some updates for modern realities, not abandonment. [ Polytropon, it's not 'obsolete' at all; still in 9 anyway. It'll be obsolete when there are no more MBR-only systems in use - say 7 years - OR when bsdinstall incorporates all the missing good sade(8) features, which requires it making a clear distinction between GPT and MBR and working accordingly, including
Re: FreeBSD slices and the Boot Manager
On Sun, 28 Jul 2013 22:23:38 +, Teske, Devin wrote: In this case, sade is (or was) a direct by-product of the death of sysinstall(8). It only exists in 9 or higher. % which sade /usr/sbin/sade System is FreeBSD 8.2-STABLE of August 2011. I think sade has been introduced in a v8 version of FreeBSD. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
Hi Devin, Apropos sade (sysadmins disk editor). I have it at /usr/sbin/sade and I am running a FreeBSD 8.3. I also mounted FreeBSD 8.1 and FreeBSD 8.2 and found sade at /usr/sbin/ even in these older FreeBSDs. Regards, Conny On Sun, 28 Jul 2013, Teske, Devin wrote: In this case, sade is (or was) a direct by-product of the death of sysinstall(8). It only exists in 9 or higher. In-fact... sade was (up until recently in HEAD) actual code removed from sysinstall(8). NOTE: In HEAD, sade(8) is now a direct path to bsdinstall partedit I don't know what the long-term goals are for sade, but it's a nice 4-letter acronym that's a nice keystroke saver (at the very least). -- Devin On Mon, 29 Jul 2013, Ian Smith wrote: --- --- --- Right. sysinstall(8) - or at least the fdisk and bsdlabel modules that constitute sade(8) - remains the only safe and sane way to handle MBR disks. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD slices and the Boot Manager
On 29/07/2013 08:23, Polytropon wrote: On Sun, 28 Jul 2013 22:23:38 +, Teske, Devin wrote: In this case, sade is (or was) a direct by-product of the death of sysinstall(8). It only exists in 9 or higher. % which sade /usr/sbin/sade System is FreeBSD 8.2-STABLE of August 2011. I think sade has been introduced in a v8 version of FreeBSD. Or earlier. On 9.1 man sade says -- HISTORY This version of sade first appeared in FreeBSD 6.3. The code is extracted from the sysinstall(8) utility. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
