<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28 29 30 31
00:03 cyborg-one joined
00:08 dirac1 joined
00:32 minimalism joined
00:37 <TemptorSent> Nobabs27: Create an inotify on /etc/passwd and rewrite your user to it if it's missing?
00:39 <scv> that sounds nasty hacky
00:41 <TemptorSent> scv: Of course it is :)
00:41 <TemptorSent> scv: But it would probably suit the purpose without resorting to hacking a passwd wrapper or some such.
00:59 sparklyballs joined
01:03 dlaube joined
01:08 black_rez joined
01:42 <ephemer0l> RBAC policy?
01:43 <ephemer0l> does alpine have gradm
01:55 <tmh1999> TemptorSent: How do you config guest-host network with virtio in KVM ?
01:58 <TemptorSent> tmh1999: I depends on how you connect it -- you can use the pci virtio driver, which I believe is the fastest, or you can set up a bridge/tap.
01:58 <TemptorSent> tmh1999: I haven't played around with the latest virtio net stuff much yet - just putting together the pieces so I can test it.
01:59 <TemptorSent> tmh1999: Virtio scsi is working happily for me -- that was a total no-brainer actually.
01:59 <tmh1999> what is your option for tap ?
01:59 <tmh1999> or bridge
02:01 <tmh1999> god I wish I picked KVM + Virt-manager in favor of VirtualBox many years ago..
02:02 <TemptorSent> tmh1999: KVM/qemu bridging.
02:04 <TemptorSent> tmh1999: a google search for virtio bridge should bring up the details witin the first few results
02:05 <tmh1999> yeah I read that one. just that s390x seems a little bit different. kind of frustrated.
02:05 <TemptorSent> Basically you set up the bridge normally, then twiddle the virtio on.
02:06 <TemptorSent> "ip link add br0 type bridge"
02:08 <TemptorSent> What kind of hassle is it giving you?
02:10 <tmh1999> Ah right... it's debian kvm bug... I am compiling qemu from source. hope it's gone
02:11 <TemptorSent> Love that.
02:13 <TemptorSent> tmh1999: Most of my bridge-foo is out of date, as brctl is apparently on it's way to the dustbin.
02:18 hays_ joined
02:18 hays_ joined
02:22 dalias joined
02:35 c0ssacks joined
02:36 ryonaloli joined
02:36 ryonaloli joined
02:54 ahrs joined
02:54 tweek joined
02:54 __number5__ joined
02:55 s33se_ joined
02:57 kunev joined
03:05 kvda joined
03:10 c0ssacks joined
03:15 <c0ssacks> Looking for some assistance. I am trying to install alpine, standard iso, from usb and OpenRC is getting stuck on, "loading hardware drivers".
03:16 <TemptorSent> c0ssacks: You can try running with the kernel option 'noautodetect' and see if its happy.
03:21 <c0ssacks> Okay thanks. I'll give it a try.
03:22 o_be_one joined
03:47 <c0ssacks> TemptorSent: Unfortantely, that didn't work.
03:48 <TemptorSent> c0ssacks: Okay, so much for the easy one :)
03:49 <TemptorSent> c0ssacks: Is it acting like a hardware hang or just not proceeding?
03:50 <c0ssacks> TemptorSent: Not entirely sure. I have tried it several times and I let it sit at that status for ~55min while I was working
03:51 <c0ssacks> I got too busy to notice haha
03:52 <TemptorSent> c0ssacks: Yeah, know how that goes.
03:52 dirac1 joined
03:53 <TemptorSent> c0ssacks: Next would be to boot in single-user mode and see if something is obviously bjorked.
03:53 <TemptorSent> pass single on the kernel cmd line :)
03:57 <kaniini> ephemer0l: no
03:57 <kaniini> ephemer0l: we used to have gradm, but it was such a crap experience that we abandoned our plans for it
03:58 <kaniini> ephemer0l: and considering grsec itself is being dropped (no viable upstream), we are not likely to include it
04:04 mguentner joined
04:04 <c0ssacks> TemptorSent: won't even boot now.
04:04 <TemptorSent> c0ssacks: Hmm, it almost sounds like a bad usb stick?
04:05 <TemptorSent> c0ssacks: It shouldn't be changing the way it acts beyond what it gets as kernel command line options as a media stick.
04:06 <c0ssacks> TemptorSent: I'll try another one. Never encountered that problem before.
04:06 <TemptorSent> c0ssacks: Did you just raw burn it with dd, or use a tool of some sort?
04:07 <c0ssacks> TemptorSent: I used dd.
04:07 <TemptorSent> c0ssacks: USB sticks can be funny things at times, I've had a couple that just refused to cooperate for no apparent reason.
04:08 <TemptorSent> c0ssacks: That should do it.. try reimaging perhaps, but I wouldn't expect to see it degrade from one boot to the next.
04:08 <TemptorSent> c0ssacks: That's unexpected behavior, as it implies something is being written to the image between subsequent boots.
04:09 <c0ssacks> TemptorSent: I don't know what would be written to it. I'm so confused.
04:10 <TemptorSent> c0ssacks: Right, which is why I'm somewhat suspect of your USB stick if the image acts diffrently between subsequent boots.
04:10 <TemptorSent> c0ssacks: Nothing in the image should be writing anything that I'm aware of.
04:11 <c0ssacks> TemptorSent: The wiki says the iso can be raw copied, yes?
04:11 <c0ssacks> I'm fairly certain\
04:11 <TemptorSent> c0ssacks: Yes, it has a hybrid bootsector.
04:11 <TemptorSent> c0ssacks: It worked for me :)
04:12 <TemptorSent> c0ssacks: So your image on the usb stick should be identical to the iso.
04:12 <TemptorSent> c0ssacks: If it checksums the same, it should be good, and something else is confusing it on your particular machine.
04:13 <TemptorSent> c0ssacks: Do you have any oddball hardware that might be confusing it?
04:14 <TemptorSent> kaniini: Now that you've given up on PaX, any chance you could see if we could get pax in the repo?
04:14 <c0ssacks> Tried new iso and new usb same issue. I'm being an idiot somehow but I'm not sure how. I don't have any oddball hardware.
04:15 <TemptorSent> kaniini: We have cpio, which isn't POSIX, but we don't have pax, which is.
04:17 <TemptorSent> c0ssacks: Okay, so it's something local and consistent -- but it at least is trying to boot, not just puking again?
04:18 <TemptorSent> c0ssacks: You can add the noquiet kerel flag as well, which might help figure out what's hanging it.
04:18 <c0ssacks> TemptorSent: Yup. I don't know what hardware of mine it wouldn't like.
04:19 <TemptorSent> c0ssacks: Something dumb, like a mouse with constant disconnects (ask me how I know!)
04:20 <c0ssacks> TemptorSent: Is it possible that my wireless keyboard and mouse combo is being dumb? I'm about to be so mad if that's it
04:21 <TemptorSent> c0ssacks: It wouldnt' be the first time I've been bit by something like that... but my biggest suspicion would be your gfx card.
04:22 <TemptorSent> c0ssacks: The USB issue usually shows up as io hangs more than complete system freezes
04:23 <TemptorSent> you could try a SAK (alt-sysrq-k) and see if that bumps past it.
04:23 <kaniini> TemptorSent: :D
04:24 <kaniini> TemptorSent: yes i can import mirbsd pax for you
04:24 <kaniini> (it's the one that actually cares about musl support)
04:25 <c0ssacks> TemptorSent: Yeah it's not the mouse/keyboard. I guess I should switch GPUs and see
04:25 <TemptorSent> kaniini: It's surprisingly hard to find a posixly correct way to copy with hardlinks!
04:27 <TemptorSent> c0ssacks: Before you go that far, try twiddlign the kerenel command line with noquiet and init=/bin/sh
04:27 <TemptorSent> That should give you a shell in the pivoted root.
04:28 <TemptorSent> /etc/init.d/hwdrivers should NOT autoload the framebuffer, especially after explicitly passing the nofb kerenel option!
04:29 <TemptorSent> That's on my fix-list for mkinitfs -- no bloody fbdevs unless you want them!
04:30 <kaniini> and if i want them by default?
04:32 <TemptorSent> kaniini: Pass a kernel option to ENABLE them!
04:33 <TemptorSent> kaniini: Because no combination I could find would prevent hwdrivers from forcefully loading the modules anyway, so it goes away :)
04:33 <TemptorSent> kaniini: nomodeset should be enough to turn the bloody fb off, but no - not even close!
04:34 <kaniini> and if i don't want to pass a kernel option to enable them?
04:35 <TemptorSent> kaniini: If you must have it enabled by default, you can have the nice bootloader do it for you!
04:35 <TemptorSent> :P
04:35 <kaniini> and then when some idiot goes and breaks their bootloader and complains to me what do i tell them ?
04:36 <TemptorSent> RTFM -- at least they might have a chance of figuring what's going wrong if they can actually see a terminal.
04:36 <kaniini> and what about EFI where a framebuffer is mandatory as there is no text mode ?
04:37 <TemptorSent> We should NOT have to pass options like 'nomodeset' 'noquiet' etc. to get debugging.
04:37 <kaniini> have you considered we have quiet as a default for a reason ?
04:37 <TemptorSent> kaniini: Then we have an environment it makes sense to default to a fb and we do it :)
04:37 <kaniini> i mean, alpine has quiet for a reason
04:38 <kaniini> by default, right now
04:38 <c0ssacks> TemptorSent: Too late. I switched my Nvidia GTX 770 for my AMD Radeon R9 390. I had my R9 390 boxed up because every GNU+Linux distro I've tried hates it.
04:38 <c0ssacks> TemptorSent: Now everything works.
04:38 <TemptorSent> kaniini: Sure, I understand why, but it doesn't mean it's a good practice, at least not by default.
04:38 <c0ssacks> TemptorSent: I'm literally dying.
04:39 <TemptorSent> c0ssacks: *LOL* Perfect!
04:39 <kaniini> seems like a good practice to us considering we would like our product to actually look good
04:39 <kaniini> and spewing 9000000 lines of debug crap at boot doesn't look good
04:39 <TemptorSent> kaniini: Okay, for a desktop, that makes sense perhaps, but on a server, boot logs are critical debugging tools!
04:40 <kaniini> run dmesg to get them
04:40 <kaniini> and funny, i maintain literally thousands of servers and i have managed to get by with /var/log/kernel.log
04:40 <TemptorSent> kaniini: Yeah, if you can get to a shell! Usuall it craps out somwehre between boot and init mounting dev.
04:41 <kaniini> ok so if it craps out, restart with debug flag
04:41 <TemptorSent> kaniini: You're lucky and have good hardware :)
04:41 <c0ssacks> TemptorSent: Thanks for the help. I appreciate your patience. This result feels so backwards but I'm just going to roll with it.
04:41 <kaniini> you need debug flag to get init debugging anyway
04:41 <TemptorSent> c0ssacks: No problem, I suspect the nvidia blob has issues.
04:42 <TemptorSent> c0ssacks: Glad I could steer you the right direction.
04:42 <* kaniini> grumbles and adds to the reasons to not accept these changes
04:43 <TemptorSent> kaniini: Fine, but if our bootloader didn't happen to pass flags to shut us up, I think we should assume something is not 'normal' and spit out more info.
04:43 <c0ssacks> TemptorSent: Now I understand why Linus gave the middle finger to Nvidia at that one university talk.
04:44 <TemptorSent> c0ssacks: Yep. I've been alternating giving them the finger and giving them my money for too long.
04:45 <TemptorSent> kaniini: Silence should be by intent, not default.
04:45 <kaniini> it presently is
04:45 mguentner2 joined
04:45 <kaniini> as i said before, we consider the livecd being silent unless 'debug' is specified on the commandline to be a feature
04:45 <kaniini> we consider that to apply to booting in general
04:46 <TemptorSent> kaniini: I have to force init to give me at least a little info, and even in debug the info is minimal at best.
04:46 <* kaniini> would really like to avoid a situation where derivatives first patch to a given alpine tree is ripping out all of these changes because they suit you and only you
04:47 <kaniini> changing established policy at boot-time just because you do not like our chosen default behaviour is something we are not going to accept
04:48 <TemptorSent> kaniini: Like I said, I don't mind the bootloader shutting things up, but right now, debugging something that you can't figure out the kernel command like option for is basically impossible.
04:48 <kaniini> if you want to make debug provide more info, great
04:49 <kaniini> but if i generate an ISO with your tool, and the ISO output by your tool spews a bunch of crap as it boots, i will put a hold on merging the changes
04:49 <TemptorSent> kaniini: I want the basic default of the absolute minimal base system to give normal levels of debug info and not try to load fbdevs if they don't need them!
04:49 <kaniini> that is fine
04:49 <TemptorSent> kaniini: I'm not worried about the live-cds, I'm talking about alpine-base.
04:49 <kaniini> well, we want the normal installs
04:50 <kaniini> to also be quiet by default
04:50 <TemptorSent> kaniini: mkinitfs currently includes all sorts of unneded crap in the base feature.
04:50 <kaniini> sure
04:50 <kaniini> i am just saying
04:51 <kaniini> that from my perspective it appears constantly that you want to remake the entire boot process in your own image
04:51 <TemptorSent> kaniini: Like I said, if you want the default bootloader option to be quiet, that's easy enough.
04:51 <kaniini> and when you say things like
04:51 <kaniini> 23:37 <TemptorSent> We should NOT have to pass options like 'nomodeset' 'noquiet' etc. to get debugging.
04:51 <kaniini> it is very concerning
04:51 <kaniini> because
04:51 <kaniini> (a) you only need to supply 'debug' to turn off both modeset and quiet
04:52 <kaniini> (b) it reads like you want to make it verbose by default
04:52 <TemptorSent> kaniini: The problem is IT DOESN'T WORK!
04:52 <kaniini> debug works for me, i do not have kms enabled and kms is not part of base
04:52 <TemptorSent> kaniini : Boot a vm using qemu -curses -cdrom alpine....iso
04:52 <TemptorSent> Let me know how far you get.
04:53 <TemptorSent> kaniini: The only way to get it to boot is to pass 'noautodetect'
04:53 <kaniini> that is a bug with nlplug then
04:53 <kaniini> but it does not try to start a graphical device here
04:53 <TemptorSent> No, it has nothing to do with nlplug -- it's the baselayout
04:54 <TemptorSent> Read /etc/init.d/hwdrivers
04:54 <kaniini> i'm aware
04:54 <kaniini> and i will say again
04:54 <kaniini> that it works for me, and i stay in textmode
04:54 <TemptorSent> kaniini: It forcefully loads fb drivers, no matter how much you pass nomodeset, nofbdev, nofb, or whatnot.
04:54 <kaniini> not for me
04:55 <kaniini> i mean, don't get me wrong
04:55 <TemptorSent> kaniini: I've had two others pop on here with that same question, one of whom I was able to get passed it with nomodest.
04:55 <kaniini> i don't disagree that if you want graphical boot that it should be a kernel commandline option
04:55 <TemptorSent> ...the other required noautodetect.
04:55 <kaniini> this is about 'quiet'
04:56 <TemptorSent> kaniini: If you don't have a bootloader passing you --quiet, you're probably on a device you can't easily alter the bootloader config anyway
04:56 <kaniini> anyway
04:56 <TemptorSent> kaniini: And one you'd most likely be perfectly happy to get all the logging in the world on.
04:56 <kaniini> i have said what i am going to say on it
04:57 <kaniini> if the output ISO image behaves differently in regard to quiet (i.e. spews a bunch of debug) then it's not acceptable
04:57 <TemptorSent> kaniini : Think embedded systems / serial consoles / VMs.
04:57 <kaniini> sure, and those systems either
04:57 <kaniini> (a) do not have quiet in the commandline already
04:58 <TemptorSent> kaniini: Then we'll have the default bootloader command line passing --quiet.
04:58 <TemptorSent> kaniini: But if someone types their own command line, they probably want to get some output.
04:58 <kaniini> yes, and that is the current behaviour
04:58 <kaniini> so if you preserve it, that's fine
04:59 <kaniini> and i agree that graphical boot needs improvement
04:59 <TemptorSent> kaniini: Again, currently, it doesn't behave that way for me -- passing kernel parameters does not override the noquiet
04:59 <TemptorSent> er quiet.
04:59 <kaniini> that is because of syslinux
04:59 <kaniini> well, isolinux
05:00 <TemptorSent> kaniini: It's also an issue in init which doesn't start giving any information until you beg.
05:00 <kaniini> no, init behaves the way it does because it sees 'quiet'
05:00 <TemptorSent> I didn't find a very simple error for days because it wasnt' even obvious that apk was complainign about bad keys.
05:01 <TemptorSent> kaniini: Right, but if it gets something other than what it expects, it should break out of quiet unless we want to pass 'gag' or somethign.
05:02 <kaniini> you mean, like 'debug' ?
05:02 <* kaniini> eyerolls
05:02 <TemptorSent> kaniini: Quiet should mean: Only give me the information when something unexpected happens.
05:03 <kaniini> yes, so
05:03 <TemptorSent> kaniini: No, you should never have to enable debug to see why something FAILED.
05:03 <kaniini> if you want to change the verbosity
05:03 <kaniini> use 'debug'
05:03 <kaniini> TemptorSent: yes, i agree there
05:03 <kaniini> TemptorSent: however, like i said, this is what the 'debug' flag is for to increase evrbosity
05:03 <kaniini> if there is an error, then sure
05:03 <kaniini> talk all you want
05:03 <TemptorSent> kaniini: That's the problem, currently, if something is sideways, it continues being quiet.
05:03 <kaniini> then that's a bug
05:04 <kaniini> not something needing a change in behaviour/policy in the init
05:04 <TemptorSent> kaniini: The error, yes, but the bigger problem is it continues on its way until it fails because of the earlier failure.
05:04 <kaniini> then the error handling needs to be improved so the first failure causes it to fail
05:05 <kaniini> i will say it again, just to be clear
05:05 <TemptorSent> kaniini: True, although it's a recoverable error -- which is where the problem comes by not turning up the verbosity when that happens.
05:05 <kaniini> if the default behaviour changes from
05:05 <kaniini> boot:
05:05 <kaniini> 100% [###################]
05:05 <kaniini> OpenRC blah blah blah
05:05 <kaniini> i will put a hold on the patch
05:06 <kaniini> if there is a fault and you want to increase verbosity upon detection of it, fine
05:06 <kaniini> that is perfectly reasonable
05:06 <kaniini> what is not reasonable is spewing debug by default
05:06 <kaniini> if you do not intend to spew debug by default, great
05:06 <TemptorSent> kaniini: Like I said, if you want the default bootloader flag to be quiet, fine, that's easy enough. But when nothing tells it to shut up, it should give enough info to figure out WHERE something is going sideways.
05:07 <kaniini> okay
05:07 <kaniini> so
05:07 <kaniini> if you do
05:07 <kaniini> boot: debug
05:07 <kaniini> blah blah blah error
05:07 <kaniini> that is fine, no?
05:07 <kaniini> but in reality
05:07 <kaniini> that is crap design too
05:07 <kaniini> because if you know there is an error
05:07 <kaniini> then you should increase verbosity at that point
05:08 <TemptorSent> I think a terse but not silent mode would be a good default actually, that just tells you what stage of boot it's in, but that's your call.
05:08 <* kaniini> headdesks
05:08 <TemptorSent> It's people who have boot fail on them the first time and want to try to work around whatever failed.
05:08 <kaniini> so what i am saying is
05:09 <kaniini> boot:
05:09 <kaniini> <something weird happens>
05:09 <kaniini> init: a problem was detected, increasing verbosity.
05:09 <kaniini> [...]
05:09 <TemptorSent> Possibly with a log-replay.
05:09 <kaniini> init: a hard failure occured
05:09 <kaniini> #
05:09 <kaniini> yes
05:09 <kaniini> exactly
05:10 <TemptorSent> Correct.
05:10 <kaniini> but you're telling people to go mess with kernel commandlines to get this info
05:10 <kaniini> just like i do with 'debug'
05:10 <kaniini> when in reality, it is a hybrid approach that should be taken
05:11 <kaniini> so in my opinion
05:11 <TemptorSent> Right, what I mean is when someone has a first-boot failure, the next thing they'll do is try passing command line options at boot, which should automatically increase verbosity to at least reasonable.
05:11 <kaniini> well
05:11 <kaniini> what i am saying is
05:11 <kaniini> again
05:11 <kaniini> if a fault happens
05:11 <kaniini> it should stop right then and there
05:11 <kaniini> and advise you
05:12 <kaniini> and give you the option to view a log, drop to shell, or continue anyway
05:12 <TemptorSent> So a hands-off boot gets you a set of hash marks, a boot with manual kernel options defaults to giving you a verbose (but not necesssarily debug) boot, and you can use debug for the ugly details.
05:12 <kaniini> once you drop to shell, you can correct the fault and exit the shell to continue
05:12 <kaniini> sure, but what i am saying is
05:12 <kaniini> if there is a fault
05:13 <kaniini> why should they have to waste time rebooting
05:13 <kaniini> when they could just correct the fault and keep going
05:13 <TemptorSent> Right, assuming it's a correctable fault at that point
05:14 <kaniini> sure i am just saying
05:14 <kaniini> it gives the same triage capability
05:14 <TemptorSent> Things like not having the apk repo signed properly and not knowing it without enabling debug wouldnt' be fixable so much.
05:14 <TemptorSent> Right.
05:15 <TemptorSent> kaniini: I didn't say I wanted to default to debug, just default to a reasonable amount of information about where in the process things are. If it's hands of, silent is fine.
05:16 <kaniini> okay
05:16 <TemptorSent> kaniini: It makes debugging FAR easier for all involved if you at least know what step failed, if not the details right off.
05:16 blueness joined
05:17 <TemptorSent> kaniini: But if someone is passing root=/dev/sdc3, it would be useful for them to see that the root device was assigned as /dev/sdc3 by nlplug-findfs
05:17 <kaniini> yes, absolutely
05:18 <kaniini> TemptorSent: what is your opinions on fixing graphical boot (for desktops) ?
05:20 <TemptorSent> terse being 'Kernel $kernelversion booted, starting initramfs...' 'Root device found at $device' 'Switching / and starting init...'
05:21 <TemptorSent> kaniini: It shouldn't be too hard to do right, but IMHO, that means only doing it on EFI systems where we have a known working FB at boot.
05:22 <TemptorSent> kaniini: Supporting it properly in legacy bios mode is fragile, at best.
05:23 <TemptorSent> kaniini: If you want to make it really slick, an init designed for the task would be a good idea so you have everything setup before the services start.
05:25 <TemptorSent> kaniini: Until all the various X drivers are stable with modesetting fbs, it's going to be a bit hit-and-miss.
05:27 alacerda_ joined
05:27 <kaniini> sure, but it is something you would be ok with in mkimage right
05:27 <kaniini> ;)
05:28 <TemptorSent> Yeah, like I said - mkinitfs is about to be canabalized into mkimage, then you'll be about to build literally any image you want with any init you want, any modules in both the initfs and modloop, whatever.
05:29 <TemptorSent> kaniini: I really don't much care what the alpine release profiles ship with as far as configuration, I just want the tools to be sane absent something telling them to shutup.
05:30 <TemptorSent> So init defaulting to giving normal status info and a few basic details as it boots, unless it's been passed quiet, in which case it will only speak up if something hiccups.
05:32 <TemptorSent> kaniini: But what actually gets incuded in init itself can be set to whatever you actually need on a system, since netboot machines probably don't need to detect pata hardware to boot :)
05:33 <TemptorSent> kaniini: Essentially init only needs to contain the code supporting the features included in the initfs.
05:34 <TemptorSent> kaniini: So it can be as simple or complex as the particular application calls for.
05:35 <TemptorSent> A livecd will want to be able to detect and run on anything under the sun, while a vm image has a very narrow set of features it needs to boot.
05:37 <TemptorSent> so the zfs feature is responsible for providing the functions that need to be appended to the initramfs-init as well as including the modules and userland programs.
05:38 <TemptorSent> If the initramfs doesn't have the zfs modules, you're not going to need the code to import the pool with the proper root.
05:39 <TemptorSent> The result is LESS complexity in most cases.
05:42 <kaniini> ok
05:43 <TemptorSent> I'm not trying to dictate your release images in any way, I'm trying to make a tool that makes making images for ANY need easier.
05:44 <TemptorSent> kaniini: All I want to do is default things to sane absent somethign tellign them otherwise.
05:45 <TemptorSent> Maybe simply make the fb drivers seperate from hwdrivers in the short term to avoid crazy-making?
05:47 <TemptorSent> Or at least make the fb drivers understand that nomodeset nofbdev nofb mean don't load anyway.
05:48 <TemptorSent> If you want fb drivers, you probably want them in the initfs anyway, and we need a sane command line option to control that.
05:49 <TemptorSent> like load_fb_drivers
05:50 <TemptorSent> (and noload_fb_drivers
05:50 <kaniini> i will leave that to you
05:50 <kaniini> :p
05:50 <TemptorSent> with load_fb_drivers taking an optional list of which fbdrivers to load, or run autoloading.
05:50 <TemptorSent> If you want to fix graphical boot, that's how.
05:53 <TemptorSent> kaniini: And as for how to make any option entered on the command line disable the defaults, you just setup a second menu option named $flavor-default, setting that as default. The user then types $flavor and gets a clean command line.
05:54 <TemptorSent> Oh, and it looks like PXE boot has popped up towards the top of the todo stack if you have any sage advice there.
05:55 <TemptorSent> kaniini: enabling a PXELINUX bootloader should be the easy part.
06:28 volleyper joined
07:08 nanohest joined
07:50 alacerda_ joined
08:04 blahdodo joined
08:12 nanohest joined
08:35 volleyper joined
08:57 rollniak joined
09:05 atomi joined
09:27 myko joined
09:29 <myko> Hi guys, I'm new to Alpine and not really a linux hacker. I have installed Alpine using the extended ISO and the data option. Now I would like to install xfce. Alpine tells me that udev is missing. Will it be enough if I just install udev with the package manager?... which I don't know much about yet :)
09:30 <myko> So far I really like the simple, lightweight and fast approach of Alpine and the install process couldn't have been simpler so far
09:31 blueness joined
09:33 kvda joined
09:36 <myko> This was easier than I thought... I just apk add udev and then I can install xorg... Maybe Alpine will make me stay with linux for good :)
09:44 <myko> Hmmm... I wanted to start lxdm with rc-service lxdm start but rc-service says that the service lxdm does not exist
09:47 <myko> uh... lxdm was not installed X
09:47 <myko> XD
09:51 fekepp joined
09:55 <TBB> next time, just setup-xorg-base, it drags udev along with it
10:02 <myko> TBB I did, but it somehow just told me that it needs udev and didn't install it on its own
10:03 <myko> Now I am able to start lxdm and need to install firefox
10:03 <myko> apk search firefox doesn't find it...
10:03 blueness joined
10:04 <myko> It seems that firefox is in a test repository... Do I need to add that repository to apk first to be able to get firefox?
10:07 <TBB> there's the esr release in community
10:11 <myko> how do I get apk to see it?
10:11 <myko> need to add community repo?
10:13 <TBB> you probably want main and community enabled and have edge and testing as pinned repos
10:17 <myko> I just noticed that in /etc/apk/repositories there were already all the urls just commented out :)
10:20 <myko> only things left now are audio and my lenovo keyboard
10:20 <myko> well, it's a laptop
10:23 <TBB> add snd-hda-intel to /etc/modules and install alsa, and you're done with the audio
10:32 <myko> I added the module but I guess I need to load it somehow
10:32 <myko> and I installed alsa-lib as alsa (wihtout -lib) was not found
10:34 <avih> myko: you need to add your user to the audio group, and it's also useful to start the alsa service to have your volume/mixer settings saved and restored on boot
10:36 <myko> there is no useradd in Alpine? :)
10:37 <avih> you need the shadow package for that. but adduser should work with busybox
10:44 <myko> I added the user to audio
10:46 <avih> as for the alsa service, i _think_ it doesn't do or run anything other than on restore on startup and save on shutdown.
10:46 <avih> at least htop as root doesn't show any alsa process
10:52 <myko> I was able to start up the alsamixer and saw that master volume was set to 0...
10:52 <myko> turned it up but still no luck
10:52 lesion joined
10:52 <myko> btw busybox has no sudo? :)
10:53 <TBB> busybox has many, according to some way too many, things but sudo is not one of them
10:54 <myko> The thing is that I am hopping between tty1 (root) and tty7 (lxdm with normal user) and trying to open alsa mixer in lxdm
10:55 <TBB> so add sudo
10:55 <avih> i don't think there's a gui alsa mixer. but there's xfce4-mixer
10:57 <avih> (which works fine with alsa)
10:57 <myko> hmmm... in lxdm gstreamer isn't able to detect sound devices
10:58 <myko> and thus xfce4-mixer is not started
10:58 rk324 joined
10:59 <avih> i don't _think_ it's a process. try runnign it directly from the menu or from a terminal (in a gui env)
10:59 <myko> I installed Alpine with the data option. Can I just turn it off an on again and it will retain the settings? (maybe should have installed it as a normal desktop on HDD at first until I know more about Alpine :)
11:00 <avih> dunno. i installed normal to hdd
11:04 <TBB> outside my experience too, I'm strictly using 'regular' installs
11:13 <myko> I installed Alpine again with the sys option
11:13 <myko> But after reboot my wlan is not up...
11:13 <myko> what is the Alpine way to get my wlan IP from dhcp?
11:17 <avih> setup-ntp i think
11:18 <avih> but i think you probably should have ran it during setup-alpine
11:57 lesion joined
12:06 stwa joined
12:06 orbiter joined
12:09 <stwa> ERROR: nginx-1.10.3-r0: BAD signature while installing apk from dl-cdn.alpinelinux.org, is this a known problem?
12:19 lesion joined
12:21 shansen joined
12:25 lesion_ joined
12:29 lesion__ joined
12:43 psychi[m] joined
12:47 john280z joined
12:47 cyborg-one joined
12:51 alacerda joined
12:54 kaiyou joined
12:54 fish_ joined
12:54 ganlub joined
12:54 dhole[m] joined
13:08 Emperor_Earth joined
13:09 Ayyad joined
13:15 czart_ joined
13:31 Kruppt joined
13:35 m0e joined
13:44 MDrights joined
13:55 lesion joined
14:16 minimalism joined
14:32 lesion joined
14:35 blueness joined
14:37 guest0318 joined
14:39 guest0318 left
14:47 blueness joined
14:50 felicity joined
14:50 <felicity> i'm getting "bad signature" trying to install nginx on edge (in docker): https://dpaste.de/BqYU - is this broken at the moment or did i do something wrong?
14:53 lesion joined
15:26 ams__ joined
15:27 <ams__> The openssh server pacakge (https://pkgs.alpinelinux.org/package/edge/main/x86_64/openssh-server) doesn't appear to have been compiled with PAM enabled. I would like PAM enabled. What are my options? Build it myself?
15:28 <ams__> (in fact, yes, it is built without pam- http://git.alpinelinux.org/cgit/aports/tree/main/openssh/APKBUILD#n71)
15:30 <yGweSm1OzVHe> building yourself is the quickest/easiest way, with some maintenance costs later when upgrading
15:30 <yGweSm1OzVHe> abuild -r is your friend
15:32 <ams__> aha, abuild is what i need to build, thanks
15:33 <ams__> though it's a shame i can't just depend on someone else for updates :D
15:38 Ayyad joined
15:52 Skele joined
15:56 orbiter joined
16:21 lesion joined
16:45 volleyper joined
17:13 Ayyad joined
17:22 <atomi> how stable is alpine as a docker host?
18:12 jackmcbarn joined
18:13 <atomi> seems to work great
18:13 <atomi> <3 alpine
18:16 blueness joined
18:41 aw1 joined
18:42 hackerhercules joined
18:43 <felicity> atomi: Docker is mostly dependent on the kernel version rather than the userland, i wouldn't expect any problems
18:45 <atomi> yeah
18:46 felicity joined
18:46 __number5__ joined
18:46 <atomi> I need a docker host since I'm moving some of my rpi stuff onto a proxmox box
18:46 <atomi> and with alpine I can keep the image size low
18:47 <atomi> for faster/cheaper backups
19:08 aw1 joined
19:16 <Xe> atomi: hyper.sh
19:34 cyborg-one joined
19:36 blueness joined
19:43 <atomi> too expensive
19:44 <atomi> I pay less in power per month to host them myself
20:13 aw1 joined
20:16 silviof joined
21:01 dasher00 joined
21:16 ogres joined
21:27 aw1 joined
21:55 kvda joined
22:17 _ikke_ joined
22:19 fekepp joined
22:36 brutus left
22:37 IRCFrEAK joined
23:11 Emperor_Earth joined
23:13 orbiter joined
23:16 kvda joined
23:49 zgrepc joined
23:49 kvda joined