| ted-ious | Oh that's interesting. | 00:05 |
|---|---|---|
| ted-ious | I missed that while reading back. | 00:05 |
| rrq | anyone using QTerminal? and knows how to make BlackOnWhite be "on white" rather than "on gray"? | 00:06 |
| ted-ious | Is that a kde terminal? | 00:07 |
| rrq | it's the default of lxqt | 00:08 |
| gnarface | rrq: you could check to see if it obeys ~/.Xdefaults or ~/.Xresources | 00:20 |
| ted-ious | Oh I thought it was called lxterminal. | 00:21 |
| ted-ious | I guess they updated while I wasn't looking. :) | 00:21 |
| systemdlete | Problem was PEBKAC | 02:19 |
| systemdlete | I didn't stop to think that running badblocks on ANY disk--new or used--might just corrupt the MBR. | 02:19 |
| systemdlete | My bad. Totally. | 02:19 |
| gnarface | well it depends on the flags you used | 02:20 |
| systemdlete | However, I find it a bit inconsistent (as did some others here) that utilities could not find the table even though the kernel outsmarted them | 02:20 |
| systemdlete | gnarface, the purpose of the test was to ensure that the disks would work for at least a while before having to send them back. I was getting bad disks for a while, and by the time they went T.U., they were out of whatever warranty I might have had. | 02:21 |
| systemdlete | So I preferred to thoroughly torture the things. | 02:21 |
| systemdlete | Nowadays, whenever I receive *any* kind of disk, memory chip, mainboard, component, or other device, I immediately subject it to torture for about 3 days. | 02:22 |
| gnarface | yea, i understand that, but what i'm saying is badblocks shouldn't be inherently destructive, unless you picked the destructive options... if you didn't, this is strong evidence you actually might have found what you're looking for: defective hardware | 02:22 |
| systemdlete | hmmm. badblocks did not report any errors. If it had, that disk would have been on its way back to the vendor long ago. | 02:23 |
| systemdlete | I get what you are saying, and I think you might be right. | 02:23 |
| systemdlete | This was on two different disks! | 02:23 |
| gnarface | well, which badblocks options did you use specifically? i can sanity check them for you | 02:23 |
| systemdlete | -w and another... | 02:24 |
| gnarface | oh | 02:24 |
| gnarface | yea, well that's the destructive mode, that'll definitely corrupt everything | 02:24 |
| systemdlete | right. And since they were new and I had not put anything on them (even an OS) yet, it seems the perfect test. | 02:25 |
| gnarface | and that fdisk doesn't recognize archaeological traces of shredded partitions as partitions even when Linux does isn't such a super big mystery. fdisk is actually older than Linux so it's believable it would have more sanity checks built in | 02:25 |
| systemdlete | somehow, the kernel sniffed out the fact there were 4 entries in the mbr. But the utilities' noses must have been stuffed up or something. | 02:26 |
| gnarface | nah, i think it's the other way around | 02:26 |
| systemdlete | gnarface, we tried with sfdisk, cfdisk, gdisk, and blkid | 02:26 |
| systemdlete | same errors. | 02:26 |
| systemdlete | what? | 02:26 |
| gnarface | yea, i think the utilities were bullet-proof and the kernel is the one that's janky | 02:26 |
| systemdlete | oh just great | 02:26 |
| systemdlete | (if so) | 02:26 |
| systemdlete | I think I'd rather have janky utils than a janky kernel. | 02:27 |
| gnarface | eh, maybe completely explainable if you look at the MSDOS partition format at the raw hex level | 02:27 |
| systemdlete | I have! | 02:27 |
| gnarface | maybe 4 partitions is 0xFF | 02:27 |
| gnarface | looking at the test data badblocks outputs, it seems plausible | 02:28 |
| systemdlete | sure, so can't fdisk read? | 02:28 |
| gnarface | fdisk probably does several other checks to see if it's a valid partition table | 02:28 |
| gnarface | same with the others | 02:28 |
| systemdlete | and you are saying the kernel does not. | 02:28 |
| systemdlete | meh | 02:28 |
| gnarface | heh, yea | 02:28 |
| systemdlete | yipes. | 02:28 |
| gnarface | :-/ | 02:28 |
| systemdlete | That's sort of... uhm. How does one say it? Important? | 02:29 |
| gnarface | maybe so | 02:29 |
| systemdlete | But I take full responsibility for the noise. Or, perhaps I should say "fool responsibility" | 02:29 |
| gnarface | when you've excluded the impossible and the absurd then what you have left is the truth | 02:29 |
| systemdlete | Yes watson | 02:30 |
| gnarface | all evidence points to that the kernel doesn't check very carefully what is a partition and what is just badblocks test patterns | 02:30 |
| systemdlete | well, it would have no way to really test the latter, other than by elimination | 02:30 |
| gnarface | now, if you were to see this same behavior with -n instead of -w i would worry about the hardware | 02:31 |
| gnarface | but it sounds like it's just Linux | 02:31 |
| gnarface | and not the first time i've caught it doing something weird | 02:32 |
| gnarface | (try changing a drive from windows 7 to GPT then to MSDOS without zeroing the first few megabytes of the drive inbetween steps) | 02:33 |
| gnarface | yea, i've seen ample evidence to suggest that the lowest-level components of the system are shitty at sanity checking partition table anomalies | 02:34 |
| gnarface | so the idea that "badblocks scans for bad blocks by writing some patterns (0xaa, 0x55, 0xff, 0x00)" might look enough like the crude skeletal remains of a MSDOS partition table to the kernel in some cases, completely believable | 02:36 |
| gnarface | it's probably not checking the whole data structure, it's probably just fast-checking for some certain key start bytes | 02:37 |
| gnarface | something that just happens to match 0xaa, 0x55, 0xff, 0x00 too | 02:38 |
| blockhead | of possibe interest? https://wiki.osdev.org/MBR_(x86) | 02:40 |
| gnarface | systemdlete: i would have mentioned all that earlier but i had assumed by context you had meant you'd done badblocks -n not -w | 02:41 |
| systemdlete | gnarface, my first task in my first programming job was to maintain and extend the partitioning tool for a PC OS | 02:41 |
| gnarface | blockhead: ah, yes, probably. good find. | 02:41 |
| systemdlete | So I know all about 0x55AA | 02:42 |
| systemdlete | (or whatever the heck it is) | 02:42 |
| systemdlete | would have been smarter to make that an actual checksum of some sort, but that would have been smarter. Which DOS was not known for | 02:42 |
| systemdlete | just fyi, gnarface, I agree with everything you are saying | 02:43 |
| systemdlete | And it was, indeed, -w, not -n | 02:43 |
| systemdlete | My intention was to force bad bits to show themselves | 02:43 |
| systemdlete | I wanted to be as tough and thorough as possible. | 02:43 |
| gnarface | that's certainly the way to do it | 02:43 |
| gnarface | but you possibly might want to consider zeroing the whole disk as a final step to that process | 02:44 |
| systemdlete | I guess submitting this for a fix would be pointless? | 02:44 |
| gnarface | truthfully i'm not sure. it does seem like there could be a theoretical security implication here, but i'm not sure drive mounts are expected to be binary-safe or whatever you'd call it | 02:45 |
| systemdlete | yeah, that can be done with badblocks. I'll keep it in mind goiong forward. Thing is, though, I still have about a half dozen disks that have already been subjected to this procedure, and I am not too "up" for redoing them... although, it would not be that difficult. I mean, I do have hotswap bays on all my PCs... | 02:45 |
| gnarface | eh, you can probably zero them faster with dd | 02:46 |
| systemdlete | ah, sure. | 02:46 |
| gnarface | actually if they're SSD they might even have a super-fast built-in zeroing feature in the firmware, but i've yet to actually try any of those where i've seen the feature advertised | 02:47 |
| gnarface | ... so i'm not sure exactly how you'd trigger it from linux | 02:47 |
| gnarface | i know you can use hdparm to check for the existence of such a feature but not sure what you'd use to trigger it | 02:49 |
| systemdlete | no not ssd | 02:57 |
| systemdlete | old fashioned 2TB drives | 02:57 |
| gnarface | hmm, well, worth checking though i'm not sure if those would have it or not, i had thought it was something new with flash media | 02:58 |
| rrq | systemdlete: the internet does have stories about "phantom partitions" but all seeems to try to fix them rather than analyzing why/how they come up | 03:47 |
| rrq | so far I haven't find a way to replicate it | 03:48 |
| leitz | Anyone have an idea how to fix Grub "no such partition" from using Expert install on 5.0.1 (amd64)? Totally new install, and I just tried to do a rescue mode boot and reinstall grub on /dev/sda. | 16:30 |
| mason | leitz: If you're using rescue mode, the pattern I like is to mount your system into /mnt or similar, mount --rbind /dev /mnt/dev and the same for /sys and /proc, chroot in, and you should be able to update or reinstall grub a couple ways, the best place to start potentially being dpkg-reconfigure grub-pc (or grub-efi-amd64 if you're on UEFI) | 17:49 |
| rwp | leitz, If you used Expert mode and partitioned it yourself is it possible you used GPT and UEFI and did not create a ESP EFI-System-Partition and that is what is not being found? | 18:53 |
| leitz | Not sure. I just retried with a normal install, and am getting the same issue. | 19:07 |
| rwp | During the installation there will be a dialog to ask what partition to install grub in and one must make a selection (usually /dev/sda) but at that point it should either work or fail. | 19:10 |
| rwp | Here is a screenshot, page down to step 21 bootloader location, https://www.devuan.org/os/documentation/install-guides/daedalus/install-devuan | 19:11 |
| leitz | I'm going back through the install. The box has multiple disks, but I'm trying to do everything on /dev/sda. Maybe it installed grub on another disk? | 19:14 |
| rwp | It should only install upon the disk manually selected at that step. But... Stuff happens so maybe the BIOS is booting off a different disk? | 19:16 |
| rwp | When I am doing installs on machines with multiple disks I unplug the disks I don't want touched as a first step. Then there is only one disk. And it boots off that one disk. | 19:16 |
| rwp | Almost certainly the BIOS is selecting one of the other disks to boot from and in that case either the cables need to be swapped until it boots off the disk you want or you need to install the bootloader on the other disk that is booting. | 19:17 |
| rwp | If the other disk is another OS then of course that will overwrite that other OS boot loader. That's why for me I would unplug those other disks. | 19:18 |
| golinux | I have done that several times. Makes things less confusing . . . | 19:21 |
| DelTomix | hello leitz ! what type of a partition layout are you using? is it GPT? and are you using a separated /boot partition? | 19:23 |
| leitz | It took doing a "one big partition" install to work, but it finally worked. I'm going to go back and re-install, and see if the other methods pick up the right disk to install on. | 19:35 |
| leitz | But yes, the original expert install was gpt with a separate /boot. | 19:35 |
| DelTomix | ah thats likely where you need to choose it as the place to install grub. | 19:36 |
| DelTomix | so like if /boot was /sda2 for example | 19:37 |
| fsmithred | is it uefi or legacy bios? And is it still gpt? | 19:37 |
| fsmithred | I'm too sick to wait for an answer. uefi needs an efi partition (not the /boot partition) and gpt with bios needs bios_grub partition (1MB without file system) | 19:39 |
| DelTomix | thanks fsmithred hope you feel better | 19:40 |
| DelTomix | I thought the installer would have made those. | 19:41 |
| leitz | Hope you feel better, fsmithred! | 19:42 |
| leitz | And I made /boot the first partition. Not sure if the system is using uefi or not, how would I tell? | 19:42 |
| leitz | Can you tell /me is of an older sysadmin generation? :) | 19:43 |
| fsmithred | ls /sys/firmware/efi - if it's there it's uefi boot | 19:43 |
| fsmithred | thanks. back to bed | 19:44 |
| leitz | Thanks fsmithred! It is *not* there. | 19:44 |
| rwp | DelTomix, The installer in Expert mode does exactly what you tell it, so not having the right partition setup is a typical error. But in normal install it should Do The Right Thing itself. | 20:00 |
| rwp | leitz, If /sys/firmware/efi is not there then you are booting in either Legacy BIOS mode or CSM (Compatibility Service Module?) which is the same thing. Which actually is simpler and easier to debug. | 20:01 |
| rwp | In which case you will end up with grub-pc installed (instead of grub-efi-amd64) and then we would just need to know the partition type used. | 20:02 |
| rwp | If using MBR then grub steals empty space from between the MBR partition table and the first partition. If GPT then a bios_boot partition is needed to hold the bootloader. | 20:04 |
| rwp | Legacy BIOS with MBR is the most recent traditional method. | 20:04 |
| DelTomix | rwp: been a while since I've done it with stock installer - my recollection was that in expert mode it still had the option for "guilded" partitioning which had some template layouts - I need to get around to really run through some actual installs and update myself. | 20:21 |
| n4dir | as far i remember the expert install method was very close to the usual installer, but you were asked way more questions. But nothing was missing you had on the "usual" installer | 20:22 |
| fsmithred | yes, you get the same partitioning choices in regular or expert. | 20:22 |
| n4dir | many used it, probably as it sounded cool to say you use expert, but did it just the usual way. For a while | 20:23 |
| leitz | Ah, "guided with separate home, tmp, and var" doesn't create a /boot partition. | 20:23 |
| n4dir | fsmithred: in and out of bed, huh? Best wishes to get better soon | 20:23 |
| fsmithred | thanks. | 20:24 |
| leitz | Hmm, can't create an LVM based disk? | 20:27 |
| leitz | Ah, I see it. I think. | 20:28 |
| DelTomix | omg s/guilded/guided I seem to be making the most idiotic typos lately | 20:29 |
| leitz | DelTomix, when I'm tired I'll mis-type my own name... | 20:31 |
| DelTomix | :) second language | 20:31 |
| leitz | I'm enjoying the "Continue the install via ssh" option. | 20:33 |
| rwp | I have definitely helped people who used the Expert install but did not create the required partitions before. So that is what I am remembering. | 20:52 |
| rwp | For the normal install there is a screenshot walkthrough of every dialog here https://www.devuan.org/os/documentation/install-guides/daedalus/install-devuan | 20:53 |
| rwp | Meanwhile myself I don't like the default choices and so I almost always make custom partition choices. | 20:53 |
| rwp | I always make a /boot because it's insignificant in size and is most flexible. But I think the installer has stopped requiring it now that grub has support for all of the default file systems now. | 20:54 |
| rwp | leitz, The installer is a little confusing in that it won't show LVM options until there is at least one partition marked as an LVM PV partition. But then as soon as one is set to a PV type then the LVM options appear. | 20:55 |
| rwp | Same thing with raid setup. The installer doesn't show the options to set up raid unless there is at least one partition marked for raid. | 20:57 |
| rwp | The installer is a bottom-up thinker and needs to build from the foundation up. As opposed to being goal oriented starting at the top and filling in the dependencies below. | 21:00 |
| onefang | "gpt with bios needs bios_grub partition" is that needed if you are not using grub? I'm having trouble getting qemu to find the boot stuff in UEFI mode on a GPT partitioned qcow2 image using syslinux and friends. | 21:05 |
| rwp | I don't know. | 21:09 |
| rwp | I don't happen to have any VMs running that use UEFI. I'll build one and see what GPT partitions are created. | 21:11 |
| rwp | These are the defaults for a normal UEFI install: https://www.proulx.com/tmp/Screenshot_devuanuefi1_partition_defaults.png | 21:26 |
| rwp | And I see that the installer has changed. It shows options for both software raid and lvm without having any partitions marked as such now. That's new. | 21:26 |
| rwp | Exploring the selections of Sofware Raid and LVM though if you don't know you need partitions of the right type and don't create them then you end up looking at a dialog asking you to select a partition and of course no partitions of the right type are available. | 21:34 |
| rwp | Which might be better due to letting the user know that way what is needed rather than not showing anything about RAID or LVM. | 21:34 |
| leitz | Okay, so, nope. Expert mode seems to have not installed grub on /dev/sda, even though the drive model was the same. | 21:41 |
| leitz | I had /boot, swap, and then a PV for the lvms, in that order. I verified that each time it was /dev/sda, and only sda. | 21:43 |
| rwp | You unplugged the other drives? | 21:43 |
| rwp | Assuming that multiple drives exist then try booting and at the BIOS screen hit the key to select the boot device. Then manually select the drive you want to boot from. | 21:45 |
| rwp | It's a tragedy but BIOS device order is almost never the same as Linux kernel device order. | 21:46 |
| leitz | If i have to unplug the drives, it's a loss. When I did the "one big thing" install, it worked, and survived reboots. The disk used as sda has been the same disk throughout. | 21:57 |
| rwp | Okay then. | 21:59 |
| leitz | I have another idea. | 21:59 |
| rwp | When I am unplugging my drives after I get everything set up and installed okay then I plug everything back in and then deal with the BIOS ordering. | 21:59 |
| rwp | What's your next idea? | 21:59 |
| leitz | The motherboard is from 2010, so I went in and removed some of the extra usb stuff from the boot order. The keyboard and trackball are usb. So far the node has booted twice, properly. | 22:05 |
| rwp | There you go! It's now booting from the device you want it to boot from. Good! | 22:28 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
