--- Log for 18.12.122 Server: lithium.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 22 days and 12 hours ago 00.01.05 Quit Trzyzet (Read error: Connection reset by peer) 00.10.29 Quit CH23_M (Read error: Connection reset by peer) 00.10.38 Join CH23_M [0] (~CH23@revspace/participant/ch23) 00.10.56 Quit CH23_M (Read error: Connection reset by peer) 00.11.16 Join CH23_M [0] (~CH23@revspace/participant/ch23) 00.19.19 Quit hexadecagram (Ping timeout: 260 seconds) 01.24.35 Quit massiveH (Quit: Leaving) 01.26.24 Join matii [0] (~matii@83-145-151-199.cable-modem.tkk.net.pl) 01.28.36 Quit matii (Client Quit) 01.58.19 *** Saving seen data "./dancer.seen" 02.12.31 Join matii [0] (~matii@83-145-151-199.cable-modem.tkk.net.pl) 02.13.24 # _bilgus_ it worked! I've managed to get multiboot working with this firmware: https://www.mediafire.com/folder/x9hvpqrmfx76n/Multiboot_Firmware 02.13.43 # <_bilgus_> matii grab the latest dev version 02.13.52 # <_bilgus_> thats so old its scary 02.14.03 # where can i find it? 02.14.30 # <_bilgus_> https://www.rockbox.org/daily.shtml 02.14.40 # <_bilgus_> look for the clip+ 02.14.55 # <_bilgus_> then download and unzip to the root of the sd card 02.15.04 # <_bilgus_> all done 02.15.49 # that's gonna be the multiboot version? 02.16.02 # i mean the one compatible with multiboot 02.16.06 # <_bilgus_> yep its in main now 02.16.18 # wonderful 02.16.22 # <_bilgus_> that post is like 5 years old 02.16.49 # <_bilgus_> while you a re at it grab some themes https://themes.rockbox.org/index.php?target=sansaclipplus 02.17.03 # <_bilgus_> same deal just unzip to root of sd 02.17.33 # wow there are so many 02.18.38 # it'll be difficult to settle on one theme haha 02.19.11 # thank you so much for all your help! i was about to call it quits 02.19.27 # you revived an old sansa 02.27.14 # <_bilgus_> isn't the first hopefully not the last :p 02.27.52 # <_bilgus_> you can grab as many themes as you want with a decent sd card they aren't very large esp for the clip+ 02.28.46 # <_bilgus_> so with the latest fw can you browse the internal memory? 02.29.51 # <_bilgus_> it'll be listed as one of the microSD folders 02.29.57 # <_bilgus_> SD0 likely 02.31.11 # <_bilgus_> once you verify thats the case the other one will be your sd card with the working rb install on it 02.32.12 # <_bilgus_> what you can do is long press select to pop the context menu and go down to 'Start File Browser Here' 02.32.36 # <_bilgus_> or if you have stuff on the internal memory that you can read you can just leave it 02.33.46 # now I have to head out but I'll update you as soon as I install the latest firmware and check the internal storage, hopefully still today 02.34.16 Quit matii (Quit: leaving) 02.43.09 # <_bilgus_> when you get a chance read the manual https://download.rockbox.org/daily/manual/rockbox-sansaclipplus/rockbox-buildch8.html#x11-1570008.5.12 02.43.35 # <_bilgus_> you can hide the internal drive from the usb so you dont see it when you plug it into the pc 02.51.23 # is it a problem to see it ? 02.54.06 # multi-boot is great 02.54.20 # i use it on several sansa's, m3k and q1 03.02.10 # <_bilgus_> their internal drive is ready only 03.02.20 # <_bilgus_> so better to hide it 03.08.33 Join hexadecagram [0] (~acc@user/hexadecagram) 03.18.34 Join lebellium [0] (~lebellium@2a01cb040109a60057484dad52b1f739.ipv6.abo.wanadoo.fr) 03.58.23 *** Saving seen data "./dancer.seen" 05.58.24 *** No seen item changed, no save performed. 06.57.55 Quit toruvinn (Ping timeout: 252 seconds) 06.58.03 Join toruvinn [0] (~toruvinn@KD119106000050.ppp-bb.dion.ne.jp) 07.58.26 *** Saving seen data "./dancer.seen" 09.07.21 Quit CH23_M (Read error: Connection reset by peer) 09.08.38 Join CH23_M [0] (~CH23@revspace/participant/ch23) 09.24.56 Quit jacobk (Ping timeout: 272 seconds) 09.58.27 *** Saving seen data "./dancer.seen" 11.08.41 Join Malinux [0] (~malin@2001:4641:4dfa::12c:c4a7) 11.58.31 *** No seen item changed, no save performed. 11.59.25 Join CH230 [0] (~CH23@revspace/participant/ch23) 12.01.04 Quit CH23 (Ping timeout: 252 seconds) 12.23.36 Join CH231 [0] (~CH23@revspace/participant/ch23) 12.26.24 Quit CH230 (Ping timeout: 260 seconds) 12.27.16 Nick CH231 is now known as CH23 (~CH23@revspace/participant/ch23) 12.55.20 Quit Nezumi-sama (Ping timeout: 252 seconds) 12.57.00 Join Nezumi-sama [0] (~narf@rrcs-67-53-148-69.west.biz.rr.com) 13.09.30 # <_bilgus_> makefiles are a bane to my existence.. 13.10.43 # not the english language ? 13.13.48 # <_bilgus_> very terse 13.22.19 Join mink [0] (~mink@178.197.193.87) 13.58.17 Join matii [0] (~matii@hol2.bg.am.poznan.pl) 13.58.32 *** Saving seen data "./dancer.seen" 14.00.39 # _bilgus_ on the old multiboot firmware from mediafire I can browse the internal storage but it's read-only. And the new dev releases don't open on boot, I have to open the .sansa file manually ("can't locate .rockbox" - even though the location is the same as the old firmware). Have you encountered such a problem before? 14.17.43 # <_bilgus_> matti so it says can't open ,rockbox when you boot it? 14.18.37 # <_bilgus_> matii* 14.19.13 # <_bilgus_> i'm not sure I understand what you mean by don't open on boot 14.21.58 # <_bilgus_> if its still opening firmware on the internal memory you probably don't have the redirect file right 14.24.39 # <_bilgus_> try deleting it and creating a new one that is empty if you did that try grabbing the one johnb supplied here: https://forums.rockbox.org/index.php/topic,51844.msg247373.html#msg247373 14.25.44 Quit Nezumi-sama (Ping timeout: 260 seconds) 14.27.38 # <_bilgus_> the firware should be in the root of the sdcard file structure as such-> /.rockbox if its in another folder it needs to be as such in the redirect file too 14.30.14 # a file with extension .clip+ is unusual on windows 14.32.26 # rockbox_main.clip+ with just a / in it worked for me. just the /, no enter/newline 14.33.54 Join Nezumi-sama [0] (~narf@rrcs-67-53-148-69.west.biz.rr.com) 14.35.55 # <_bilgus_> windows also does that dumb shit of hiding known extensions 14.36.38 # <_bilgus_> 'no clue why people run malware so much' 14.36.50 # but it has icons! 14.37.24 # it could be the reason it did not work for matii though, perhaps some extra extension 14.38.08 # <_bilgus_> I haven't even touched a windows install since win8 it was bad before you were their explicit product i'll STFA from that 14.39.01 # <_bilgus_> I did find it interesting they did the subsystem for linux but thats just a way for them to try and kill linux 14.39.23 # <_bilgus_> or at least wine 14.39.46 # _bilgus_ , spork , my friend will join IRC in a few minutes and explain everything in detail as he's the one working on it at the moment 14.41.10 # today I don't have much time but if the mystery of the dev version not working on multiboot remains unsolved tomorrow, I'll check it on my working sansa clip+ with the redirect file created through "touch" command on my linux machine 14.42.53 # again, thank you very much for your input, it's great to see that the rockbox community and devs are still very much active 14.44.05 # <_bilgus_> the one in the forum post above is known working^ 14.45.33 # the link in the forum post is https://www.rockbox.org/daily.shtml so the known working one is the today's build? 14.46.27 # oh sorry, you probably meant the redirect file, not the firmware 14.46.29 # my bad lmao 14.48.09 Join JanekCzarny [0] (~JanekCzar@89-71-176-5.dynamic.chello.pl) 14.55.17 # <_bilgus_> yeah the redirect, re the daily builds I only use redirected builds so I'm not sure the issue but I'm sue we can figure it out 14.55.26 # <_bilgus_> sure* 14.56.08 # hi, _bilgus_ older fw work pretty good (only disconnecting from usb throws *panic*) and works with .clip+ file empty or "/" 14.57.19 # _bilgus_ the newer fw without .clip+ file don't boot, broken from internal drive is booting 14.59.18 # <_bilgus_> I did some updates to the firmware to fix a bug perhaps the newer firmware doesn't like the empty redirect let me check my device 14.59.24 # with .clip+ file with "/' or empty file newer fw is booting but throws 2 pop-ups, 1: no .rockbox directory, 2: installation incomplite 14.59.55 # incomplete* sry 15.00.26 # <_bilgus_> and the .rockbox directory is in the root of the sd drive? 15.03.56 Quit mink (Ping timeout: 268 seconds) 15.04.06 # yup, but fw works - I can browse files, when I want to play file it's open pop-ups 2 info like I wrote earlier, player skips files to the end of folder and back to file browser 15.05.30 # maybe there are some files missing from the latest dev build? 15.05.42 # <_bilgus_> yeah its not getting its location right so it doesn't have a tether to the the drive for relative paths 15.06.43 Join mink [0] (~mink@178.197.197.31) 15.06.53 # thats problem not exist in older fw, so whats change with path finder 15.07.38 # <_bilgus_> the old fw wouldn't redirect the root it was hardcoded 15.08.08 # <_bilgus_> so once you get the latest fw to boot you should be able to run the multiboot plugin does it list your redirect? 15.08.49 # <_bilgus_> plugins>apps>multiboot_select 15.09.42 # <_bilgus_> it should state something like using root: /<1>/ 15.10.39 # <_bilgus_> rathe get it ran with rolo (by selecting from file browser) 15.11.05 # I cant open none of folders in Plugins like games, apps 15.11.27 # <_bilgus_> yeah I figured that would be the case 15.11.48 # <_bilgus_> ok in the debug menu go to bootdata 15.12.03 # <_bilgus_> main menu>system>debug 15.13.01 # <_bilgus_> it should show Boot Volume: ... Root: ... and CRC: ... what do those three say 15.13.50 # <_bilgus_> on CRC we are looking for BAD or OK not the actual string 15.15.41 # now when i open .rockbox/rockbox.sansa ROLO reboot fw and then I have Plugins>Apps>multiboot_select >select root> pop-up: no roots found 15.17.02 # <_bilgus_> one thing you might try is unzipping the dev fw to a new folder like /dev/.rockbox and in the redirect file write /dev 15.17.39 # boot volume <0> root: /<0> CRC: BAD 15.17.59 # <_bilgus_> yeah its an issue with the redirect file 15.19.10 # <_bilgus_> i'd delete the redirect file and do it fresh the bootloader is v. limited so it doesn't have a lot of logic 15.19.59 Quit matii (Quit: leaving) 15.20.20 # <_bilgus_> you could also make the file on the device from the internal fw just to be sure 15.28.51 # <_bilgus_> if its still not working when you get a chance after a fresh boot what does the internal firmware say in the bootdata menu it should still say <0> or at least CRC: OK! and there will be a string of numbers those should be all 0 (it depends what version it is on if it shows the root) 15.30.09 # I put .rockbox into dev folder and try 3 versions of rockbox_main.clip+ file with: /dev/.rockbox (boot broken 3.15 fw), /dev/ and /dev (boot fw but pop-ups errors like before 15.32.02 Quit mink (Remote host closed the connection) 15.35.58 # in broken fw v:3.15 on internal drive boot data> Magic: {gic! lenght: 4 CRC: c704dd7b CRC: OK! 00: 00 00 00 00 15.36.49 # <_bilgus_> just to be sure you are using a daily build and not 3.15 on the sd card right? 15.38.08 # this one to tests: https://download.rockbox.org/daily/sansaclipplus/rockbox-sansaclipplus-20221218.zip 15.38.16 # <_bilgus_> delete the redirect and make a new empty one and put 3.15 on the sd card does that boot? 15.39.06 # <_bilgus_> it won't do root redirects so it has to be in the root of the drive 15.42.09 # <_bilgus_> ill try downloading that version from the mainsite and see if it works on my clip+ 15.48.16 # 3.15 dont boot, 3.15 boots from internal only 15.48.35 # <_bilgus_> huh 15.49.30 # <_bilgus_> the version I downloaded works fine let me try zipping it up I wonder if the sd card has an issue 15.49.52 # <_bilgus_> why then that old vrsion works no clue 15.50.04 # <_bilgus_> any way give me moment i'll get you a link 15.52.44 # when its boot from sd files from internal are hidden, now all are visible CRC ok, cant play file after loading... screen pop-up error accessing playlist control file (-numbers) 15.53.43 # <_bilgus_> https://www.mediafire.com/file/h789vgy6vc1kpni/ClipPlusDaily12-18.zip/file 15.56.29 # sansa fw is broken (after sansa sign shows logo and thats all), rockbox v: 3.15 was installed on internal but this broke storage to read-only, so 3.15 rockbox wont work on sd because sansa boot 3.15 fw from internal as first 15.56.53 # <_bilgus_> no the bootloader soes all that 15.56.57 # <_bilgus_> does* 15.56.58 # internal 3.15 = sd 3.15 so boot internal first 15.57.38 # <_bilgus_> the firmware just has a special tag in it that the bootloader writes to tell it where it was loaded from 15.58.16 # <_bilgus_> 3.15 has this tag it just didn't understand anything beyond the root of the card 15.58.30 # <_bilgus_> newer fw does and can redirect to other folders 15.58.35 *** Saving seen data "./dancer.seen" 15.59.08 # <_bilgus_> and that bootloader hasn't changed in 5 years so thats not the issue 16.00.05 Join amachronic [0] (~amachroni@user/amachronic) 16.00.15 # <_bilgus_> if you have a different sd card i'd try that either that or format the sdcard with something other than the windows inbuild prompt 16.01.38 # <_bilgus_> https://forums.rockbox.org/index.php?topic=51941.0 16.01.57 # i format sd with linux, windows shows only ntfs or exfat options 16.02.01 # <_bilgus_> the second link HD Low level formatter worked the last time I had to use windows 16.05.12 Quit munkis (Ping timeout: 272 seconds) 16.05.18 # <_bilgus_> in linux you have to be careful what you supply https://forums.rockbox.org/index.php?action=profile;u=60254 16.05.45 # <_bilgus_> sorry https://forums.rockbox.org/index.php/topic,41666.msg229222.html#msg229222 16.06.31 # <_bilgus_> this specifically 'mkdosfs -F 32 -I /dev/sdcX' where X is the proper drive index 16.06.48 # i used gparted 16.06.56 # Build Server message: 3New build round started. Revision d6744c92b1, 303 builds, 8 clients. 16.06.58 # <_bilgus_> try that 16.07.17 # <_bilgus_> there is clearly an issue here so lets go back to basics we know work 16.08.13 # <_bilgus_> that post outlines how to do it his output is in a European language but it gets the gist across 16.09.26 # <_bilgus_> and the media fire link above was just copied from my clip+ so use that for the moment its already set up 16.10.55 # so in hdd llft do low-level format, then put on sd 3.15 fw and make the .clip+ empty file? 16.11.54 # this tool dont have any options in which format i want to do it 16.12.10 # <_bilgus_> ah crap it will only do the first step 16.12.23 # <_bilgus_> let me grab you the formatter link 16.13.20 # <_bilgus_> https://forums.rockbox.org/index.php/topic,53831.msg248368.html#msg248368 16.13.42 # <_bilgus_> the lowlevel formatter will just make sure the card is fully wiped and marks bad sectors 16.14.14 # <_bilgus_> you still have to format it sorry its been every bit of 5 years that i've done this in windows 16.15.14 # <_bilgus_> after done with that grab the mediafire zip above and unzip directly to the card 16.16.51 # <_bilgus_> might even do it out of the device if you have a reader 16.17.17 # <_bilgus_> wouldn't suprise me if the fw running had a USB issue or something 16.17.54 # LLF do magic so we can go for drinks ;) 16.18.40 # fw from interal can suprise you with error inside this broken installation 16.19.05 # <_bilgus_> beyond that IDK without having the device in hand but I guess put that old version that worked back on its just realllly weird 16.20.10 # <_bilgus_> maybe something is corrupted on that internal but it seems very odd for it mess up multiboot and still boot the fw as they are in the same loop 16.20.58 # <_bilgus_> the only other thing I can think is maybe it read errors and it thinks the sd card is drive 0 but then it wouldn't boot the internal at all 16.21.33 # <_bilgus_> curiouser and curious-er 16.22.28 # doesn't it always fall back to internal if multiboot fails for some reason? 16.22.51 # <_bilgus_> yes 16.23.42 # <_bilgus_> the only other thought is maybe rootredirect is just not working right with a bad internal drive I should probably make a bad bootloader that blocks drive 0 and see if it still works 16.24.46 # iirc the old multiboot swapped the drive numbers to make the external SD come up on drive 0 16.25.17 # Build Server message: 3Build round completed after 1100 seconds. 16.25.19 # Build Server message: 3Revision d6744c92b1 result: All green 16.25.30 Join munkis [0] (~mendel_mu@2600:4041:5ad1:6800:b225:aaff:fe48:a92c) 16.25.31 # root redirect doesn't do that so maybe it's trying to access drive 0 (= internal drive) and getting stuck for some reason 16.26.39 # i remember drive 0 was 'special associated with it but i don't know if you got rid of that when you added root redirect 16.26.55 # *special for some reason* 16.26.59 # <_bilgus_> possible so I guess a fw with drive 0 blocked might be a valid way to test 16.27.37 # <_bilgus_> i'll try it on the clipzip I have several of those i'm saving this clip+ for retirement lol 16.30.55 # when boot 3.15 fw from internal and go system> rockbox info> Int: 2.00GiB / 7.35GiB after click select button and scanning disk... its turns to 0KiB / 7.35GiB. Buffer with internal rb fw shows 0KiB and with working rb fw on sd shows more than 4Mb.. if its a hint 16.33.07 # "newer fw is booting with '/' or empty file" -- so that means the bootloader *was* able to load RB from the SD card 16.33.16 Join mendel_munkis [0] (~mendel_mu@2600:4041:5ad1:6800:b225:aaff:fe48:a92c) 16.34.30 # but .rockbox folder couldn't be found, so maybe it's searching in the wrong drive 16.34.31 Quit munkis (Ping timeout: 260 seconds) 16.34.50 # i wonder if a build from before root redirect was added would work 16.36.19 # this fw https://www.mediafire.com/file/jyhyz0dz8t50tzw/ClipPlus_multibootFW_rockbox-full_10_24_2019.zip/file works almost perfect 16.37.12 # only issue *panic* after disconnecting usb 16.41.21 # fw is alive and behave like nowadays kids - dont wanna be disconnected 16.43.54 # JanekCzarny try this build https://drive.google.com/file/d/1II1iG-4JZZE8UWOp3Jwpwizt9BHB2son/view?usp=share_link 16.45.23 # that's one of the last versions before root redirect was added 16.45.40 # with or without .clip+ file 16.45.49 # with the clip+ file 16.46.36 # <_bilgus_> always need the clip+ file for sd boot as the bootloader looks for it 16.47.38 # cant do test now cuz my sd have 35% complete of low-level format ;/ 16.48.35 Quit mendel_munkis (Remote host closed the connection) 16.49.18 # <_bilgus_> how big is this card? 16.49.27 Join mendel_munkis [0] (~mendel_mu@2600:4041:5ad1:6800:b225:aaff:fe48:a92c) 16.49.28 # 64gb 16.51.13 # <_bilgus_> I don't remember it being that slow I take it that its still in the device? 16.52.10 # <_bilgus_> amachronic blocking drive 0 makes it behave like this so it might just be that it enumerates as drive 0 then doesn't realize its actually drive 1 16.52.42 # <_bilgus_> sorry JanekCzarny I probably made you reformat for nothig I guess at least we will be sure its a clean card 16.53.04 # i have it in card reader 16.53.05 # something like the drive numbers aren't the same between bootloader and RB? 16.53.42 # and dont check quick wipe 16.55.43 # <_bilgus_> amachronic, exactly the bootloader says drive 1 and the fw actually checks for a viable drive 16.55.57 # <_bilgus_> doesn't find one and marks the sd as drive 0 16.56.32 # _bilgus_ if its dont work I will be still happy - older fw works and revive this clip 16.56.55 # <_bilgus_> so maybe we can check if the redirect drive is > the nmber of drives found and if not assume its drive 0 16.58.23 # tbh i don't really understand how the redirect works 16.58.54 # i can't follow the 3 different types of "mounting" going on :) 16.59.39 # redirect change drives ( internal with external) 17.00.46 # yeah i mean i can't follow how the code does it 17.01.29 # <_bilgus_> thats a common sentiment of jhmike code lol 17.02.04 # <_bilgus_> dude is very talented but it takes a lot of mental work to follow the code 17.02.38 # <_bilgus_> I think this probably where it is failing https://gerrit.rockbox.org/r/c/rockbox/+/4365/1/firmware/include/dircache_redirect.h#164 17.03.37 Quit user890104 (Ping timeout: 252 seconds) 17.04.09 # redirect is like software-like changing connector on pins on ata drives where u must now which drive you want to set as master to boot from there 17.04.36 # _bilgus_ i'm not too sure of that, that can effectively only happen if get_redirect_dir() gives file not found. 17.05.10 # because the snprintf at the end always prepends a drive number /<#> 17.06.09 # <_bilgus_> right-o 17.07.45 # <_bilgus_> JanekCzarny, actually the way rootredirect works is that it remaps the drives in the namespace rather than physically switching them it acts more like a shortcut when the device accesses the drive it swaps what drive it returns on the backend 17.08.05 # <_bilgus_> rempas might be a better term 17.08.09 # <_bilgus_> remaps* 17.09.11 Join user890104 [0] (~Venci@freemyipod/user890104) 17.17.19 # Build Server message: 3New build round started. Revision e8ad52be94, 303 builds, 8 clients. 17.24.43 # strange code.. unmounting drive to set other drive as first - that shouldnt just lauch other fw with rolo? with redirect u cant access file from internal - little waste of space 17.26.10 # rolo and multiboot don't really work well together 17.26.46 # only do normal hard reboots 17.29.54 # when I do it manually it works.. 17.31.55 # is this with the build i posted earlier? 17.32.35 # so its should work with cmd that launch file like rockbox.sansa 17.34.29 # it should work when you boot like normal, you shouldn't need to do rolo manually 17.38.07 # Build Server message: 3Build round completed after 1247 seconds. 17.38.09 # Build Server message: 3Revision e8ad52be94 result: All green 17.38.54 # when i tested daily build and runs but cant play music, I manually lauch rockbox.sansa then I was able to play music 17.40.47 # not sure but in this way the cfgs always was set as default as new fw 17.49.38 # can you try it again with the build I posted 17.50.41 # its more like the mediafire version that works for you 17.53.31 # Build Server message: 3New build round started. Revision b650e774a1, 303 builds, 8 clients. 17.55.07 # i make low format and format the sd card, test with _bilgus_ fw wont work now I try with yours amachronic 17.58.30 Quit lebellium (Quit: Leaving) 17.58.37 *** Saving seen data "./dancer.seen" 18.01.48 # <_bilgus_> I have an idea of whats broken with it I just need a way to reliably detect it 18.02.08 # <_bilgus_> check in tomorrow I should have it in the dev builds 18.02.46 # <_bilgus_> if all else fails it'll be make a special folder called /nointernal/ but I hope to get a way to detect it automatically 18.09.35 # amachronic with yours fw it works but usb disconnecting gives error, music works, radio works.. doom doesnt ;( 18.10.15 # missing base WAD 18.10.38 # if the usb error is about the playlist control file, it's harmless 18.10.53 # doom requires you to supply your own WAD 18.11.01 # it's not provided with the .zip 18.15.56 # the usb error was something else but now not throws errors, but pc have problem when connected, and shows sd and disk not accessable named SANSA CLIP 18.17.13 # and pop-up error put in disk 18.17.32 # most likely its related to your internal drive going bad 18.17.42 # Build Server message: 3Build round completed after 1450 seconds. 18.17.43 # Build Server message: 3Revision b650e774a1 result: All green 18.18.42 # with older fw shows drive but not freezes pc 18.18.48 # try enabling general settings > system > USB Hide Internal Drive 18.21.54 # Build Server message: 3New build round started. Revision 8165a6c245, 303 builds, 8 clients. 18.23.37 # amachronic thx works ;p 18.24.17 # nice :) at least you can use that until bilgus has a fix 18.24.40 # _bilgus_ so tommorow or today later ( its after midnight for me) will be searching for info here 18.26.01 # bye ;) have a nice day/night 18.26.13 # <_bilgus_> yw, you too 18.26.31 Quit JanekCzarny (Quit: Leaving) 18.35.00 Quit speachy (Quit: WeeChat 3.6) 18.46.56 # Build Server message: 3Build round completed after 1502 seconds. 18.46.57 # Build Server message: 3Revision 8165a6c245 result: 504 errors 20 warnings 18.52.34 # <_bilgus_> so it appears its a bit of a difference between multidrive vs multi volume in the case of it working right its essentially the same but once there aren't two drives the assumption breaks 18.53.21 # <_bilgus_> I just need to test it still works right in the internal drive case but I think Ive got it 18.54.38 Quit hexadecagram (Remote host closed the connection) 18.56.19 # Build Server message: 3New build round started. Revision 992455dc58, 303 builds, 7 clients. 19.05.45 # <_bilgus_> https://github.com/Rockbox/rockbox/blob/master/firmware/export/config.h#L865= 19.06.53 Join hexadecagram [0] (~acc@user/hexadecagram) 19.06.55 # <_bilgus_> I even put a note there abould multi partion booting, I'm not even sure anyone has tried it 19.18.09 # <_bilgus_> g#4938 19.18.11 # 3Gerrit review #4938 at https://gerrit.rockbox.org/r/c/rockbox/+/4938 : 3[BugFix] root redirect failed to match the peoper drive when internal drive is missing by William Wilgus 19.20.43 # this is the drive/volume number mixup coming back to bite us isn't it 19.20.58 # <_bilgus_> yep 19.22.50 # i think we need to version bump the multiboot protocol to deal with this cleanly 19.22.58 # Build Server message: 3Build round completed after 1598 seconds. 19.23.00 # Build Server message: 3Revision 992455dc58 result: All green 19.23.42 # <_bilgus_> thats likely going to require touching bootloaders though 19.23.53 # yes but that's ok 19.24.13 # <_bilgus_> only if you have users to test them 19.24.22 # the point is we want to draw a line so we can say "yes this is definitely a broken bootloader" 19.24.35 # instead of having to guess 19.25.13 # <_bilgus_> the bootloader is always going to work its the firmware where the distinction matters 19.25.41 # the firmware needs to know what version of the bootloader it's dealing with so it can accomodate the bootloader's quirks. 19.26.28 # i'm just suggesting we add a version byte and get new bootloaders to set it to 1 once the volume/drive mixup is sorted out 19.26.51 # the code to handle version 0 will still be there in the firmware 19.29.39 # <_bilgus_> I don't think it does from the perspective of the bootloader NUM_VOLUMES gets morphed into either 19.29.41 # <_bilgus_> NUM_VOLUMES (NUM_DRIVES * NUM_VOLUMES_PER_DRIVE) 19.30.10 # <_bilgus_> so if its 2 drives with 1 volume each or 1 drive with 4 its still going to do the right thing 19.31.03 # drives contain volumes 19.31.08 # volumes contain filesystems 19.31.27 # so the redirect only has meaning if the boot_volume is actually a volume number, right? 19.31.41 # the drive number would be ambiguous if NUM_VOLUMES_PER_DRIVE > 1 19.32.09 # <_bilgus_> I suppose but whatever you call it its still going to just be where the bootloader found it 19.32.36 # <_bilgus_> but the bootloader will be in lockstep with the fw in that case 19.32.49 # <_bilgus_> they are using the same code afterall 19.33.20 # yep 19.33.43 # except if you have flaky hardware causing one of the volumes to fail 19.33.53 # <_bilgus_> its only a problem here because volume 0 is not checked for validity at boot where as it is in the fw 19.34.20 # <_bilgus_> drive 0 heh 19.36.11 # <_bilgus_> the bootloader has no idea what drives and volumes even are really I think it can be fixed on the fw side only 19.36.48 # <_bilgus_> now how to best do that I'll have to think on a bit 19.36.51 # they do use the same drive and volume numbering. 19.37.31 # iirc drive numbers are stable -- dependent on number of hardware slots 19.37.46 # volume numbers get assigned dynamically 19.39.25 # <_bilgus_> the issue would be when you have both MULTIVOLUME and MULTIDRIVE 19.39.37 # <_bilgus_> if there are even any such IDK 19.39.47 # not in practice 19.40.21 # well technically MULTIDRIVE is also MULTIVOLUME but with NUM_VOLUMES_PER_DRIVE fixed to 1. 19.41.35 # using a (drive, partition number) pair should always be reliable I'd think 19.45.46 # <_bilgus_> or we just mount the drives and volumes unconditionally then check for validity after and unmount if they are not viable 19.46.46 # <_bilgus_> then the volumes are no longer so dynamic 19.52.17 # isn't that exactly like stuffing the partition number into the low bits? 19.52.51 # that might be viable as long as nothing cares that the valid volume numbers might not be contiguous. 19.54.50 # <_bilgus_> looking into it to try and see if it matters 19.58.40 *** Saving seen data "./dancer.seen" 19.59.10 # as for old bootloaders... i think ignoring boot_volume is the best option. 19.59.23 # either it's going to be 1 (sd card) or 0 (internal) 19.59.40 # the firmware can figure that out itself by scanning for redirect files 20.10.22 # <_bilgus_> I dont think we need to by marking the volume failed it grabs the next available volume instead and keeps inline with what the bootloader returns 20.12.14 # provided it fails the same way each time 20.15.01 # <_bilgus_> well no its still end up the same volume 20.15.21 # <_bilgus_> essentially it turns it into a bunch of removable drives 20.15.34 # <_bilgus_> it just doesn't happen to be mounted atm 20.17.30 # ??? mounting happens in disk_mount_all() 20.17.43 # so it does drive 0 then drive 1 20.17.59 # each drive mounts 0 or 1 volumes 20.18.09 # so if drive 0 fails then drive 1 becomes volume 0 20.19.09 # <_bilgus_> currently yes 20.19.37 # <_bilgus_> but if drive 0 fails and you eat the volume drive 1 becomes volume 1 20.19.47 # yes 20.20.27 # <_bilgus_> if drive 0 succeeds you fill the volume and drive 1 is still 1 20.21.14 # this is not any different than having partition numbers, only they are encoded into a single int. 20.22.42 # <_bilgus_> yes but it required one int and one if check 20.23.15 # why not just have a static assignment driveN partM = volume(N*4 + M) 20.24.28 # ignoring for the moment the annoying effect that'll have on path syntax... 20.26.03 # it's just making explicit what you want the loop to do 20.26.10 # <_bilgus_> essentially on the back end that already happening 20.27.55 # <_bilgus_> the place where it matters is probably the case of true multi volume 20.28.29 # <_bilgus_> in that case your way would be better since it would catch a failed volume and mine only catches a failed drive 20.29.33 # <_bilgus_> not that it can it just takes more logiv 20.29.37 # <_bilgus_> logic 20.30.03 # i'm pretty sure your way would have the same effect since drive mounting would have to scan all 4 partitions in a multi volume setup 20.30.28 # <_bilgus_> oh I have an idea 20.33.17 # to make path syntax sane we could break down the volume number as on multi-volume targets 20.33.44 # so volume 7 becomes <1p3> 20.34.08 # <_bilgus_> check that out g#4938 20.34.10 # 3Gerrit review #4938 at https://gerrit.rockbox.org/r/c/rockbox/+/4938 : 3[BugFix] root redirect failed to match the peoper drive when internal drive is missing by William Wilgus 20.34.31 # <_bilgus_> just mark them as used as soon as the are supplied 20.36.15 # <_bilgus_> ignore the improper spelling of proper 20.36.18 # yep that should work for non multivolume targets 20.38.26 # <_bilgus_> for multivolume I think we can just eat the rest up to the max count 20.38.34 # uh, scratch that, there's an unfortunate side effect in the loop. 20.38.50 # after mounting an fs it calls get_free_volume() again 20.39.02 # the last mounted fs will waste a volume. 20.40.48 # <_bilgus_> yep 20.52.49 # <_bilgus_> at the end it can just loop over the rest of the volumes and mark as used 20.52.52 # <_bilgus_> for (int i = mounted; i < NUM_VOLUMES_PER_DRIVE; i++) 20.52.52 # <_bilgus_> vol_drive[i] = -2; 20.53.41 # <_bilgus_> you could still get a case of a bad volume changing positions but idk that its possible to even detect that reliably 21.00.35 # i still think building the partition number into the volume number is the best option all around 21.00.51 # i'm pretty sure the only thing that would need to change is path formatting 21.03.55 # <_bilgus_> sounds like a can of worms 21.04.31 # <_bilgus_> I kinda prefer the whole single volume thing from a parsing stanpoint 21.05.54 # <_bilgus_> but it would make it less ambiguous then again windows is no different 21.06.27 # <_bilgus_> they just happen to use 'a' + vol 21.06.51 # <_bilgus_> suppose 'c' + vol 21.10.35 # <_bilgus_> IDK that its even worth the complexity its surely going to be a larger amount of code whats the upside 21.12.03 # <_bilgus_> as far as the multivol case you'd have to keep state to keep the ordering proper so I guess you could store an entry the first time you see it 21.14.50 # there are other quick'n'easy ways to fix multiboot since it has to deal with old bootloaders anyhow 21.16.38 # admittedly i don't see much use to having more predictable volume numbers beyond multiboot. 21.22.06 # less invasive would be to remember the partition number for each volume, like is already done with drive number 21.22.57 # then multiboot can have the bootloader pass it and the firmware can check it 21.23.47 # keeps the complexity contained to multiboot 21.32.26 Quit amachronic (Quit: amachronic) 21.47.40 # <_bilgus_> where would you store it then? 21.48.14 # <_bilgus_> or do you mean just in the math of num of volumes 21.58.41 *** Saving seen data "./dancer.seen" 22.14.09 Quit hexadecagram (Ping timeout: 260 seconds) 22.14.41 # <_bilgus_> machronic (logs) pretty sure this is the commit that broke this https://gerrit.rockbox.org/r/c/rockbox/+/2523 22.15.33 # <_bilgus_> just updating bootloaders would fix it AFAICT then again it would also make that broken device unable to boot 22.15.54 # <_bilgus_> * amachronic * 22.21.28 # <_bilgus_> hmm i'm not sure the best way to proceed on that note 22.22.08 # <_bilgus_> in theory it would still be ok since itd mount the sd card 22.22.48 # <_bilgus_> but it wouldn't be able to boot the internal as it is now 22.38.47 Join hexadecagram [0] (~acc@user/hexadecagram) 23.12.57 Quit kakaszsz (Ping timeout: 268 seconds) 23.24.49 Join kakaszsz [0] (~koniu@cpc107003-dals23-2-0-cust91.20-2.cable.virginm.net) 23.32.53 # Build Server message: 3New build round started. Revision f37ebe5ed2, 303 builds, 7 clients. 23.34.23 # <_bilgus_> ok that should fix the issue we will have to revisit this and come up with a more robust way to handle it there are still 3 chars left in the bootdata payload so we should be able to make it backwards compatible 23.37.16 Quit m01 (Quit: Konversation terminated.) 23.39.26 Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) 23.53.11 # Build Server message: 3Build round completed after 1219 seconds. 23.53.12 # Build Server message: 3Revision f37ebe5ed2 result: All green 23.58.43 *** Saving seen data "./dancer.seen" 23.58.44 Quit CH23_M (Remote host closed the connection) 23.58.59 Join CH23_M [0] (~CH23@revspace/participant/ch23)