| paculino | Is udhcpc hard to setup? I'm considering switching from isc-dhcp (after coming from network-manager and isc-dhcp) | 00:49 |
|---|---|---|
| paculino | (On devuan, not embedded) | 00:49 |
| gnarface | never tried it, and ditching network-manager is a sound decision on its own, but i recommend sticking with isc-dhcp-client since it's the reference one and the only one that hasn't caused me weird compatibility issues | 00:51 |
| gnarface | also, nothing else i've tried from busybox seems to be suited to real world use | 00:52 |
| paculino | I've seen some stuff about isc-dhcp being or nearing deprecation, which is part of why I ask. | 00:53 |
| paculino | I've never really used much busybox besides when recovering an old kubuntu(?) system | 00:54 |
| gnarface | i think according to ISC it's already past deprecation, but that's irrelevant to its support status in current devuan/debian stable | 00:54 |
| gnarface | basically ISC was just like "fuck you nobody's paying us for this shit, ingrates, so we're discontinuing it" (paraphrased) | 00:54 |
| gnarface | it's still the best one from a functional standpoint and the only problem i've noticed with it is that it takes marginally longer to complete handshakes than the competing offerings | 00:55 |
| gnarface | i would recommend you just stick with it until you actually have a real problem with it | 00:56 |
| rrq | I use udhcpc "everywhere" | 00:59 |
| rrq | and only ifupdown "everywhere" (+ wpa_supplicant) | 01:00 |
| gnarface | to be fair, i typically do everything with completely static configurations, and only use dhcp as a convenience for guests and a couple of my more esoteric mobile devices, so ymmv, but i would vouch for isc-dhcp-client and isc-dhcp-server both from at least a compatibility standpoint, if not necessarily a performance standpoint (which i don't really consider important in my use cases) | 01:11 |
| gnarface | i wouldn't characterize any of the dhcp clients or servers as "hard to setup" though... so it begs the question: Are you having problems setting it up? | 01:12 |
| gnarface | paculino: ^ | 01:13 |
| paculino | Sorry, I got distracted in another conversation | 01:14 |
| paculino | I haven't tried setting it up yet, but I want to get the dhcp client integrated with a custom awesome-wm widget, so want to be sure that I have the best option | 01:15 |
| paculino | So isc-dhcp is basically forked now? | 01:15 |
| gnarface | i'm not even sure you'd consider it forked, but regardless of what any upstream projects say about the status of their projects being discontinued, the version that was admitted to debian stable will stay there forever, as per debian policy | 01:16 |
| gnarface | for some future release, it might mean debian will have to remove it just to avoid the maintenance hassle if nobody wants to pick it up, but that still won't affect the versions in current and previous debian releases already | 01:17 |
| gnarface | and dhcp is kindof a solved problem already, so it seems likely it may remain simply because a high maintenance load isn't really required | 01:18 |
| gnarface | now, about customizations: i originally switched to isc-dhcp-client from the default of dhcpcd some releases ago myself because it was more extensible and i needed to extend the dhcp client we were using at the time for [reasons], so i would say it's the safest bet if you're making a custom widget too and that were a primary requirement for doing so... except that it seems to me if you're making a custom dhcp widget for | 01:20 |
| gnarface | awesome-wm wouldn't it be smartest to design it to be completely compatible with every dhcp client? maybe i don't understand the task at hand, but it seems to me like a dhcp widget should be easy to make dhcp-client-agnostic | 01:20 |
| gnarface | just a thought | 01:21 |
| gnarface | (it was during the aforementioned extension task that i discovered it was basically the "reference implementation" of dhcp and what ISC had to do with it, and stuck with it more on principle than anything else) | 01:22 |
| paculino | I've never done anything besides network-manager through widget and isc-dhcp-client through cli (nm widget to indicate only), so I'm not really sure | 01:23 |
| paculino | I guess playing nicely with wpa-supplicant and ifupdown is all that matters for making the widget | 01:24 |
| gnarface | afaik they should all do that fine | 01:24 |
| gnarface | it's more of a question of what happens when you need to start relying on optional parts of the DHCP spec that Microsoft just added so cable ISPs could use hostnames as a security feature | 01:25 |
| gnarface | i wouldn't think a desktop widget would need to care about such low-level implementation differences | 01:26 |
| gnarface | but, that said, i don't really know the specifics of what you want the widget to do other than show an on/off status, so if you run into trouble let me know and maybe i can help | 01:31 |
| paculino | Okay, thank you | 01:40 |
| plasma41 | ping dosensuppe | 20:53 |
| [NoClan]GoAway | hello good people. I'Ve ran into some "minor" problem trying to install Devuan from the netinstall iso that's available via the one of official sites/mirror. long story short, I can't install it because the installer is stuck at a "failed to mount the cdrom" error. keyboard's not working for the "emergency shell" that pops up... any suggestions or possible workarounds? | 21:01 |
| cousin_luigi | [NoClan]GoAway: Is it a very new device? | 21:07 |
| plasma41 | [NoClan]GoAway: Link to the netinstall iso you downloaded? | 21:07 |
| plasma41 | [NoClan]GoAway: Did you write the iso to a CD/DVD or did you copy it to a USB drive? What program or tool did you use to copy it to the installation media? | 21:09 |
| [NoClan]GoAway | @cousin_luigi, it's a rather old device I bought back in '14 (i7-4771, Gigabyte Mobo) | 21:10 |
| [NoClan]GoAway | @plasma41, link: https://mirror.leaseweb.com/devuan/devuan_daedalus/installer-iso/devuan_daedalus_5.0.1_amd64_netinstall.iso | 21:10 |
| [NoClan]GoAway | I used my other linux pc to get the iso pver to an USB stick using the dd command, prior to that I used my Ventoy stick, yet the message/error stays the same. | 21:11 |
| [NoClan]GoAway | *over to | 21:11 |
| plasma41 | The Devuan ISOs are incompatible with Ventoy | 21:12 |
| [NoClan]GoAway | using the Devuan Live CD from the Ventoy stick works (even installing a system over with the help of the Live CD, yet the bootloader is missing after the installation). | 21:12 |
| [NoClan]GoAway | @plasma41, hm... any reason why? | 21:12 |
| [NoClan]GoAway | because, the LiveCd seems to work | 21:12 |
| [NoClan]GoAway | in the past I tried several netinstall isos from testing to the late stable release, non had issues like this one. | 21:13 |
| plasma41 | I'm unclear on the technical details. rrq can explain it. (pings rrq) | 21:14 |
| [NoClan]GoAway | oh, I don't want to bother people unecessarily... | 21:14 |
| plasma41 | [NoClan]GoAway: Is the issue repeatable? | 21:15 |
| [NoClan]GoAway | it is. very. ;) | 21:15 |
| [NoClan]GoAway | fails every time | 21:15 |
| [NoClan]GoAway | can link a photo I made after uploading it somewhere. | 21:15 |
| [NoClan]GoAway | any picture upload sites prefered? | 21:16 |
| plasma41 | Hmm, let me see if I can replicate the issue on a spare computer. | 21:16 |
| plasma41 | https://transfer.rrq.au/ | 21:19 |
| gnarface | [NoClan]GoAway: are you getting that cdrom error halfway through the installer's setup questions, or are you getting it at the boot screen? | 21:22 |
| gnarface | and can you paste the exact dd command you used so we can sanity check it? | 21:22 |
| plasma41 | [NoClan]GoAway: It will be a few hours till I'll have an opportunity to do a test install of my own. Hang around in the channel and I'll let you know what I discover. | 21:23 |
| [NoClan]GoAway | @gnarface, I'm getting it after hitting the "install" button after booting the from the stick | 21:23 |
| [NoClan]GoAway | s/the/it | 21:24 |
| [NoClan]GoAway | @gnarface, I'll look up what command I used... just a second... | 21:26 |
| [NoClan]GoAway | dd if=/home/iso/devuan_daedalus_5.0.1_amd64_netinstall.iso bs=1M of=/dev/sdc && sync | 21:27 |
| [NoClan]GoAway | that's the one given as an example on the Devuan page. | 21:27 |
| [NoClan]GoAway | so I "blindly" used it after making the corrections suiting my needs (directory, stick etc.) | 21:29 |
| [NoClan]GoAway | worked the other times I needed the iso on the stick | 21:30 |
| [NoClan]GoAway | btw, the picture: https://transfer.rrq.au/ppWn0FvAVu/20250221_211733.jpg | 21:30 |
| [NoClan]GoAway | not sure if done correctly | 21:30 |
| plasma41 | [NoClan]GoAway: Got the picture | 21:33 |
| gnarface | [NoClan]GoAway: "bs=1M" sometimes corrupts writes, and for some machines you need "Legacy USB support" enabled in the BIOS or you don't have keyboard support until after the Linux kernel loads | 21:36 |
| gnarface | still not quite clear if those issues are relevant to your case though | 21:40 |
| plasma41 | Frankly, the advise to use dd is rather cargo-culty. 'cp /home/iso/devuan_daedalus_5.0.1_amd64_netinstall.iso /dev/sdc' works just as well. | 21:40 |
| gnarface | yea, that's true | 21:40 |
| [NoClan]GoAway | short question regarding the keyboard support: if it's working in the installer window where you choose the options, why isn't it a few seconds later? | 21:40 |
| plasma41 | afk | 21:41 |
| gnarface | [NoClan]GoAway: good question for sure... if you're seeing that failure after the bootloader, i don't know. (didn't actually look at your screenshot sorry, and your description of the timing was ambiguous) | 21:41 |
| gnarface | it's not a common issue though... | 21:42 |
| [NoClan]GoAway | well, I boot from the stick, get to the options menu,then I choose "install" and after that it hangs on that error.. | 21:42 |
| [NoClan]GoAway | that's the timeline of it. | 21:42 |
| gnarface | did you get past the network setup? | 21:42 |
| [NoClan]GoAway | nope. not even close to that. | 21:43 |
| gnarface | so this is the "install" option at the top of the install disk's boot menu, not the "install" option that's the final step of the setup? | 21:43 |
| [NoClan]GoAway | I could try an older 4.0 iso I still have as that worked well last time. yet I don't want to go through the whole upgrade process if a 5.0.x version is available | 21:43 |
| [NoClan]GoAway | yup, the first "install" option. | 21:44 |
| gnarface | well, i'm fairly certain you shouldn't be having this problem with 5.0 still, but if you proceed with a minimal install you should only need to do about 500-600MB of redundant downloading when you upgrade it | 21:44 |
| [NoClan]GoAway | reading about that error I find pages telling me that was an issue years ago already, that's why I'm a bit puzzled that's still an issue. | 21:44 |
| gnarface | well the thing is, we've seen the cdrom thing come up there for various reasons, usually to do with improper writing or booting | 21:45 |
| gnarface | whereas the same cdrom error later might be caused by having no network setup | 21:46 |
| gnarface | ...because then it will put a path to the cdrom in your sources.list and expect the installer to still be there, but then not find it if you used a USB drive or ejected it | 21:46 |
| [NoClan]GoAway | funny things... | 21:46 |
| [NoClan]GoAway | and there one might think computers work in a predictable fashion :) | 21:47 |
| gnarface | well they usually do but there's still enough variables to make it look random | 21:47 |
| gnarface | only things i can suggest at this point is to checksum the iso file then checksum the drive you wrote it too afterwards, to make sure it didn't get corrupted | 21:48 |
| gnarface | then just try the write again without bs, or with bs specified to match the physical block size of your USB media | 21:49 |
| gnarface | you are booting from USB not optical here, right? | 21:49 |
| [NoClan]GoAway | usb, yes. | 21:49 |
| [NoClan]GoAway | optical's not wired currently as I ran out of sata ports on that port ^^ | 21:50 |
| [NoClan]GoAway | *board | 21:50 |
| [NoClan]GoAway | is it somehow strange that "iso9660" is appearing when looking at the partitions created on the stick, i.e. mounting for looking what's on them? | 22:02 |
| [NoClan]GoAway | as I understand it, it related to cdroms | 22:02 |
| [NoClan]GoAway | *it's | 22:02 |
| gnarface | no, it's not strange for these images, they're something called "hybrid-iso" which is setup so that it can work as is when booted from either USB flash or optical media | 22:04 |
| gnarface | and the debian images have been that way since even before devuan existed | 22:05 |
| plasma41 | [NoClan]GoAway: What's the precise model of the motherboard? | 22:05 |
| [NoClan]GoAway | uh oh... just a sec.. need to look that one up... | 22:05 |
| [NoClan]GoAway | it's a Z87X-UD5H from Gigabyte | 22:06 |
| plasma41 | [NoClan]GoAway: thanks | 22:07 |
| [NoClan]GoAway | I have to thank you guys for helping. | 22:08 |
| plasma41 | :-) | 22:11 |
| [NoClan]GoAway | while we're at it, just a "minor" question in regards to Devuan: I noticed while using it the my block devices (read: hard drives) are in "random" order when doing a lsblk and the order is ever changing with the reboots (done so on other DEvuan installs in the past or, respectively, a previous testing version still on another one of my partitions). is there a reason for doing so or a way to revert back to the "usual" way of recognizing drives? | 22:12 |
| gnarface | [NoClan]GoAway: no, it's because of a low-level change to the kernel logic some 15 or so years ago. you're recommended to just use the UUIDs instead, because they won't change between reboots | 22:13 |
| gnarface | this is also not devuan specific | 22:14 |
| gnarface | (you can use disk labels you set too, but they'll already be assigned UUIDs by default whether you use them or not) | 22:15 |
| Darthix | I just installed Devuan on two machines, both with XFS and the OS does not install xfsprogs automatically, yet it tries to use those tool during boot to fsck | 22:16 |
| plasma41 | AIUI, the device assignments (/dev/sda, /dev/sdb, /dev/sdc, etc.) are created in whatever order the kernel detects the devices at boot. | 22:16 |
| Darthix | no problem to install xfsprogs manually after OS install, it just feels like a missed opportunity for the OS to do it on its own | 22:16 |
| gnarface | Darthix: the netinstall is based on Debian's, so this is their fault | 22:17 |
| Darthix | ok | 22:17 |
| gnarface | plasma41: yes, AIUI, the relevant change to the kernel was just that they removed some unreliable heuristics they'd been using previously to attempt to create a predictable drive ordering, as newer hardware became more divergent | 22:19 |
| dosensuppe | plasma41: I'm on devuan daedalus stable | 22:33 |
| plasma41 | dosensuppe: Ok, you should be able to compile a snapper backport package with [this](https://paste.debian.net/1352889/) patch applied after the #976888 patchset. | 22:37 |
| [NoClan]GoAway | thanks again for helping and answering the questions. | 22:40 |
| [NoClan]GoAway | btw, I used the above recommendation of "cp /home/to/iso /dev/stick" and booted from that... | 22:41 |
| [NoClan]GoAway | got only two lines of error this time around and after that a number of "506xxx blocks" blocks shown and after that it went through to the installer | 22:42 |
| plasma41 | [NoClan]GoAway: :-/ Do you get the same issues with a different USB drive? | 22:43 |
| gnarface | wait, but it's working now right? | 22:43 |
| [NoClan]GoAway | minor caveat: after being done with the installing of the system, the installer tries set the GRUB entries to the drive I had assigned. turns out it's not doing that pretty well. GRUB only worked after using the "rescue mode" from the boot stick and re-installing GRUB again to said drive. | 22:43 |
| gnarface | hmmm | 22:44 |
| [NoClan]GoAway | @plasma41, I didn't use a different stick, it's the same one. | 22:44 |
| gnarface | well the important part is you managed to get it installed | 22:44 |
| [NoClan]GoAway | @gnarface, yes, now it did install the system. | 22:44 |
| [NoClan]GoAway | but I find it strange that the "dd" part worked well for the past years and now it's not so much. | 22:45 |
| [NoClan]GoAway | as it got mentioned above, the Devuan iso's aren't well suited for Ventoy... | 22:45 |
| gnarface | so far this all supports my hypothesis that "bs=1M" was corrupting your write. i'm not sure exactly why some flash media hates high block sizes and some doesn't, but it seems particular to just certain combinations of flash media and byte sequences above a certain threshold of bs size | 22:45 |
| [NoClan]GoAway | is that specific to a certain version? | 22:45 |
| [NoClan]GoAway | as the LiveCD is working quite well... | 22:46 |
| [NoClan]GoAway | @gnarface: I did use different block sizes in the dd command, even did it withput the option bs= | 22:46 |
| [NoClan]GoAway | it resulted in the same errors. | 22:46 |
| gnarface | the netinstall is based on Debian's and designed to be as much like it as possible, and being very archaic just does some things Ventoy isn't compatible with. the live isos on the other hand are based on refracta, and both them and refracta are maintained here by fsmithred, who has responded specifically to complaints about compatibility with ventoy | 22:47 |
| [NoClan]GoAway | out of curiousity I did the "cp" thing and tried that, after seeing two lines of error I thought, well, it's the same... | 22:47 |
| rrq | ventoy doesn't offer the media as partition; it loads kernel and initrd from iso files only, then the iso is present (hidden) as a file in a partition | 22:47 |
| [NoClan]GoAway | @rrq, makes sense. any explanation why the netinstall one fails while the other one works? | 22:48 |
| [NoClan]GoAway | just trying to make sense of it... | 22:48 |
| gnarface | [NoClan]GoAway: it's not really important at this point, but if you say default bs still didn't work, and you're sure you still ran "sync" after that attempt, i'd be curious to see what the physical block size on that flash drive is | 22:49 |
| [NoClan]GoAway | @gnarface: coming back to the order of drives, in the installer it still uses the "old style" sorting without uuid's | 22:49 |
| rrq | not sure exactly; netinstall was built as a two phase thing (due to reasons) and the first stage only includes drive modules; it lacks many usb modules | 22:50 |
| gnarface | [NoClan]GoAway: yea the UUIDs don't get assigned until after you've formatted the partitions. then they won't change unless you resize or reformat the partition | 22:51 |
| rrq | there is a possible workaround if you can place the iso as a partition on the harddisk | 22:51 |
| gnarface | ... i think, did i once see maybe a UUID change just repairing a partition with fsck too? not sure, might be remembering that wrong... | 22:52 |
| [NoClan]GoAway | might try to do that on the ventoy stick. | 22:52 |
| rrq | you may then install over that (once the second stage is started it has all modules) | 22:52 |
| rrq | ventoy still won't work, because the second stage also needs the media as partition | 22:52 |
| [NoClan]GoAway | seems there's a horde of things to consider... | 22:53 |
| gnarface | you get used to it | 22:53 |
| [NoClan]GoAway | sorry, still need to come back to that non-Devuan specific issue of drive oders if time allows... | 22:54 |
| [NoClan]GoAway | how is it that it's still "old fashioned" on some other, quite recent Linux distros? | 22:54 |
| rrq | most installers where designed before extfat was a thing | 22:56 |
| gnarface | not sure what you mean. if they're not using UUIDs then they're either using "disk labels" or their drives just come up in unpredictable orders. you're saying you've seen predictable drive orderings with just the bare /dev/sd* names? | 22:56 |
| [NoClan]GoAway | hm...no, the drive orders on those distros get shown in the regular fashion, i.e. sda first, then sdb, then sdc and they stay the same across reboots | 22:57 |
| gnarface | keep in mind that stuff like USB drives will always come up after IDE/SATA/SCSI | 22:57 |
| [NoClan]GoAway | @rrq, thanks :) | 22:57 |
| [NoClan]GoAway | @gnarface, yeah, I noticed that over the years, and there's no problem with that. I just can't get used to the ever-changing order of drives... | 22:58 |
| [NoClan]GoAway | and yes, times call for UUID's | 22:58 |
| rrq | the drive adapters names the drives as fast as it can so they will be named in the order the "spin up" .. everyone laves random boot up | 22:59 |
| [NoClan]GoAway | I just imagined there'd be a way to revert back to the old model | 22:59 |
| gnarface | you'd need a really old kernel, something from before 3.x i think, and it's not clear the predictable ordering logic they had back then would even work on your more modern rig... AIUI they had removed this back then because they couldn't make it work reliably on all newer hardware anyway | 23:00 |
| gnarface | so probably what you'd need is some 2.x kernel and a motherboard with only PATA drives | 23:01 |
| gnarface | ... a motherboard with only PATA drives and not a Dell BIOS | 23:01 |
| [NoClan]GoAway | I get that, but why is it different on other distros and why don't all use the same when using the up-to-date kernels? | 23:01 |
| gnarface | sorry, that's the part of your statement i simply don't actually believe | 23:02 |
| gnarface | unless it could be explainable by having a string of very different-speed drives that just happen to POST up in a predictable order where there's no possible race condition | 23:03 |
| [NoClan]GoAway | when I boot my Nobara system, the drives are in the regular order. when I use the current Devuan, it's as you said. | 23:03 |
| gnarface | (like for example one SATA drive and one USB drive) | 23:03 |
| gnarface | Nobara? haven't even heard of it... | 23:03 |
| [NoClan]GoAway | think it's based on Fedora. | 23:03 |
| [NoClan]GoAway | maintained by GloriousEggroll as it's a Linux made for gaming (yeah, sorry, bad hobby ;) | 23:04 |
| gnarface | hmm, well it's possible they resurrected some heuristics and put them in a custom kernel, but i suspect you've got a false positive that could be explained by more thorough testing | 23:04 |
| rrq | well one may have software renaming devices based on any distinctive properties the individual devices might have | 23:04 |
| gnarface | custom udev rules that sort drives by product id or something? | 23:05 |
| gnarface | seems possible in theory, just not something i've ever heard anyone mention anyone doing up till now | 23:05 |
| rrq | or pci address, if that's persistent | 23:06 |
| [NoClan]GoAway | circling back to the GRUB issue, any ideas why it's not installing properly on the first attempt and only works after using the rescue mode from the netinstall stick writing it the second time? | 23:06 |
| [NoClan]GoAway | regarding the drives, can't one sort it by controller numbers or assigned device id's? | 23:06 |
| gnarface | usually means you pointed it at the wrong drive or partition, though i've seen this caused sometimes by badly behaved bios that changes the drive letting on the fly during boot (*cough* Dell *cough*) | 23:07 |
| rrq | the grub installer gets fooled by the presence of an EFI partition | 23:07 |
| gnarface | oh, or that | 23:07 |
| [NoClan]GoAway | well, there's only the one EFI partition, and that's the one on the stick. every other drive I have in that rig hassn't seen a EFI partition. | 23:07 |
| rrq | yes, that's enough to fool grub | 23:08 |
| [NoClan]GoAway | hm.. | 23:08 |
| [NoClan]GoAway | if that's a known issue, will there be a change some day so it's not happening? | 23:08 |
| [NoClan]GoAway | sadly I didn't shoot a picture of that error. but it mentioned something like "i386" and "module" not found and entered the GRUB console. | 23:10 |
| gnarface | if Debian fixes it upstream, our netinstallers will inherit the change... | 23:11 |
| [NoClan]GoAway | when installing different Devuan versions I ran into the same problem, I only mitigated it by moving /boot to a stick and to boot off of it | 23:11 |
| gnarface | you can just sanity check the default grub suggestion and point it to the right drive at that stage though, can't you? | 23:12 |
| rrq | you'll need to install grub-pc by hand | 23:12 |
| [NoClan]GoAway | well, it's going for quite while. the first one I encountered this was 4.0 and it carried over to 5.0 testing and not the stable 5.0 branch | 23:12 |
| [NoClan]GoAway | i can can point it to the right drive, as I always do. I just tried the rescue mode today, didn't actually think it would fix it. | 23:13 |
| [NoClan]GoAway | "not the stable 5.0 branch" .. sorry, meant "now the stable 6.0 branch" | 23:14 |
| [NoClan]GoAway | argh ... 5.0 | 23:14 |
| rrq | that's not enough no; that only directs grub installer which disk/partition to use | 23:14 |
| [NoClan]GoAway | to install it by hand I'd need to access the system I freshly installed, wouldn't I? | 23:15 |
| rrq | it still believes the system is EFI due to seeing an EFI partition (whether mounted or not) ... I'm not sure about the full logic | 23:15 |
| [NoClan]GoAway | seems the more modern EFI is causing problems compared to the "older" regular BIOS | 23:15 |
| rrq | the installer needs to have an EFI partition so that it also can be used installing on an EFI system | 23:15 |
| [NoClan]GoAway | seems reasonable. | 23:16 |
| rrq | and maybe grub dev's all have EFI systems or something so they can't see the issue... "all modern systems have EFI" | 23:18 |
| [NoClan]GoAway | seems they do ^^ | 23:19 |
| [NoClan]GoAway | don't want to know into which problems I run when upgrading my system to a more recent one... | 23:19 |
| rrq | usrmerge probably :) | 23:21 |
| fsmithred | mini.iso might work if netinstall is still failing. Another possibility is to boot the live and either install that or use it to do a debootstrap install. | 23:22 |
| [NoClan]GoAway | I tried installing via the LiveCD, worked for installing, failed at creating GRUB. | 23:23 |
| fsmithred | yeah, I get that with both live and netinstaller, but not all the time | 23:24 |
| [NoClan]GoAway | I wonder why those problems creep up. remembering back to 2011 when I installed Debian (still systemd-less back then) Squeeze, I never ran into problems of that sort... | 23:26 |
| fsmithred | https://pkgmaster.devuan.org/devuan/dists/stable/main/installer-amd64/current/images/netboot/mini.iso | 23:28 |
| [NoClan]GoAway | I'll give that one try. | 23:30 |
| [NoClan]GoAway | side note (yeah, the now stale topic of drive orders): looking up using lsblk, my drives are in the right order as I know them. using the other 5.0 testing system, it looks different. | 23:31 |
| [NoClan]GoAway | I'll reboot and check if it stays that way. | 23:31 |
| [NoClan]GoAway | brb. | 23:31 |
| rrq | note that mini.iso sports an EFI partition as well | 23:32 |
| [NoClan]GoAway | drive order changed. | 23:34 |
| [NoClan]GoAway | strange. | 23:34 |
| rrq | usb drives spin up rather randomly | 23:36 |
| [NoClan]GoAway | there's non attached at the moment | 23:37 |
| [NoClan]GoAway | only a USB-MO drive. it mostly is the last one assigned by the old assigning-scheme from back in the days. | 23:38 |
| rrq | which drive type(s) get reordered | 23:39 |
| [NoClan]GoAway | pretty much all of them. before rebooting, they were in the (right) order, read: as they are attached to the sata-ports, the MO drive being the last one as it's connected via USB | 23:40 |
| [NoClan]GoAway | so I have 3 ssd's, one old hdd and that MO | 23:40 |
| plasma41 | MO? | 23:41 |
| [NoClan]GoAway | MagneticOptical | 23:41 |
| [NoClan]GoAway | Fujitsu and one or two other companies made those. | 23:42 |
| [NoClan]GoAway | are rather rare means of storing data, but rather persistent | 23:42 |
| plasma41 | Is that like an IOmega Zip drive? | 23:42 |
| [NoClan]GoAway | as it heats the disk and then writes the data by altering it via using magnetic stuff on the disk surface... like hard drives of the olden days, only more durable. | 23:43 |
| [NoClan]GoAway | the IOmega is like a floppy, the MO is like a HDD that gets heated and then cools and keeps it's magnetic info in that spot. | 23:44 |
| gnarface | plasma41: those were just regular magnetic. i think these are something more like minidisk | 23:44 |
| [NoClan]GoAway | what he said :) | 23:44 |
| gnarface | https://en.wikipedia.org/wiki/MiniDisc | 23:44 |
| [NoClan]GoAway | sorry, can't link the wiki page, there's no browser... | 23:44 |
| [NoClan]GoAway | thanks, gnarface | 23:45 |
| gnarface | [NoClan]GoAway: when they come up in a different order, is it actually randomized, or is it really just changing from one predictable state to another different, but still predictable state? | 23:46 |
| gnarface | because i've seen both situations happen, and i want to make sure we're not confusing one for the other | 23:47 |
| [NoClan]GoAway | @gnarface: it's rather unpredictable from what I have observed over the years. sure, with jut 5 drives, the same order comes up no and then, but mostly it's not in the old-fashioned order. | 23:49 |
| plasma41 | Apparently I got Zip disks mixed up with LS-120 disks | 23:49 |
| [NoClan]GoAway | well, the 120MB zip's weren't a bad invention back in the day. sadly, most friends didn't have the drives so giving them the disk wasn't an option to transfer data... | 23:50 |
| [NoClan]GoAway | https://en.wikipedia.org/wiki/Magneto-optical_drive | 23:55 |
| [NoClan]GoAway | btw, the link for the MO drive | 23:55 |
| [NoClan]GoAway | capacities were rather limited by today's standards, yet it's still usable for documents you need to keep safe for a prolonged period of time. | 23:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
