<mark_weaver>fchmmr: thanks for stopping by! I'm using Guix on a Libreboot X60 myself, and as you suggested I modified the grub.cfg in the flash to simply load the configfile from Guix's partition. <fchmmr>I added some changes to grub.cfg in libreboot to make it more proteanos-friendly. <fchmmr>For example, only loading initrd.img if it actually exists (checking that it exists first). <fchmmr>I'm happy to make such changes for Guix, where feasible. <fchmmr>Otherwise, grub_cbfs.html tells the user how to modify grub.cfg themselves. <mark_weaver>specifically, I have: menuentry 'Load Guix (sda3)' { // set root=(ahci0,3) // configfile /boot/grub/grub.cfg // } <fchmmr>Is Guix actually it's own GNU/Linux distribution? <mark_weaver>I made that the default entry with a timeout of 1, so it brings me to Guix's grub menu quite quickly. <fchmmr>My knowledge of it led me to suspect that it's just a package manager, but other people contradict that assumption. <mark_weaver>fchmmr: it's both a package manager that can run on other distros, and also a standalone distro. I'm using the standalone distro in my X60. <mark_weaver>but either way, the software it installs doesn't use anything at all from the host system except the kernel. <mark_weaver>guix installs it's own C library, dynamic linker, etc, in /gnu/store/* <mark_weaver>all of the software and much of the configuration is in immutable directories in /gnu/store/* <mark_weaver>then, each user has a directory ~/.guix-profile/ which is a tree of symlinks, that points to stuff in /gnu/store for all of the packages they've installed in their per-user profile. <mark_weaver>so users add ~/.guix-profile/bin to their PATH, and have to set several other environment variables as well to point into ~/.guix-profile/... <mark_weaver>on a standalone install, there's also /run/current-system/profile with a similar tree of symlinks. <mark_weaver>one of the nice features is that you can reinstall fundamental software like the C library, dynamic linker, etc, without fear of breaking your system. <mark_weaver>because those new versions of the C library/dynamic-linker/etc will be put into distinct directories in /gnu/store with different names from the old versions. <mark_weaver>all of the software you were already using will continue to use the old C library, but now you can recompile software on top of the new C library, and in the worst case that new software won't work, but you don't risk making your system unbootable. <mark_weaver>with the standalone system, when you upgrade your system, the new system becomes the default grub entry, but the old version is also provided in the grub menu. so if the new version in unbootable, you can just boot into an older version of the system. <mark_weaver>this allows us to have the best of both worlds: cutting edge software but also stability. <mark_weaver>(my grub menu now has dozens of entries, labelled by date, of older versions of my system) <mark_weaver>fchmmr: if you wanted to make Libreboot's default grub.cfg more Guix friendly, what we mainly need is an entry along these lines: menuentry 'Load GNU Guix (sda1)' { // set root=(ahci0,1) // configfile /boot/grub/grub.cfg // } <mark_weaver>it has to work by loading the configfile, because the locations of the kernel and initrd are in /gnu/store and change every time you update the system. <mark_weaver>Guix's grub config file is the only thing that stays in a stable place. <mark_weaver>but maybe you already have an entry that's essentially equivalent. (obviously there's nothing Guix-specific in that grub menu entry except for the title) <fchmmr>mark_weaver, I haven't modified grub.cfg in libreboot at all in the private (non-public) commits (the ones that will be public very soon). <fchmmr>So feel free to add/test whatever changes you like to the current libreboot git repo, and I'll merge them for you in mine. <ijp>I always read libreboot as LibReboot <mark_weaver>fchmmr: hmm, I already had an old git checkout of libreboot, and just did "git pull". much to my surprise, it seems that the most recent commit there is from Nov 28. is that right, or am I pulling from the wrong place? <fchmmr>mark_weaver, no, it's the right place. <fchmmr><fchmmr> mark_weaver, I haven't modified grub.cfg in libreboot at all in the private (non-public) commits (the ones that will be public very soon). <fchmmr>The commits that I've made since November 28th, 2014 are not pushed, but they do exist. <fchmmr>(they will be pushed during this month. my reasons for withholding them will be revealed at that time) <fchmmr>I haven't made changes to the default grub.cfg since November 28th 2014, though. <mark_weaver>resources/grub/config/menuentries/common.cfg is what I should be changing, right? <fchmmr>So any changes that you make sure will merge with my local repository without needing to be re-based. <fchmmr>the parts of grub.cfg are separated like that because there are lots of different configs but they all use common snippets. <fchmmr>The build scripts assemble them together into single grub.cfg files for each configuration. <mark_weaver>fchmmr: hmm, what would you think of changing the default 'Load Operating System' entry to read the configfile from /boot/grub/grub.cfg on sda1 instead of loading the kernel and initrd directly? it seems to me that this would be far more flexible. many people and systems add their own command-line arguments to linux-libre, for example. <fchmmr>Not an option, because many libreboot users install without a bootloader at all on the HDD. <fchmmr>You can't assume that there is any trace of GRUB anywhere on the HDD. <mark_weaver>well, you could still keep that menu item that loads linux/initrd directly, it just wouldn't be the default <fchmmr>The grub.cfg in libreboot is (with the exception of the "Search for" option) entirely self-sufficient for this reason; the assumption is that the only bootloader/config is the one in the boot flash, and that the user has no bootloader or config anywhere on the HDD. <fchmmr>mark_weaver, my Trisquel 7 installation lacks a bootloader. <fchmmr>The /boot directory contains only linux-libre and initramfs files. <fchmmr>no GRUB. That's only in the SPI flash. <fchmmr>This is possible in libreboot because libreboot *is* the bootloader (by using GRUB for the payload part). <mark_weaver>distros generally provide multiple options in their grub menus, and provide additional command-line arguments to the kernel, have entries for "single user", etc. <mark_weaver>the default grub.cfg that you are currently using makes it awkward to make use of all that. <mark_weaver>it's super easy to install grub on Trisquel, as you know. <mark_weaver>so it just seems to me that the current default is suboptimal. <fchmmr><fchmmr> So any changes that you make sure will merge with my local repository without needing to be re-based. <fchmmr>Well, a re-base will be needed but it will just mean changing the commit id, no actual code changes. <mark_weaver>here's the thing: with the current default, anyone who wants to use their own distro's grub.cfg is forced to manually edit their grub.cfg, modify their rom image, and then reflash and hope that they don't make a brick. <mark_weaver>(well, unless they want to navigate the menu on every boot, which is terrible) <mark_weaver>with my proposed default, they won't have to. if they don't have a grub.cfg on their disk, then they'll need to boot into a non-default menu item once and then install grub (easy). <mark_weaver>put another way: my proposed default can be a good default on *any* distro, requiring only a grub.cfg file on the disk. whereas your proposed default simply can't work with Guix at all, and so every Guix user will have to do the scary edit-grub.cfg-in-rom-image and reflash. <mark_weaver>fchmmr: I just had an idea: how about making the default entry do "configfile /boot/grub/grub.cfg" only if that file exists, otherwise do what you do now. would that be acceptable to you? <mark_weaver>(I don't know for sure that you can do that in grub, but I could look into it) <davexunit>I had to do the 'set root ...' dance every time I wanted to boot guix on one of the FSF's x60 laptops. <jgrant>I thought about this earlier; Would VPSes be nicer in GSD? <jgrant>davexunit: Oh yeah, also i was talking about this earlier -- do you know of any free-software supporting VPS services? <davexunit>I would like to rebuild my Linode VPS sometime to use Guix <jgrant>davexunit: I was actually talking about that earlier too. <davexunit>but I don't know how to install an OS of my choice on there. <jgrant>davexunit: Finnix can load in swap. <jgrant>You should be able to bootstrap. <jgrant>The easyish way would have guix build in Swap? <jgrant>So then you just "guix init" to the root fs? <jgrant>Does GSD have an nginx service yet? <jgrant>That's all I really need/want in the short term. <jgrant>Eventually Gitlab and Mediagoblin. <davexunit>jgrant: I got 30 python packages into mediagoblin <jgrant>davexunit: If I can get it on my Linode instance, I will. <davexunit>mark_weaver: I don't think we have a service definition for it though, do we? <jgrant>davexunit: I suspect there will be like 80 or so, for Gitlab. <davexunit>jgrant: gitlab is ruby, and our ruby build system isn't very good yet. <davexunit>because ruby packages are mostly quite terrible, honestly. <mark_weaver>(which we're running at the front web server on hydra.gnu.org, incidentally) <jgrant>davexunit: Yeah, sorry, I should have specified Ruby. <jgrant>davexunit: Yeah, I've heard. The issue is that by far, Gitlab is the best free software tool for this job. <davexunit>nginx just uses the stuff on rubygems.org, but I aim to do better. <davexunit>jgrant: I'm hoping to run a gitlab instance at the FSF <davexunit>I have a lot of repos that I want to make publicly cloneable <jgrant>I'm hoping the Guile community writes a "Tarpit" or something, for Software hosting and development eventually to replace Savane. <jgrant>Most anything would be better than Savane, at this point. :^P <jgrant>davexunit: Isn't that like cgit? <davexunit>cgit is just a web viewer, gitolite manages users who have read/write access and the repos themselves <jgrant>Oh, it's just for hosting repos. <davexunit>hoping we can get a git.fsf.org up and running sometime. <davexunit>replacing savannah is a huge topic, with lots of political issues. I don't even want to get into it. <jgrant>What happened to that one attempt like 2-3 years ago? Anything? <jgrant>It kinda sticks whatever software would have to support like 5+ VCSes. <jgrant>It'd be a lot easier/nicer if we only had to support Git and Maybe SVN officially. <jgrant>Never going to happen, but yeah. <davexunit>I'm hoping the gnu.org website repo moves to git soon <jgrant>davexunit: Yeah, that would be huge; That historical baggage is pretty strong in GNU though. <davexunit>but rms commits to it often, and I don't see him wanting to use git. <jgrant>davexunit: If you happen to hack together a solution for GSD in the shortish term though, please contact me. :^) <jgrant>Oh yeah, need to contact that guy about fixing his Guix COPR RPM spec. <jgrant>Yeah, it doesn't look as braindead to set up a linode instance as with NixOS. <jgrant>Considering starting a page, for Linode. <jgrant>I'll sleep on it; Night y'all. o/ <mark_weaver>in the default entry, if loads grub.cfg from the disk if it's there, otherwise there's no change in behavior <mark_weaver>please consider it. It would be a huge help to us if Libreboot X60 owners could boot to Guix without having to reflash. <fchmmr>mark_weaver, that patch won't work well, because then it will automatically switch to the grub.cfg of the user's distro if it exists <fchmmr>those grub.cfg files on the distro might try to do things that are unsupported by the libreboot grub payload, the most common example being trying to load modules that neither exist or are needed for libreboot (resulting in error messages on the screen). <fchmmr>If you do an "automatic" Guix install, or what is otherwise considered default or "standard", where is the vmlinuz/initramfs? <fchmmr>what partition is considered default? <fchmmr>You should be searching for the kernel itself <fchmmr>For instance, checking whether /boot exists and whether a certain kernel/initramfs exists inside, and checking what partition that is on. <fchmmr>If Guix has symlinks pointing to the kernel (in the case where older versions kernel/initramfs is kept under different filenames, and the symlink is automatically updated to point to new kernels when updating) then that should be easy <fchmmr>or if Guix is more like Parabola where the latest kernel always has the same path/filename <mark_weaver>fchmmr: I'm afraid this is unworkable for us. This is what a typical grub.cfg menu entry looks like in Guix: search --file --set /gnu/store/g1vr4fdzdgffs7a7nkbm1nnx5qypxa8a-linux-libre-3.18.3/bzImage // linux /gnu/store/g1vr4fdzdgffs7a7nkbm1nnx5qypxa8a-linux-libre-3.18.3/bzImage --root=jojen-root --system=/gnu/store/6zlkmw0ndqyfkb37y1djh90bzhrgdj62-system --load=/gnu/store/6zlkmw0ndqyfkb37y1djh90bzhrgdj62-system/boot // initrd <mark_weaver>/gnu/store/6zlkmw0ndqyfkb37y1djh90bzhrgdj62-system/initrd <fchmmr>mark_weaver, for a standard/typical setup can you send me the full copy of grub.cfg from Guix? <mark_weaver>the problem you are raising is hypothetical and easily remedied by deleting grub from the disk if the user doesn't want to use it. <mark_weaver>whereas we have no easy remedy for the problem we face <mark_weaver>and it's not just us. distros typically add extra kernel command-line arguments that your default entry lacks. you are making assumptions about how the distro wants to boot. <fchmmr>Another problem might be if the distro grub.cfg tries to set the prefix. If that happens, it means that you are now using the modules for that distro's GRUB, which are probably not from the same version of GRUB that libreboot uses. <fchmmr>mark_weaver, there is another way. You could add a special rule to Guix to create an "alternative" grub.cfg which is libreboot-friendly. <fchmmr>Then libreboot can conditionally load this if it exists (and if it does exist, it will skip the usual booting methods). <fchmmr>The "alternative" grub.cfg is created equally alongside the main one, whenever updating and so on. <fchmmr>Conditionally loading that would work well for Guix and would not negatively affect other distros. In fact, other distros could also do the same thing in which case this method would actually start to become portable. <fchmmr>You could also search for it in grub using a for loop instead of assuming ahci0,msdos1 (adapting the code from the "Search for local grub.cfg" menuentry). <fchmmr>The main distro grub.cfg is prepared by the disto under the assumption that you will be using it's version of GRUB. <mark_weaver>I suppose we could add some special libreboot magic, but it seems a damn shame to have to do that. <mark_weaver>every potential problem you've raised can be solved _very_ easily: delete grub on the distro if you don't want to use it. <fchmmr>the "lbgrub.cfg" would more or less be the same, just making sure that it is not setting prefix (already done by libreboot's GRUB payload, pointing to the modules stored in the SPI flash) <mark_weaver>is that so hard that it justifies the drawbacks of your current approach? <fchmmr>and it would also not try to load modules or use methods that are unavailable in libreboot grub <fchmmr><mark_weaver> every potential problem you've raised can be solved _very_ easily: delete grub on the distro if you don't want to use it. <fchmmr>I'm thinking mainly of user comfort here. <fchmmr>They can delete GRUB on the HDD, but that's an intervention step. The user might also want to regularly switch between libreboot (with grub) or coreboot (with seabios, which needs the distro grub to be present) ***dhgbrg is now known as dfh
<mark_weaver>we could also check for the existence of /boot/grub/libreboot_dont_use_this_grub_cfg and then users could add that if there are problems. <fchmmr>Basically, the issue is that the grub.cfg on disk is not specifically created for the GRUB payload in libreboot, though it might work. <fchmmr>The way I see it, there are 2 possible situations from Guix's persective: <fchmmr>* user is not using libreboot. Thei have a BIOS. it executes distro GRUB. grub.cfg from that is used. <mark_weaver>but in practice, have you observed problems with that, besides error messages? (and yes, I see those too, but it has not caused me any actual problems) <fchmmr>* user is using libreboot with GRUB payload. distro grub.cfg is not guaranteed to work. There needs to be a separate grub.cfg for this situation. <fchmmr>The "guaranteed to work" part is my main concern. If I conditionally load main distro grub.cfg, it won't exactly cause issues but it might cause errors if that grub.cfg is doing things that the distro grub is capable of that libreboot grub isn't. <fchmmr>conditionally loading "lbgrub.cfg" instead, is guaranteed to work smoothly (because the distro would actually prepare that .cfg specifically for libreboot). <fchmmr>I'd like to try to get this in Trisquel, probably in 7.0.1 or something. And Debian maybe. <mark_weaver>fwiw, I agree that there is value to having distros create libreboot-specific grub.cfg files under a different name, and we should probably do that. <fchmmr>Basically, cover all the distros that a libreboot user is likely to use <fchmmr>There are also situations where the distro doesn't use grub at all, for instance it might use syslinux or lilo. <fchmmr>I actually think that distros could create the lbgrub.cfg regardless of whether an actual grub is installed or intended to be install on disk. <mark_weaver>well, I completely agree that your current behavior is good when grub.cfg doesn't exist on the disk. <fchmmr>tails is also sometimes used by libreboot users ;) <fchmmr>the name isn't an issue for me. libreboot-grub.cfg is fine. <fchmmr>though, I normally use underscores instead of hyphens <mark_weaver>I'll update the patch and test it and then send it to you. thanks! <fchmmr>though, it currently assumes ahci0,msdos1 as I do. <fchmmr>I should probably use a for loop in there instead, searching all partitions instead of assuming that it's the first one. <fchmmr>I wasn't aware of that ability to automatically set the root, until you showed me the grub.cfg from guix. <mark_weaver>I wasn't either, to be honest. It's civodul's work (principal Guix dev) <fchmmr>There are other solutions proposed for what we are doing here, but they all involve huge grub.cfg files with all kinds of magic in them. <fchmmr>They were a bit too extreme, so I kept with the current approach. <fchmmr>search --file --set plus libreboot_grub.cfg will be a more sane solution I think. <mark_weaver>and if no libreboot_grub.cfg is found, should we search for a partition with the kernel, or should that fallback be restricted to (ahci0,msdos1) ? <fchmmr>probably ahci0,msdos1 assumption <fchmmr>There's a balance, because the booting will get slower and slower as you start searching more. <fchmmr>conditionally booting with libreboot_grub.cfg should work well enough. <fchmmr>It can switch to a new menu using libreboot_grub.cfg. That way, the user can easily press ESC to get back to the main libreboot grub.cfg in spi flash if needed. <fchmmr>Then the libreboot_grub.cfg sets it own timeout (or whatever guix does). <fchmmr>in libreboot_grub.cfg you have access to everytching that the libreboot grub payload can use <fchmmr>eg devices (cbfsdisk), (memdisk) and so on. <fchmmr>(cbfsdisk is the filesystem inside the libreboot ROM image that is flashed, which contains payload, grub.cfg, files, etc) <fchmmr>(memdisk is the filesystem inside the grub payload) <fchmmr>"disk" is cbfsdisk is a bit misleading, since it's not actually a spinning magnetic disk. <mark_weaver>ah, so in theory you could put a rescue initrd and kernel in there, if there was enough space <fchmmr>pehjota is working on creating an option where you can build proteanos as 2 files: kernel and a very large initramfs. That can go in SPI flash (CBFS) loadable from GRUB. <fchmmr>This only works if the spi flash is big enough (basically, the only target being considered at the moment is the thinkpad x200 which typically has an 8mb flash chip which is plenty of space for a compressed kernel/initramfs) <fchmmr>everything will be self-contained there in those 2 files. it would be like a live usb/cd, only it's in the spi flash and always available. <mark_weaver>fwiw, I have an X200 that I could test on, if you like. <fchmmr>Yes, I'm almost ready to release. <fchmmr>There isn't much more testing needed at the moment (all bugs are currently known and documented). <mark_weaver>one issue: did you mention that if software tries to use hardware virtualization, it fails ungracefully? <mark_weaver>alas, that will be an issue for us, since some of our build recipes use qemu. <fchmmr>could use software virtualization. also, the panics were only observed on one machine so far. <fchmmr>It could be that some work and some don't. <fchmmr>(depending on what revision of the microcode is burned-in to the CPU). <mark_weaver>it would be nice if the kernel reported that hardware virtualization wasn't available, so that it wouldn't try to use it and fail badly. <mark_weaver>I'm not sure of the details of how that's detected though, and whether libreboot can do anything about it. <fchmmr>Between now and the timeframe of when I want to release, there's not really much testing that could be done with vt-x <fchmmr>I'm happy to look into it post-release, though. <fchmmr>(it's currently not considered a critical issue, because most users don't need virtualization). <fchmmr>(and software virtualization should still work if hw virt fails, it would just be a bit slower) <mark_weaver>well, when a user is manually running qemu and can just add a flag, that's not a problem <mark_weaver>but when software uses qemu as part of its job, then it means we'll have to find some automatic way of working around it. <fchmmr>There needs to be a way to systematically disable hw virt to prevent crashing, in the cases where it is unsupported or unstable. <fchmmr>That is probably a job better suited to the linux kernel. <mark_weaver>well, I don't know if it's an issue outside of Libreboot. <fchmmr>Alternatively, if it's possible to disable in libreboot then it could be added to coreboot as an nvram option <fchmmr>(nvram is where proprietary bios' typically store configs. coreboot can also put it's own configs there for things like wifi and so on) <fchmmr>The utility for manipulating it is "nvramtool" from coreboot <fchmmr>The release will be extremely short-lived. <fchmmr>It will likely not be very long before another release is made with more polish/bugfixing. <fchmmr>That's more or less the way libreboot works. <fchmmr>"relevant" issues are fixed first, but for that you need lots of users. <fchmmr>there's only so much that I can do on my own, and I'm fairly certain that there are going to be lots of problems that I didn't spot. 2 or 3 other testers won't change that much, so I'll just do the release as-is. It already works well enough that it's "ready" <fchmmr>The very first libreboot release in december 12 2013 was absolutely full of bugs. <fchmmr>this one won't be anywhere near as bad <mark_weaver>have you written the docs on how to set up the BBB flashing setup? if so, I wonder if there's any reason to hold back on releasing it. I'd like to start getting prepared so I can flash when you release. <fchmmr>I'm basically ready to release now, there are just a few things I need to check. release will probably happen this week. <mark_weaver>would you be willing to send me the BBB flashing docs now? <mark_weaver>no, not yet, but I thought I'd order everything at the same time. <fchmmr>that being said, you probably need to know what to get. <fchmmr>that URL will disappear after the libreboot release, though <fchmmr>The only part of that URL that might not be relevant is the PSU <fchmmr>Because you might have to get a different type of PSU if the one I'm using is not available for you to order anywhere. <fchmmr>Any 3.3v DC supply is fine (mine is 20A, but it won't use anywhere near that much. probably way less than 5A is needed. Excess current availibility just means that most of it's capacity is unused) <fchmmr>A few people use ATX PSUs for instance, which can have a jumper put on it to start it without being connected to an ATX motherboard and then you use the 3.3v DC supply that it has on it <fchmmr>not all ATX PSUs are reliable for this, though. <fchmmr>Also, the PSU that I use is a bit... well... dangerous. If you touch those screws on the live/earth/neutral, you could get an electric shock. <fchmmr>So I place it in such a way where I am unlikely to accidentally touch them, and I keep my hands well away from the terminals <fchmmr>I also wrapped loads and loads of electrical tape around the terminals (not shown on that page, since I did it afterwards). <mark_weaver>fchmmr: you might want to suggest a specific known-good SVN revision of flashrom to build, instead of trunk. <fchmmr>Yes, well, libreboot comes with flashrom. most people use that. <fchmmr>In fact, the libreboot release is going to have ARM binaries in the binary archives (for utilities like flashrom), which have been tested on my BBB. <fchmmr>So the user can just use that if they want, or copy the flashrom src from libreboot to their BBB, which is patched/tested. <mark_weaver>also, I wonder, should 2015 be added to the copyright notice of that BBB file? (and maybe some other things you've been editing lately) <fchmmr>Most of my changes were done in 2014, though. <fchmmr>I worked like a madman getting everything done during december 19th to december 31st <fchmmr>everything after that is small bits of polish <fchmmr>The next time I update something, I change the copyright year. <fchmmr>there was also a lot of work between november 28th and december 19th. <fchmmr>mark_weaver, anyway that URL I gave you should help you setup your BBB as a SPI flasher. <mark_weaver>time to start placing orders, though I must sleep first <fchmmr>It will need to be tested, of course. <mark_weaver>yes, of course. I'll let you know when I've tested it. <fchmmr>Test it on yours against guix, and I'll test it against trisquel. <fchmmr>(I'll wait for your results with guix first. no point me testng it until I know guix works with this method) <fchmmr>the automation for libreboot_grub.cfg doesn't need to be there right now, you just need to put a libreboot_grub.cfg there <mark_weaver>and I'll have to modify guix to produce libreboot_grub.cfg <fchmmr>automation (of creating it, alongside guix grub.cfg) can come once we know that this works. <fchmmr>ah. that URL lacks the license.txt for cc by sa <rekado_>bavier`: I remember you said that you've packaged dozens of perl packages. As I'm going to have to package a few perl modules soon, it would be great if I could see the list of packages you already got lest I duplicate your work needlessly. <civodul>i'll call it GSD or GNU GSD, i think <atheia>Good — I think those are definitely the best ones. <atheia>And from what I can tell in the channel they seem most popular too… <DusXMT>civodul: About those nvi patches, what do you think about including at least the two of them that I mentioned, and provided a patch? I don't think 3 patches in total is that terrible, and they get rid of visual warnings that might scare the user <DusXMT>s/get rid/solve the problems behind/ <civodul>DusXMT: sorry i haven't checked the ML yet <civodul>rekado_: could it be a problem with the libjpeg version? (i see "JPEG" in the backtrace) <jgrant>civodul: Have you seen my syntactic sugar patch for use-modules (specifically those of packages, services, and system) yet? <davexunit>oh yeah. I should apply that patch tonight if no one voices any objections. <civodul>probably, i haven't looked at it yet, sorrty <jgrant>Would there be any objections to adding a "Installing GSD on Linode." Libreplaned page, on the Guix Group? <jgrant>It looks like we could copy aprox half the NixOS install instructions there. <jgrant>davexunit: It's something I plan on working on a bit; Not really today, I'm going to be gone/afk for like 8 hours probably today. <jgrant>But, it'd be nice to chart where the issuses are. <civodul>i guess it would be a useful wiki page <rekado_>civodul: I wonder how there can be segfault due to differences in versions when what is run has been built against this very version of libjpeg. <rekado_>There are many such oddities in the tests. <rekado_>In the tests for javap, for example, it is pretty clear that an older output format is produced, not the expected format. <jgrant>Ideally, I would like to see a startup or something based around doing NixOS and/or GSD VPSes. <jgrant>But ... right now, Linode seems like the "Best" option for this. *davexunit files for incorporation <civodul>rekado_: dunno it was just a random idea; i know there are subtle differences between libjpeg versions, which is why we have two(?) of them <davexunit>jgrant: I see such a startup dying if/when linode or whoever supports NixOS. <jgrant>davexunit: Yeah; I guess you could market to strong FOSS Advocates. <rekado_>I must say that the segfault report output doesn't make much sense to me. I don't know what it means that the problematic frame is "[ld-linux-x86-64.so.2+0x141a1] _dl_close+0x1" <davexunit>I was thinking about how to use Guix to create application "bundles" that can run on any GNU/Linux system this morning. <rekado_>why there? This looks like a mere plumbing call. <jgrant>davexunit: Can you expand a bit on this? <davexunit>it seems possible. just use the package's closure. <civodul>yeah, "guix archive -r the-package > bundle" <civodul>err, "guix archive --export -r the-package > bundle" <civodul>rekado_: let's hope someone replies to the bug report <civodul>perhaps you could skip the test in the meantime? <davexunit>civodul: 'guix archive' will also archive all of the references packages? <rekado_>civodul: I could skip this one test, but that still leaves about 100 that fail for weird reasons beyond my understanding. <civodul>it would be good to have a feel of whether the test suite is known to fail for everyone <civodul>that's the case for some big projects <civodul>before it becomes too frustrating ;-) <jgrant>How's "Installing GSD On Linode" as a title for this page? <rekado_>I'd love to and I'd probably have done it earlier if it wasn't for this segfault (because that's something I feel uncomfortable with ignoring). <rekado_>I should also say that there is still a class of tests that fail for PATH-related reasons. <rekado_>They run fine in guix environment, but they fail with guix build. <rekado_>the errors are something trivial like being unable to find "cp" in the PATH. <rekado_>I found one instance where the PATH is actually overridden. <rekado_>but even after fixing it the tests still fail as before. *davexunit has to work on fixing 'guix environment' <rekado_>there's got to be something else, but I haven't been able to find it. <civodul>perhaps a bunch of hard-coded "/bin" in makefiles or source code? <rekado_>there's also the use of UNIXCOMMAND_PATH, USRBIN_PATH, and a couple more. <rekado_>they are no longer problems, I think. <rekado_>but somewhere along the way the PATH is corrupted. (oh, how poetic.) <rekado_>The path is fine just before the check phase. <rekado_>I use (getenv "PATH") in a new phase before 'check. <rekado_>(to fix the one instance where the PATH is set in jprt.config, the config file for the hotspot test suite) <rekado_>would it be okay if I just sent my patch to the mailing list for discussion so others can take a look and play with it? <jgrant>davexunit: I just partially conceptualized portable bundles, yeah, that would be cool. :^) <davexunit>the bundles would be quite large, but they would work. :) <davexunit>might be a reasonable way to ship a binary to someone that is guaranteed to work. <jgrant>rekado_: That's typically a good way of doing things. :^) <effa```>rekado_: have you set $JAVA_HOME before the tests? <rekado_>effa```: no. And I don't think I should. <rekado_>I actually think it should *not* be set <rekado_>the build instructions say that JAVA_HOME may not be set before building. The tests are executed as part of the regular build. <mark_weaver>civodul: btw, last night I had a long conversation here with fchmmr (the Libreboot maintainer and Gluglug seller of Libreboot X60's) about how to allow the default Libreboot configuration to boot into a Guix system. <mark_weaver>background: Libreboot includes GRUB and a grub.cfg in the flashed ROM image, so you always have GRUB even if there's no disk in the machine at all. <mark_weaver>their default menu entry looks for /vmlinuz and /initrd.img in the root directory of the first partition, and boots that with only the parameters "root=/dev/sda1 rw" <mark_weaver>the only way to change that default is to modify the rom image and reflash it, which some users are probably nervous to do since if they mess up they could end up with a brick. <mark_weaver>I suggested having Libreboot look for /boot/grub/grub.cfg and to load it if present, but fchmmr didn't like that, because in the general case it won't work: the grub in Libreboot may not support the same set of modules as the grub on the disk, may be a different version, etc. <mark_weaver>anyway, in the end we settled on a different approach: look for /boot/grub/libreboot_grub.cfg <mark_weaver>that file would be mostly similar to our normal grub.cfg, but would avoid doing things that are unsafe like trying to load modules from the disk. <mark_weaver>civodul: thoughts? fchmmr is on #guix now so if you want to discuss with him. <civodul>mark_weaver: generating libreboot_grub.cfg sounds like a good idea <civodul>i'm not sure how loading GRUB modules relates to the rest, though <mark_weaver>civodul: the safest thing would probably be to avoid loading any modules at all in libreboot_grub.cfg, and just presenting the menu. <civodul>i understand, but why would there be different considerations for libreboot_grub.cfg than for grub.cfg wrt. module loading? <mark_weaver>and better yet, I guess we could arrange to make it a real submenu, so ESC would return back to the main menu embedded in Libreboot <mark_weaver>civodul: because grub.cfg can assume that the grub executable being used is the one that Guix built, but that's not the case in libreboot. <mark_weaver>the GRUB executable in Libreboot may be a different version, so the modules that we compiled may not load properly into the Libreboot GRUB <fchmmr>GRUB is built specifically for coreboot, using ./configure --with-platform=grub <fchmmr>The libreboot_grub.cfg idea can be extended to other distros, most of which will have an automated way to generate grub configs <fchmmr>distribution grub configs typically try to use modules that don't exist in libreboot grub (due to limitations in the size of the spi flash), and they might also try to set the prefix which would mean loading the distro grub modules instead of the libreboot ones (this breaks GRUB). <fchmmr>All libreboot really needs is "set root" "linux" and "initrd" then "boot" commands to boot. Another advantage to having a libreboot_grub.cfg auto-generated alongside the main grub.cfg is that in the libreboot grub.cfg you can assume 100% that it's for GRUB (coreboot payload) so you can do things like read from (cbfsdisk) <civodul>mark_weaver: re modules, OK, understood now <civodul>so libreboot_grub.cfg would be very simple, essentially chain-loading the "real" grub? <mark_weaver>fchmmr: is there a way for us to make a GRUB that can be loaded by Libreboot's GRUB? not just the config file, but the whole executable? the reason I ask is that's there one problem with this proposal: we have to take it on faith that Libreboot includes the modules we need, and if it doesn't we're stuffed. <fchmmr>civodul, chainloading the GRUB on disk is not possible due to lack of BIOS services. <fchmmr>libreboot uses GRUB as payload, with no x86/PC BIOS of any kind. <fchmmr>It's only possible to use the GRUB payload (in the SPI flash chip) with a libreboot system. You actually can't even execute the one that's on disk. <mark_weaver>fchmmr: sure but what if we built our GRUB for a different platform, like coreboot? <fchmmr>Hence the discussions about libreboot_grub.cfg <mark_weaver>in theory, it could be done, but I don't know if there are any missing pieces. <fchmmr>It's possible to switch to another grub.elf executable even if it's on disk <fchmmr>the condition being that you compiled it with ./configure --with-platform=grub <civodul>without modules, people are limited to the features available in the in-flash GRUB <fchmmr>GRUB (coreboot payload) can only boot other coreboot payloads, or a linux kernel. (or a bsd kernel, or memtest86+, but that's outside of the scope of this discussion) <fchmmr>it doesn't matter where the payload that is "chainloaded" is located, whether that be on disk, in spi flash (CBFS) or whatever. <fchmmr>That solution would be messy, though. <fchmmr>It's much cleaner to automatically generate a libreboot_grub.cfg the same way that grub.cfg (on disk) is generated in guix <mark_weaver>fchmmr: so you feel fairly confident that it's possible for one GRUB (for coreboot platform) to load another grub (for coreboot platform)? <mark_weaver>note that this chain loading would be done within our libreboot_grub.cfg. it still makes sense to have that file. <fchmmr>mark_weaver, yes, but that solution isn't practical. libreboot_grub.cfg is cleaner because it doesn't need a C utility called grub-mkstandalone for it to work whereas libreboot_grub.cfg would be generated by bash scripts like the main grub.cfg is in most distros. <mark_weaver>fchmmr: each distro could make its own decision about whether to chain-load, right? <fchmmr>(grub-mkstandalone is what you use to create an ELF payload executable of GRUB, once you've built grub for coreboot) <mark_weaver>i.e. trisquel could just make a libreboot_grub.cfg with a menu, and we could arrange to chain-load our own grub-for-coreboot-platform <fchmmr>You would be generated libreboot_grub.cfg and in there you would chainload a grub.elf from the disk which is specifically built to be used as a payload of coreboot. <fchmmr>I'm pretty sure you can chainload that. <fchmmr>"chainload" in libreboot (with grub payload) works for payloads that are built for coreboot. <fchmmr>But it won't work for chainloading an MBR for instance (which needs a BIOS like SeaBIOS, which libreboot avoids like the plague for several reasons). <civodul>no, i'm fine with the generation of libreboot_grub.cfg <fchmmr>This is actually a good idea, libreboot_grub.cfg. Earlier attempts were made to write grub.cfg for libreboot that attempted to automatically detect a distro and had all kinds of ugly hacks in it. I decided not to merge it. <fchmmr>That was a solution where libreboot changed, but making subtle changes to the distro (eg libreboot_grub.cfg alongside the main grub.cfg, automatically generated by the same scripts) is a much more workable solution. <civodul>fchmmr: i just wonder: what happens when a user has a foobar root file system, which requires GRUB to use the foobar module, which happens not to be compiled in libreboot? <fchmmr>You mean when the user has a filesystem which requires a GRUB module that libreboot's GRUB payload currently does not have? <fchmmr>That's easy: I add the module to libreboot's GRUB payload then issue an update ;) <mark_weaver>civodul: it seems that it should be possible for our libreboot_grub.cfg to 'chainload' our own GRUB executable that's built --with-platform=coreboot <mark_weaver>if we did that, then we could use any modules we like <fchmmr>The user could also do that if they don't mind re-compiling libreboot/grub themselves. <fchmmr>There is an advantage to chainloading another grub.elf (built as a coreboot payload) that is stored on the disk <mark_weaver>I'm trying to find solutions that don't require users reflashing, since many (most?) are deeply uncomfortable with doing so. <fchmmr>namely, that grub.elf can be huge because you most likely have lots of disk space. <fchmmr>There are actually 2 grub configs: grub.cfg and grubtest.cfg <mark_weaver>fchmmr: you are comfortable flashing, because (1) you have a lot of experience doing so, and (2) you have all the hardware you need to recover bricks. <fchmmr>The guide tells the user to modify grubtest.cfg first, and test that. <fchmmr>If that works, it then tells the user to copy the changes into the main grub.cfg and flash again. <fchmmr>(grub.cfg has a menuentry to load grubtest.cfg, and vice versa). <fchmmr>The instructions to test first on grubtest.cfg were added specifically to reduce the possibility of bricks. <mark_weaver>understood, but people are still nervous to do it the first time <civodul>fchmmr: the problem is that you rebuilding/republishing libreboot doesn't scale well, does it? :-) <fchmmr>So the libreboot_grub.cfg will be yet one more step that reduces this problem. <fchmmr>If guix, trisquel, parabola and other distros that libreboot users typically use all do this, then it basically solves the problem. <fchmmr>An easier solution is to use the SeaBIOS payload, but that is not feasible due to limitations in the video bios replacement (referred to in coreboot as "native graphics initialization") on all libreboot targets. <fchmmr>because seabios can't directly load a linux kernel. <fchmmr>It relies on starting a bootloader on the disk which isn't compiled for coreboot (and therefore doesn't know about native graphics init) so it needs a full VBIOS (currently the only feasible way to do this is to have a proprietary video bios extracted from the original firmware) <fchmmr>that is one of the reasons why libreboot uses the GRUB payload, because it works with the framebuffer used by coreboot when using native graphics (free vbios replacement), and since it can directly boot a linux kernel (which also works without a full vbios) it works perfectly - the only issue is usability (users fearing re-flashing their machine for possibility of bricking it). <fchmmr>That being said, GRUB as a payload does have other advantages. For example, you can setup a fully encrypted system where even /boot is encrypted, and put a GPG public key in SPI flash and set it up only to boot kernels signed with the private part of that key <fchmmr>(that, plus a password in grub, can make for an extremely secure machine) <fchmmr>Does guix have guides for setting up a LUKS-encrypted system? <fchmmr>^ I could create a guide like those, for guix <fchmmr>I plan to do one for gnewsense 4 when that is officially released (it will be based on Debian 7.x). <fchmmr><fchmmr> It relies on starting a bootloader on the disk which isn't compiled for coreboot (and therefore doesn't know about native graphics init) so it needs a full VBIOS (currently the only feasible way to do this is to have a proprietary video bios extracted from the original firmware) <fchmmr>^ the native graphics implementations in coreboot lack it completely. bootloaders like syslinux/grub/lilo all need it (when not modified for use as coreboot payloads). <fchmmr>linux kernel / xorg work without int 10h <fchmmr>basically, the native graphics implementation initialize the gpu with the correct data for certain video tasks. kernels with kernel-mode-setting/kms work without a vbios <civodul>(it should, but it is reportedly buggy) <mark_weaver>I really like having GRUB in my flash. it gives me some extra comfort that even if I mess up the bootloader on my disk, I can probably still recover without a rescue disk that I might or might not have on hand. <fchmmr>civodul, supported as in officially supported (documented) or supported as in luks is available and can be configured? <fchmmr>For instance, trisquel "supports" encryption by having it available as an easy option when using the net install <fchmmr>Libreboot also "supports" a few specific targets that are tested and have ROM images built for by the the build scripts, but there are other systems in coreboot that could be built in libreboot (they just aren't, for one reason or another). <mark_weaver>civodul: in other news, I ran into a problem with locales on non-standalone guix where /run/current-system doesn't exist: the login bash can't find the locales, and I don't see how to fix that because it tries to load them before any of the RC files are loaded. *mark_weaver goes afk for a bit <fchmmr><mark_weaver> fchmmr: is there a way for us to make a GRUB that can be loaded by Libreboot's GRUB? not just the config file, but the whole executable? the reason I ask is that's there one problem with this proposal: we have to take it on faith that Libreboot includes the modules we need, and if it doesn't we're stuffed. <fchmmr>have a look in the libreboot build scripts to see how grub is built as a payload. <fchmmr>Specifically, start with builddeps, build and buildrom-withgrub <fchmmr>and the scripts in resources/utilities/grub-assemble/ (called by "build") <fchmmr>Libreboot builds GRUB from src in those scripts, building all the utilities with coreboot-payload in mind. Then grub-mkstandalone is used by the scripts in resources/utilities/grub-assemble/ to create the .elf grub payload executables. <fchmmr>those executables are pointed to in the coreboot .config file, but you can also load them from anywhere from an existing (and running) grub payload. <fchmmr>For example, if you built a grub.elf for coreboot and put it in / on sda1 <fchmmr>in grub you would chainload (ahci0,msdos1)/grub.elf <fchmmr>(I'm fairly sure that this will work) <mark_weaver>so, if it's possible for Libreboot to detect the existence of the grub.elf file, it could chainload it automatically. <mark_weaver>then, you could simply suggest that users install the 'grub-coreboot' package. <fchmmr>Looks like that probably does build a coreboot payload of grub, then. <fchmmr>I didn't think distros would have it, so I didn't bother to check. <mark_weaver>this might actually be a nicer solution. we could avoid libreboot_grub.cfg entirely <fchmmr>I'd still rather use the grub sources from libreboot, though. <fchmmr>Keeping everything locally, I mean. I tend to self-contain everything in libreboot, relying very little (or not at all) on distro packages (the only exception being for build dependencies to compile everything contained in libreboot). <mark_weaver>understood, but since the GRUB configuration and set of GRUB modules is distro-specific, it seems better to easily allow GRUB to be managed and updated by the distro. <fchmmr>That being said, grub-coreboot should be fine. <mark_weaver>and if that could be done with any Libreboot-specific hacks, that would be preferable to my mind. <fchmmr>you can for instance use a coreboot version from 6 months ago with the latest grub from today. <fchmmr>the coreboot-grub in trisquel 7 is probably ok. <fchmmr>Personally, I still think a full libreboot_grub.cfg is more sane. <fchmmr>You'd still need it for the chainloaded coreboot payload of grub.elf that is stored on disk <fchmmr>So chainloading a grub.elf from disk might be a bit redundant (I could be wrong). <mark_weaver>fchmmr: it's not important. I'm okay with libreboot_grub.cfg. I just thought it would be nice if users could simply install 'grub-coreboot' without having to add an extra file. but it's not important. *jgrant is writing a sample GSD config he plans on distributing. Is "GSD-0.8.X" a decent hostname? <jgrant>So, iw is preferred over wireless-tools now? <jgrant>Is there a decent way to in a config, to write something like an a .xsession file? <jgrant>Or maybe just a good way to define running ratpoisoin, directly from slim? <civodul>by default slim proposes two different session types: ratpoison or WM <civodul>you can choose with F1 from the slim screen *jgrant needs to look into it; he'll be installing it on his test box again today or tomorrow. *jgrant will bbl, going to install on testbox in a few. o/ <rekado>jgrant: re dots: some tools assume that it's okay to shorten the name to the part before the first dot (when printing info). Don't remember which did this, but since I discovered this I avoid names with dots. <jgrant>rekado: I mean, if it does come to that -- that would shorten "GSD-0.8.X" too "GSD-0" which would still be accurate in that it's a prerealease. :^P <jgrant>That being said, what alterantives would one be able to do for this? <jgrant>Ah, it looks like Bash defaults to "breaking at dhe dot" ... <jgrant>Hm, not sure how to get around this then. <rekado>why purpose does the version number in the hostname serve? <jgrant>rekado: So people know it's a prerelease? <rekado>to put this in the prompt I can understand, but the hostname? <jgrant>rekado: Where else would it be blatantly apparent? <jgrant>It's trivial for people to replace. <jgrant>Eh, I guess I can leave it out and put it in the license header or something. <jgrant>Yeah, I guess this is good enough. ;; os-config.scm : GSD Sample Config for Guix 0.8.X. <mark_weaver>I suspect there will be problems if your hostname includes a dot, because it might be interpreted as a domain name. <mark_weaver>I'm not sure how things will cope with that. I would expect breakage. <jgrant>mark_weaver: Yeah, I just sided with rekado. Just leaving the hostname pure "GSD". <jgrant>With the intention that people will figure out the relevant fields and replace stuff. <jgrant>Yeah, I'm zonked ... I'll probably install tomorrow; If not, 100% by the end of the weekend. <jgrant>GSD is going to be my primary computer, when not connected to my aptly put together treadmill desk rig. <DusXMT>Does anyone remember the custom package path? I forgot it, and I can't find it in the docs... *jgrant has also been considering writing a very simple gui, in ncurses, for wpa_supplicant. <DusXMT>mark_weaver: thanks, I'll write it down this time :) <mark_weaver>DusXMT: it's relatively easy to find in the "Programming Index", if you know that it starts with GUIX_