Vfs: crash after 10.0 dual-boot transfer

[max21]

Hello again,

As some of you know I have been posting small issues about intalling FreeBSD-10.0. From my last thread I finally got everything work perfectly. Now I have a problem transferring the entire FreeBSD-10.0 partition to my main hard drive using a live linux disk that have worked for many years and still works for everything else up to this 10.0 version of FreeBSD. Please allow me to explain how I build what I think is still the beginning of my ULTIMATE basic dual-booting machine.

I’m working with two machines. One has a 80GB HDD and my main machine (machine #1) has a 500GB HDD. First I use my out-of-the-box Partition-Tool to make 3 primary disk and a extended disk for linux and swap on my main HDD. On this drive I must install Windows first on primary-3 so that it doesn’t go into the state-of-shock and mess up the MBR in the end. It will take over the MBR, and that’s why it must be the first install. FreeBSD never done until 10.0. MAYBE it did, or did not, but something has surely changed ...

I use machine #2 to install FreeBSD on a already created UFS partition of 75000MB by my partitioning tool; which is deleted by the new FreeBSD installer because it force the issue to create its own partition of the size you give it. This is another bad idea in this new installer. It’s all our fault. Many user use to complain about the old installer for years. They wanted it to be like linux I guest and it was FreeBSD aim to please the new generation cry-babies.

Anyway, once I do a complete near ULTIMATE install of FreeBSD, fully packed with all the applications I need! After testing and dressing-up FreeBSD, I than place the 80GB HDD on machine one. I insert my live linux CD and copy [dd] sdb1 to sda1 or sda2 ; which both are already UFS formatted and the same size of 75000MB. As you see, we have left Window on sda3 along, and it will now pay for its MBR take-over disk actions once this set-up is finish. Soon linux will play a part.

This has never fail since 7.2, 8.2, and 9.2, but now it fail with10.0 and I did it twice to be sure that I made no mistakes. I live this ... I don’t need to be told more than twice that it don’t work anymore! That is a very bad thing at this moment but it could be a nice security action that FreeBSD created, or even not have a clue about the benefit when it comes to servers. So I am not crying too hard.

I could simply make FreeBSD-10.0 the first install on my main machine than build the primary-2 for FreeBSD-9.2, than build primary-3 for Windows to take over the MBR, than finally add ARCH-LINUX or Fedora on extended with GRUB to kick all their assies to allow dual-booting of them all. Yes, LINUX has a use in the FreeBSD world. Trust me, maybe any BSD, but for sure, FreeBSD is the greatest computing tool expecailly with this set-up! It allow FreeBSD to manupulate every os on that disk for the better!

Anyway, here is the problem and it seems as stated above but unlike Windows, FreeBSD has taken a new road, by doing HDD checking but has now caused a problem when switching partitons to another harddrive of a difference brand. This is not what FreeBSD is suppose to be about according to its history!

In my opinion FreeBSD don’t need to do this (if that is the case) because it will rules anyway based on our standard dual-booting setup/or it just does anyway. I did not invent this setup. Many threads taught me how to back when google got started.

This is FreeBSD. .. I’m sure this is simple and can be manually fixed, but I don’t know how. I want to keep this install and build my technical BSD skills instead of taking the easy way out that may or will cause problems when I want to transfer my already build system remotely to disk. How do I fix this. This old dog don’t need that change but I am willing to learn new tricks.

I hope I covered every needed detail without going overboard by including my own personal opinions abot the system.

Thank you

GEOM_PART: integrity check failed (diskid/DISK-this-disk-XXXXXX, BSD)
Trying to mount root from ufs:/dev/ada0s1a [rw] ...
Mountroot: waiting for device /dev/ada0s1a ...
Mounting from ufs:/dev/ada0s1a failed with error 19.

Loader variable:
	vfs.root.mountfrom=ufs:/dev/ada0s1a
	vfs.root.mountfrom.options=rw

		And some may knows the rest
		..............
		..............

 

[bsdkeith]

Re: Vfs: crash after 10.0 duel-boot transfer

I would also like to know what

failed with error 19

means.

EDIT: Found this to do with error 19.

[amd64, i386] FreeBSD 9.0-RELEASE includes several changes to improve resource management of PCI devices. Some x86 machines may not boot or may have devices that no longer attach when using ACPI as a result of these changes. This can be worked around by setting a loader(8) tunable debug.acpi.disabled to hostres. To do this, enter the following lines at the loader prompt:

set debug.acpi.disabled="hostres"
boot

Or, put the following line into /boot/loader.conf:

debug.acpi.disabled="hostres"

 

[wblock@]

Re: Vfs: crash after 10.0 duel-boot transfer

In this case, it is not an ACPI error.

intro(2) (or man errno) shows error numbers. 19 is ENODEV, which means "operation not supported by device", or sometimes "device not present".

There are so many things going on in the first post that I don't know what to say. Well, one thing: when copying partitions with dd(), expect problems. Again: dd() is not a filesystem-level tool. It copies bytes as told, whether that will work or not. Do not use dd() to copy filesystems. FreeBSD UFS filesystems are copied with dump() and restore(). Here is an article about that which gives examples: Backup Options For FreeBSD.

There are other possibilities. MBR and FreeBSD partitions (not slices) depend on two types of bootcode. Disks must be set up correctly, and it's particularly hard for multiboot with MBR. Here is an article that covers MBR setup (but not dual-boot): Disk Setup On FreeBSD. The MBR part is the second half.

If I have to dual-boot a system, I install Windows first, leaving enough of the disk unpartitioned for FreeBSD. Then I would back up the Windows install using Clonezilla. Then I would install FreeBSD, using the "manual" disk partitioning to add the correct slice and partitions (Thread 45072). Then I usually install either FreeBSD's multiboot loader with boot0cfg(), or restore the Windows MBR bootcode and use EasyBCD (scroll to bottom, click Register, registration not required).

Given the choice, I would prefer virtualization, which avoids all these problems and others.

 

[max21]

Re: Vfs: crash after 10.0 duel-boot transfer

Thanks bsdkeith, I tried by booting to FreeBSD-9.2 on ada0s2 (sda2) and mounting ada0s1. I typed the code in the loader.conf, fixed up GRUB to rebooted to FreeBSD-10.0 but it did not work as fblock indicated.

There are so many things going on in the first post that I don't know what to say. Well, one thing: when copying partitions with dd, expect problems. Again: dd is not a filesystem-level tool. It copies bytes as told, whether that will work or not. Do not use dd to copy filesystems.

fblock, you said a few times to many in my previous threads that I did not provide enough details and that I need to format my posts. This only waste a poster time and can throw him off the point. But anyway, I try and I now provide details to the fullest, designed to give even a newbee the complete map of what’s going on ... and I do my best to format the thread properly so there will be no delay .... but you now tell me:

There are so many things going on in the first post that I don't know what to say.

I’m sure you notice that even other posters has adopted your suggestion which was a good thing until now. I read new threads quite often.

Re-read my first post above. It’s in plain and simple English and my method of using a linux live-cd has been working since FreeBSD-7.2 ... which is fast enough for the situation and it has been with-out an issue whatsoever until 10.0 ...

There is no need to say more other than Linux carry the ULTIMATE dd tool, which I can assure you that FreeBSD never accomplished properly. I tested and compare them both every new version of FreeBSD. The results in size touched are always difference. Just google, it’s a known fact that FreeBSD loss here, but this is not the question.

I plan to use no Windows tools as a work-around. Linux is more trustworthy for such a simple job. As I said above, I want to fix what is now on my main disk. I hope I don’t loss friends because of that.

How about the solution to the

device not present

What get confusing is talking about everything else than the original question. That's where we all can go wrong.

 

[wblock@]

Re: Vfs: crash after 10.0 duel-boot transfer

We discovered last week that using dd() on Linux had some problems, and I have no idea what you mean by "ultimate dd tool", but let's ignore that for now.

The error in the first post is an integrity check failure. That partition integrity check makes sure the partitions don't overlap, for example. When the partitions are not correct, that check prevents booting (or the disk device being created) to prevent data corruption. That the partitions are not correct is probably due to using tools which are not standards-compliant to the extent FreeBSD is. I disagree that FreeBSD components are broken because your procedure doesn't work. Actually, I have used FreeBSD as described and it worked, which suggests either the procedure or the non-FreeBSD tools are the problem.

I'm sorry if you feel formatting posts is too difficult. What I meant about the first post is that the procedure is so complex that it is difficult to figure out where the problem lies.

 

[bsdkeith]

Re: Vfs: crash after 10.0 duel-boot transfer

In this case, it is not an ACPI error.

intro(2) (or man errno) shows error numbers. 19 is ENODEV, which means "operation not supported by device", or sometimes "device not present".

Thanks for the info, will try & remember man errno.

 

[max21]

1)
fblock, After some sleep I re-read my own thread, and it was confusing. It sound like I was promoting Linux. Never getting to the main point of my question ... If it was not for the title of this thread, the error-code would just be a error-code at the bottom of the page.

