Hp Pavilion Notebook "B&O" is booting this way


#22

Unfortunately, this seems to be the only feasible approach I know of.

I am uncertain if Windows would respect a write protect flag and if Haiku would boot from a write protected volume. However, this could be a possibility with a Haiku script setting the flag on shut-down and thus protecting the drive from Windows bread crumbs.


#23

What exactly are these bread crumbs and why does it fumble with the boot process?


#24

Played a bit more around with it. The USB keyboard works on the docking station and directly plugged into the laptop. The USB mouse (budget model as typically handed out by companies for worker laptops) is not working neither on the docking station nor directly plugged into the keyboard. On the other hand the touchpad works. Kinda strange.

EDIT: Interesting. After working for a few minutes the USB keyword suddenly stopped responding. Plugging it out and back in had no effect. The inbuilt keyboard still works. Unstable USB system?


#25

I don’t see how Windows would write anything to a BFS partition it has no knowledge of. I never ran into problems multi-booting Windows with Linux or Haiku over the last decade. What makes you think it would write to other partitions?


#26

As far as I know, Windows is the only operating system which has a “Time of Last Access” flag for folders and files,

I would not be surprised that there is a similar flag for removable volumes such as USB Flash Drives. Because Windows does not understand the BFS partition, it may have issues with it and leave a flag which then interferes with the subsequent boot process.

As a matter habit, I never leaves any of my Haiku USB Flash Drives attached to the system when going into Windows. This comes from having experienced some challenges booting Haiku after leaving them attached while in Windows in my early days exploring Haiku.


#27

Um, no. Unix definitely does; I’ve used it with ls I think with the -ul flags if I rememer right. I think, though I may be wrong, that stat also does this. I’ll have to check that one though. But definitely look into atime (and ctime and mtime).


#28

Yes I can confirm that… If I do not remove the USB-Drive Windows will start… ignoring the Stick…


#29

I tried not booting windows in between but the effect is the same. Whatever. I know now I need to reboot 2-3 times to get it working. Writing it off as HW/BIOS problems.


#30

I ran into this issue on my HP Pavilion G6. It was a pain, so I ended up deleting Windows. Try unplugging the power/battery. That way you don’t have to wait for windows to boot and shutdown 3 times. 3 was the magic number on mine too.


#31

On a side note, whenever I do a fresh Haiku install with certain versions, or on certain updates, I seem to have wait for a couple boot time kdls to flush through the system. Each time it will kdl in two different places before finally booting fine until the next install/update.


#32

I do not like this UEFI Stuff…
Before it was easier to boot into Haiku…


#33

Same here. I wiped my UEFI tears away when I wiped Windows off my computers. I’ll stick with tried and true MBR and occasionally test UEFI. I’ve got enough headaches.


#34

Are we talking of warm restarts instead of full power-off/reboot cycles?

As no other users seem to currently have this issue, is-it possible that this is particular to the HP Pavilion line?


#35

no I have this issues on my Tarox PC as well


#36

I’m assuming it is particular to the HP Pavilion G series laptops. Mine does the same behavior as described by OP. My G6 has several peculiar activities that are specific to it. Crashing while running the Haiku build system in Haiku is one. I can use haikuporter just fine. I can run other build systems in Haiku just fine I can build haiku in Linux just fine. Building haiku in haiku results in a crash every time. Dead lock up, not possible to get kdl or recover the syslog. This only occurs on the G6, no other hardware that I have. The G6 also has a dead lock up on shutdown, but not reboot or shutdown -r. Same no kdl or recoverable syslog. And of course the USB booting misstep noted above.