<botifico-c849d97b>
[haikuports/haikuports] jmairboeck 6feb326 - gltron: new recipe (#8562)
<Begasus>
PR created for imagemagick
<B2IA>
(UnrealNeil) braewoods__: I am aproaching this from a different angle. I have a ReadyNAS 6 Pro, I want to upgrade the OS.... Haiku would be nice. I would love to avoid any form of Linux, because I like Haiku.... but it seems that it will have to be linux, because Haiku probably doesn't support it... And of course all my precious data is stored on the RAID, and it's x-raid.... so Yes, it does matter. Bonus Question, since
<B2IA>
you've turned the conversation... does Haiku support any Raid? perhaps Software RAID, as you as touting...
<braewoods__>
UnrealNeil: no idea honestly, i was just saying i try to avoid getting hung up on a feature that can probably be reproduced with something else.
<braewoods__>
but i don't recall seeing anything related to RAID with the haiku disk management stuff.
<braewoods__>
I usually use ZFS which has support for a handful of BSDs, Linux, and maybe even Illumos.
<Begas_VM>
bbl
braewoods__ has left #haiku [Leaving]
vezhlys has joined #haiku
floof58 is now known as Guest675
floof58 has joined #haiku
Guest675 has quit [Ping timeout: 480 seconds]
<trungnt2910[m]>
When porting apps -rdynamic can be safely ignored on Haiku right?
<Begasus>
shouldn't change anything, only thing that's changed is the location for cmd:convert :) Thanks!
<Begasus>
waddlesplash, icu70 is still disabled (was so for beta4), is this still an issue?
<waddlesplash>
needs someone to do some careful validation
<Begasus>
or shouldn't it be updated to the one from the PR from jmairboeck ?
<Begasus>
requires "lib:libicui18n >= 70.1" of package "kiwix_tools-3.3.0-1" could not be resolved
<jmairboeck>
I just enabled it for x86 and x86_64, I didn't test it
<Begasus>
for kiwix_tools :) (it was still build when icu70 was enabled)
<jmairboeck>
can kiwix_tools be built with icu66?
<Begasus>
as mentioned on the PR, I guess conflicting the devel_package shouldn't brake anything for icu?
<Begasus>
probably it will jmairboeck , just requiring about icu, fix for kiwix_tools would be just a revbump
<jmairboeck>
for texlive (specifically bibtex) it is not so easy, it requires icu >= 70, I didn't want to patch that out, as eventually we will hopefully move to a newer ICU version
<Begasus>
libssh needs to be fixed for libnetwork :)
<puck_>
KapiX: right, my suspicion is that it's not seeing the right disk
<KapiX>
my thoughts as well
<KapiX>
more details: the new disk is in nvme slot 0, boot disk nvme slot 1
<puck_>
yup, that explains
<puck_>
KapiX: can you boot into linux and dump (redacted, if desired) efibootmgr -V lines for the two NVMe slots?
<puck_>
(aka the device paths)
<jmairboeck>
about flif: it seems pretty much dead (superseded by jpeg-xl) and not used by anything in haikuports if I'm not mistaken. Should we keep that?
<KapiX>
puck: efibootmgr -V tells me the version, -v doesn't seem to print what you are asking for?
<KapiX>
oh, sorry, -v works
<KapiX>
Boot0001 Hard Drive BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)0000474f00004e4fcd000000080000008d004c006500780061007200200053005300440020004e004d00380(...moregibberish)
<puck_>
oh right. the device paths can play that way
<KapiX>
BootOrder: 0002,0001
<KapiX>
I don't understand why the problem only started when I formatted the partition, does the loader bail at first BeFS partition found?
<puck_>
..wait, how do you start the haiku loader
<KapiX>
chainloaded from grub
<puck_>
hm, that's a factor i'm less certain of
<puck_>
does it work if you load it directly from the EFI? or e.g. via efi shell
<KapiX>
wait a minute, it worked without problems for 4 years
<KapiX>
I did not change the GRUB entry
<puck_>
yes
<KapiX>
let me see what I can do in EFI shell actually
<KapiX>
brb
KapiX has quit [Quit: KapiX]
Diver has quit [Quit: Leaving.]
Diver has joined #haiku
nosycat has quit [Quit: Leaving]
KapiX has joined #haiku
<KapiX>
puck_: running the loader from EFI Shell gave the same result
<puck_>
KapiX: is your efi loader 4 years out of date too? :p
<KapiX>
no, I just updated it
<puck_>
hmm
<puck_>
and you were efi-booting on usb?
<KapiX>
? I don't understand
<puck_>
as in, using the efi loader when you booted off usb
<KapiX>
yes
<puck_>
so i checked the source code and it should properly handle multiple block devices even if they're the same - it would be funny if the order mattered here due to some other bug. i'd look into this more but i'm a bit too brainfogged rn
<KapiX>
I have CSM disabled on my mobo
<KapiX>
I'll try "unformatting" the partition
KapiX has quit []
humdinger has quit [Quit: Vision[]: Oi with the poodles already!!]
<PulkoMandy>
are the partition GUIDs all correct? (especially the Haiku ones need to have the Haiku or BeFS GUID, or at least it helps in finding them)
<puck_>
i'm mostly confused about it working when booted off USB
KapiX has joined #haiku
<puck_>
KapiX: i'm not sure CSM is off, otherwise i'm a bit confused at the bios boot specification boot entry :p
<KapiX>
mobo only shows UEFI boot options, and the USB drive also has "UEFI: " prefix when I'm choosing it
<KapiX>
unformatting did not help
<KapiX>
PulkoMandy: on the boot drive Haiku partitions are marked correctly (according to drivesetup)
<KapiX>
only the other disk had BeFS partition marked as "Linux data" but it was supposed to be storage so it shouldn't matter
<KapiX>
I'm trying to read the log but it seems incomplete :/