2)
Anyway, I use the old Fedora-12 and a very old Arch linux only for dd’ing to take care of FreeBSD and Windows partitions and backups and it never fail. The problem is the newer version of linux for dd’ing and a lot more is not to be trusted. I bet that is what you used to get those bad results. Sorry I did not mention that I use the old versions of linux.

That partition integrity check makes sure the partitions don't overlap,

3)
You’re right again fblock - you got 21/2 out of 3 , logic is logic. This could be possible. When I used my partitioning tool I should have made primary-1 a few megabyte bigger than 75000MB because primary-one size always smaller than primary-2 of the same size of 75000MB. I guest because it touches the MBR department. So it’s back to the drawing board.


Thank you for expertise and being U

 

[wblock@]

1) fblock,

That's a "W".

2)
Anyway, I use the old Fedora-12 and a very old Arch linux only for dd’ing to take care of FreeBSD and Windows partitions and backups and it never fail. The problem is the newer version of linux for dd’ing and a lot more is not to be trusted. I bet that is what you used to get those bad results. Sorry I did not mention that I use the old versions of linux.

The problem we found with Linux was that it buffered writes, making it appear to be very fast. But the data was corrupted (not completely written) unless the user forced it all to be written with sync().

3)
You’re right again fblock - you got 21/2 out of 3 , logic is logic. This could be possible. When I used my partitioning tool I should have made primary-1 a few megabyte bigger than 75000MB because primary-one size always smaller than primary-2 of the same size of 75000MB. I guest because it touches the MBR department. So it’s back to the drawing board.

