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.
What exactly are these bread crumbs and why does it fumble with the boot process?
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?
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?
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.
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).
Yes I can confirm thatā¦ If I do not remove the USB-Drive Windows will startā¦ ignoring the Stickā¦
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.
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.
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.
I do not like this UEFI Stuffā¦
Before it was easier to boot into Haikuā¦
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.
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?
no I have this issues on my Tarox PC as well
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.
Hp Pavilion Notebook āB&Oā does not work!
Cannot boot into Startscreenā¦
Will file a bugreport when I got somethingā¦
Is this from a clean Haiku image? It looks like a filesystem corruption problem.
No I used the usb-stick with my other laptop and used SoftwareUpdater with itā¦
So it is not a clean image!?
Shouldānt it work anyway?
I tried a Haiku 64bit USB - Stick
and a Haiku 32Bit USB - Stick
If I do a clean Haiku Imageā¦ what is the difference?
What to try now? Make a new USB - Stick with a nightly build? thx for helpingā¦
As I said it looks like this is not an hardware problem but a corrupt filesystem. To avoid that, you can try downloading a nightly build and writing it to the stick, or use a different stick, or check that the stick works on another computer.
Also, when you have bugs, please report on the bugtracker, not on the forum.
Actually this message almost always means that write-backs failed and left the block cache in an inconsistent state (i.e. the last transaction is still open because blocks in it were not written due to an error.) The syslog will reveal the real reason. So, actually it does often mean a hardware problem.