Hi, I've been using FreeBSD for many years. Not as my main operating system, though. But anyway several bugs and patches were contributed and somebody even added my name into the additional contributors list. That's pleasing but today I tried to install the FreeBSD 11.0 and I'm upset about this operating system. First of all I faced an old problem that I reported here a year ago: http://comments.gmane.org/gmane.os.freebsd.stable/96598 Completely new USB flash drive flashed by the FreeBSD-11.0-RELEASE-i386-mini-memstick.img file kills every Windows again. If I use the Rufus util to write the img file (using DD mode) the Windows dies immediately after the flashing. If I use the Win32DiskImager (suggested by the Handbook) it doesn't reinitialize the USB storage and Windows dies only if I remove and put that USB flash drive again or boot Windows when it is connected. Nothing was done to fix this nasty bug for a year. Ok, I've used the trick and rebooted Windows manually into the BIOS setup right after I flashed the USB disk by the Win32DiskImager. The FreeBSD 11.0 installation has started. I did it on my old computer with MBR disk schema and installed the FreeBSD on the second MBR slice (ada0s2). The installation finished. I changed the BIOS boot configuration back, started to reboot and quickly removed the USB flash drive (I didn't want to kill Windows again). But suddenly my computer appeared unbootable. The new MBR code, that was rewritten without any notation, can't find any OS. I tried to reboot several times. Why bsdinstall doesn't ask about changing the MBR code? Maybe I don't want to change it. Or maybe I want to install the BSD boot manager version of the MBR code (boot0cfg -B). Ok, I booted from the installation USB drive again and ran 'boot0cfg -B ada0'. My computer is bootable again, but only for Windows. If I press F1 the Windows boots properly. If I press F2 or F2 and Enter I see only hash tags. If I reboot after that I see F2 already selected. But if I wait (for F2 - FreeBSD) to the selected OS automatic boot I see the hash tags again. WTF? I've never seen such bugs with boot0 in any previous FreeBSD version. I'm upset. Someone else at my place was throwing the FreeBSD 11.0 installation media far away right after the first problem. What is going on? At least, how to finish the quest? FreeBSD is losing popularity for Linux these days. I think such a bad user experience of very basic use cases is one of the main reason for this loss. Forgive me for saying that, I'm just upset.
Hi. On 17.10.2016 5:44, Rostislav Krasny wrote:> Hi, > > I've been using FreeBSD for many years. Not as my main operating > system, though. But anyway several bugs and patches were contributed > and somebody even added my name into the additional contributors list. > That's pleasing but today I tried to install the FreeBSD 11.0 and I'm > upset about this operating system. > > First of all I faced an old problem that I reported here a year ago: > http://comments.gmane.org/gmane.os.freebsd.stable/96598 > Completely new USB flash drive flashed by the > FreeBSD-11.0-RELEASE-i386-mini-memstick.img file kills every Windows > again. If I use the Rufus util to write the img file (using DD mode) > the Windows dies immediately after the flashing. If I use the > Win32DiskImager (suggested by the Handbook) it doesn't reinitialize > the USB storage and Windows dies only if I remove and put that USB > flash drive again or boot Windows when it is connected. Nothing was > done to fix this nasty bug for a year.I saw this particular bug, and I must say - man, it's not FreeBSD, it's Rufus. So far Windows doesn't have any decent tool to write the image with. As about Rufus - somehow it does produce broken images on a USB stick (not always though), which make every Windows installation to BSOD immediately after inserting. And this continues until you reinitialize the stick boot area. My opinion on this wasn't changing regardless of the operation system: if something traps after something valid happens (like USB flash is inserted) - that's OS problem, not the problem of whoever triggered this. Especially in the case when the USB flash is inserted, containing no FS that Windows can recognize and mount ouf-of-the-box. A non-bugged OS just shouldn't trap whatever is inserted in it's USB port, because it feels like in the cheap The Net movie with Sandra Bullock. FreeBSD has many problems (and I'm upset with it too), but this just isn't it. Just because such thing never happens when you create the image using dd on just any OS that has it natively. So it's bad experience with Rufus, not with FreeBSD. P.S. By the way, win32diskimager is a total mess too. Sometimes it just does nothing instead of writing an image. I did try almost all of the free win32 tools to write image with, and didn't find any that would completely satisfy me. Rufus would be the best, if it didn't have this ridiculous bug with BSOD. Eugene.
> On 17 Oct 2016, at 02:44, Rostislav Krasny <rosti.bsd at gmail.com> wrote: > > Hi, > > First of all I faced an old problem that I reported here a year ago: > http://comments.gmane.org/gmane.os.freebsd.stable/96598 > Completely new USB flash drive flashed by the > FreeBSD-11.0-RELEASE-i386-mini-memstick.img file kills every Windows > again. If I use the Rufus util to write the img file (using DD mode) > the Windows dies immediately after the flashing. If I use the > Win32DiskImager (suggested by the Handbook) it doesn't reinitialize > the USB storage and Windows dies only if I remove and put that USB > flash drive again or boot Windows when it is connected. Nothing was > done to fix this nasty bug for a year.I?m afraid that?s a Windows problem. And potentially a critical one. That barfing upon USB insertion might point to a buffer overflow condition. Now that people from Microsoft are reading these lists and polishing support for the Microsoft hypervisor, maybe they should slap some wrists in-house (hard!). *nudge*-*nudge*-*wink*-*wink*. Borja.
On 17.10.2016 11:57:16 +0500, Eugene M. Zheganin wrote:> Hi. > > On 17.10.2016 5:44, Rostislav Krasny wrote: > > Hi, > > > > I've been using FreeBSD for many years. Not as my main operating > > > system, though. But anyway several bugs and patches were contributed > > and somebody even added my name into the additional contributors list. > > That's pleasing but today I tried to install the FreeBSD 11.0 and I'm > > > upset about this operating system. > > > > First of all I faced an old problem that I reported here a year ago: > > http://comments.gmane.org/gmane.os.freebsd.stable/96598 > > > Completely new USB flash drive flashed by the > > FreeBSD-11.0-RELEASE-i386-mini-memstick.img file kills every Windows > > again. If I use the Rufus util to write the img file (using DD mode) > > the Windows dies immediately after the flashing. If I use the > > Win32DiskImager (suggested by the Handbook) it doesn't reinitialize > > the USB storage and Windows dies only if I remove and put that USB > > flash drive again or boot Windows when it is connected. Nothing was > > done to fix this nasty bug for a year. > > I saw this particular bug, and I must say - man, it's not FreeBSD, it's Rufus. > So far Windows doesn't have any decent tool to write the image with. As > about Rufus - somehow it does produce broken images on a USB stick > (not always though), which make every Windows installation to BSOD > immediately after inserting. And this continues until you reinitialize the > stick boot area.The DD mode in Rufus and in any other flashing util that supports the DD mode (including the native dd(1) program) just writes the image file byte by byte without any change, isn't it? If you say the boot area re-initialization resolves the BSOD issue then why the boot area isn't fixed in the image file at the first place? I agree that Windows has a serious bug but why FreeBSD doesn't try to workaround it? After all people try to install FreeBSD and if the Windows bug and the FreeBSD developers stubbornness prevent them to do so they just can't and won't install FreeBSD. This is a lose-lose situation.> P.S. By the way, win32diskimager is a total mess too. Sometimes it just > does nothing instead of writing an image. I did try almost all of the free > win32 tools to write image with, and didn't find any that would completely > satisfy me. Rufus would be the best, if it didn't have this ridiculous bug with > BSOD.Did you try the native FreeBSD dd(1) program or a MinGW version of dd(1)? And what about other issues I've described in my first email? I managed to install FreeBSD 11.0 but it still unbootable. P.S. please Cc your replies to me since I don't receive this mailing list emails directly, although I'm subscribed.
On Mon, 17 Oct 2016 03:44:14 +0300 Rostislav Krasny <rosti.bsd at gmail.com> wrote:> First of all I faced an old problem that I reported here a year ago: > http://comments.gmane.org/gmane.os.freebsd.stable/96598 > Completely new USB flash drive flashed by the > FreeBSD-11.0-RELEASE-i386-mini-memstick.img file kills every Windows > again. If I use the Rufus util to write the img file (using DD mode) > the Windows dies immediately after the flashing. If I use the > Win32DiskImager (suggested by the Handbook) it doesn't reinitialize > the USB storage and Windows dies only if I remove and put that USB > flash drive again or boot Windows when it is connected. Nothing was > done to fix this nasty bug for a year.As was already said in the other answers this is a bug in Windows. Particulary in the partition parser. partmgr.sys (running in kernel mode) crashes while parsing the FreeBSD installation images GPT setup. This may be a variant of the bug known as "Kindle is crashing Win 10": http://answers.microsoft.com/en-us/windows/forum/windows_10-performance/plugging-in-kindle-is-crashing-windows-10-after/5db0d867-0822-4512-919e-3d7786353f95?page=1 That bug was patched on september 13 and I'm unable to reproduce the crash on a fully patched Win 10 VM. But there's no patch for Win 7, even with all patches applied my Win 7 VM is still crashing as soon as the FreeBSD installation image is connected. I did some debugging and I'm pretty sure that the problem is not the pmbr used for classic BIOS boot but the GPT itself. But my knowledge of GPT and especially Windows internals is limit. So maybe someone with more insight can look into this. Or even better: Complain to Microsoft. Even if the GPT is invalid it should crash the kernel. Regards, Yamagi -- Homepage: www.yamagi.org XMPP: yamagi at yamagi.org GnuPG/GPG: 0xEFBCCBCB
On Tue, Oct 18, 2016 at 21:57:29 +1100, Ian Smith <smithi at nimnet.asn.au> wrote:> > If FreeBSD GPT images (and Kindle readers) can trigger this, so could a > theoretically unlimited combination of data on block 2 of USB media; > modifying FreeBSD to fix a Windows bug should be out of the question.Not modifying FreeBSD and not fixing Windows bug but modifying the FreeBSD installation media and working around the Windows bug to let people install FreeBSD without disappointing at very beginning. Why GPT is used in the memstick images at all? Why they can't be MBR based? I think they can.