Linux partitioning tools like gparted make assumptions, like rounding all partitions to 1M. These do not always work with strict standards, like the one for the MBR that says partition sizes must be multiples of CHS values.

dd() makes no assumptions. Because of that, it copies a lot of data that is empty, and takes more time than necessary. When copying partitions, the destination must be either the exact same size or larger than the original. Making it the exact same size is difficult when using two different operating systems. Making it larger wastes space.

 

[max21]

It works! What I did was to increase the size of the partition on a my second 500GB hard drive that I had in storage. I increase both primary 1 and 2 from 75000MB to 77824MB (76-GB), and than I copy both OS partitions to that disk.

So device not found can equal overwriting your own partition, making it not found! That was the first and last for me. You won’t hear me crying wolf again.

The only real problem I had with FreeBSD dd is that it won’t dd another FreeBSD partition unless you run a or some commands in advance and afterwards (to reset), which was a pain. I do use FreeBSD dd for EVERYTHING else once I done the Arch setup thing. I never boot to Arch thereafter unless something major went wrong with FreeBSD. That is how I do a major replacement with backup. That was another important detail that I did not no go into.

Thanks @wblock@ for the key word — overwriting, and your previous thread. I'm going to be looking into it.

 

[wblock@]

The only real problem I had with FreeBSD dd is that it won’t dd another FreeBSD partition unless you run a or some commands in advance and afterwards (to reset), which was a pain.

I have no idea at all what you are talking about here. If you would try dump(8) and restore(8), you'll find they work, and can even restore to partitions smaller than the original. Combine that with use of gpart(8) to create partitions, and an understanding of how MBR slices and FreeBSD partitions work, and there will be less difficulty later.

 

[max21]

Yes, I use dump(8) and especially tar for everything once inside of FreeBSD, but only after I used GRUB under Linux to play on the partition as mentioned, and that will never change if I can help it. You and others may have issues with time spent or the method itself, but I don’t. I just expect it to work, and now it does as usual after correcting my sizing mistake.

The only real problem I had with FreeBSD dd is that it won’t dd another FreeBSD partition unless you run a or some commands in advance and afterwards (to reset), which was a pain.

I wanted to post the code but I did not remember the command-line sequences I just found it in my old 7.2 command-line listing:

Operation not permitted:

kern.geom.debugflags=0x10		#  if operation not permitted

sysctl kern.geom.debugflags=16		#  after done reset or reboot.

 

[wblock@]

No, do not do that. If you have to do that, it means you are overwriting partition structures that are in use. Usually that is because they are mounted.

This is a data protection safety feature of the GEOM system, nothing to do with dd(1).