Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marcus Linsner: > On Thursday, September 27, 2018 at 7:15:30 PM UTC+2, Rusty Bird wrote: > > Marcus Linsner: > > > I haven't yet tried installing an .iso because I need to get an > > > empty disk, probably next week, then I'll be back here with > > > report(s) :D and re-read Marek's post/apply it... > > > > Sure, no rush. > I'm having second thoughts about using btrfs instead of ext4 now > that it's the 2nd time that I've lost files on an Arch Linux laptop > due to some btrfs-related kernel crash(oops with 4.19-rc5 now, in > some zstd code). Ouch, that sounds stressful. By all means, stick to what works for you! > In both cases though it happened with -rc kernels, so I guess I had > that comming :D > [...] > That commit=300 in fstab made things worse also. Hmm ya, probably best to avoid the newest btrfs code and any less common or aggressive options. FWIW, I've never had serious issues with the LTS kernels, default mount options + noatime, and plenty of free space. > Maybe I should just do periodic snapshots On Qubes, I've noticed that if there's more than a handful of whole- filesystem snapshots (though it's not necessarily the number, but the amount of diverging data that seems to be the trigger), sooner or later the whole system slows down a lot. YMMV. But even one snapshot is super helpful to recover from minor user error. And on the rare occasion that I need some older data, I fish it out of secondary storage with qvm-backup-restore. > How do you do your backups? Nothing fancy, just full qvm-backup runs every couple of... decades. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJbr2zxXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf/eMQAIzEoB0KqLQCqpm+iHzrA9tm k3yckoXPDfMxXUupfXQ7nNZNjOUXHG88Dftd66DZFszMtFIC6Hg58HjcvbgYe23k NtoJTZOfLwMt6s74U9ZboHK0r8xGCX2x42qCFY2GYep0+V2aWytNHxJfoYgLRXzN 3FplocBnIb5IrNL6jRV0/HotZYakdzLz9JpVthnNkKLuibZ3StXQAZ9gzsVccyYi gf/yfePf0d6DBlxwE50Sha5+NkXW3/pnKyZsS7NlTp44G2iCbiMgegYiksG11TMn SzVDuIf3oWUgjxDwD+wtHYAnASaXCAg/tCKVNvlLz0Zk1URMJ/xdwRbC8UzNodLY SAjUENOzRGLfOCF4r2xW7pU4RXHq55rr4TitZmvvzqFnBcNlcwXpY3I6IOoyGQGa ud7f9LcREjQBopnUwiwUnFT35l5fu3Ypux7NO1O17FT63eBoryJrgx6l3w5mam4Z ozYdd5ua02X/a1rI+KY+kdKBCBKgDO8W6/u/yKUxxzfkOsRLjonMXV1k5ZinxRfd QPSyMkbmQZpV2Mb4hZn7Ui07SGC3K+TrB3sa0+tkGwdi18n27UBNLyXFqSma+ZhZ rMLBwLQVA9I54S5xjjGQCHxeJQJP/yhXINsij5GdrlY56BX73Yf0dwke7pBIKHDp 8nHiLsEd0Skb0PjJNupB =uEnf -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180929121545.GA1149%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
On Monday, September 24, 2018 at 9:30:50 PM UTC+2, Marcus Linsner wrote: > On Monday, September 24, 2018 at 1:38:00 PM UTC+2, Rusty Bird wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Marcus Linsner: > > > Can I maybe still use audit=0 ? ie. another way to fix the above > > > error? because I don't want to see the audit spam on dmesg (mainly > > > due to journal being sync-ed to disk, seemingly every time). > > > > That audit spam shouldn't trigger a disk sync (because it doesn't have > > CRIT/ALERT/EMERG priority), according to the journald.conf manpage: > > > > | SyncIntervalSec= > > | The timeout before synchronizing journal files to disk. After > > | syncing, journal files are placed in the OFFLINE state. Note that > > | syncing is unconditionally done immediately after a log message of > > | priority CRIT, ALERT or EMERG has been logged. This setting hence > > | applies only to messages of the levels ERR, WARNING, NOTICE, INFO, > > | DEBUG. The default timeout is 5 minutes. > > > > If it does, might be worth filing a systemd bug. > > Maybe it's a dom0 feature? patch added by qubes? (i doubt it but hey) > > It doesn't seem to happen in a Fedora 28 VM, but on dom0 (Fedora 25), I can > dupe it with these steps: > 1. in a terminal: dmesg --raw -w > 2. in another terminal: sudo iotop > 3. in a 3rd terminal: logger I cannot reproduce these with `sudo iotop -to` and no audit=0 in /proc/cmdline, even with vanilla official qubes kernel 4.14.67-1 I mean, systemd-journal does a Total DISK WRITE but not an Actual DISK WRITE which is only done by jdb2/dm-4-8 every 5 seconds, which makes sense as you said, Rusty, commit= being 5 sec by default for ext4! So I don't know why I remembered that even the actual disk write was being made in the same 1 second instance. It's definitely not true since it clearly only happens every 5 sec. Glad to see that I was wrong, else it would've been weird. And thanks to you Rusty Bird, now I know it's the commit= (man ext4) which causes the sync. Good stuff! > > every time you press Enter in [3.] you see systemd-journald making a write in > [2.] (and you see the loglevel 5 message on [1.], except in Fedora 28 but may > be my systemd .conf settings(see below)) (in [2.] "Actual DISK WRITE" is like > 15KB) > > Practically when audit=0 doesn't exist in xen.cfg for me(*), and I've xfce > panel plugin "Sensors plugin" set to refresh every 5 sec, then it spews 3 > lines dmesg every 5 seconds and does a disk write(actual disk write, so I > assumed sync/flush), 3 lines like these: > > <5>[ 521.639294] audit: type=1100 audit(1537814876.977:451): pid=5406 > uid=1000 auid=1000 ses=2 msg='op=PAM:authentication grantors=pam_localuser > acct="root" exe="/usr/sbin/userhelper" hostname=? addr=? terminal=? > res=success' > > <5>[ 521.639418] audit: type=1101 audit(1537814876.977:452): pid=5406 > uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_permit > acct="root" exe="/usr/sbin/userhelper" hostname=? addr=? terminal=? > res=success' > <15>[ 521.640091] userhelper[5406]: running '/usr/sbin/hddtemp -n -q > /dev/sda' with root privileges on behalf of 'ctor' > > * it actually syncs to disk even when audit=0 does exist in /proc/cmdline > because then I still get to see the level 15 message from above, and the > logger reproduction steps still work, obviously. I've to hide the disk > temperature in Sensors plugin to actually stop the every 5 sec disk sync due > to that log level 15 new dmesg line. > > Since it doesn't happen in Fedora 28, and Fedora 25 in dom0's systemd is too > old, I can't report a bug. It's possibly fixed anyway. > > In /etc/systemd/journald.conf I've the uncommented "#SyncIntervalSec=5m" > which means it's at its default value. > > I'm not sure what level is 5, but I see these: > /* We show everything that is MORE important than this.. */ > #define CONSOLE_LOGLEVEL_SILENT 0 /* Mum's the word */ > #define CONSOLE_LOGLEVEL_MIN 1 /* Minimum loglevel we let people use */ > #define CONSOLE_LOGLEVEL_QUIET 4 /* Shhh ..., when booted with "quiet" */ > #define CONSOLE_LOGLEVEL_DEBUG 10 /* issue debug messages */ > #define CONSOLE_LOGLEVEL_MOTORMOUTH 15 /* You can't shut this one up */ > > in > /home/user/qubes-builder/chroot-fc25/home/user/rpmbuild/BUILD/kernel-latest-4.18.9/linux-4.18.9/include/linux/printk.h > > Oh wait, it's actually in linux/kern_levels.h > #define KERN_EMERG KERN_SOH "0" /* system is unusable */ > #define KERN_ALERT KERN_SOH "1" /* action must be taken immediately */ > #define KERN_CRIT KERN_SOH "2" /* critical conditions */ > #define KERN_ERR KERN_SOH "3" /* error conditions */ > #define KERN_WARNING KERN_SOH "4" /* warning conditions */ > #define KERN_NOTICE KERN_SOH "5" /* normal but significant condition */ > #define KERN_INFO KERN_SOH "6" /*
Re: [qubes-devel] Build ISO from official uploaded packages?
On Thursday, September 27, 2018 at 7:15:30 PM UTC+2, Rusty Bird wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Marcus Linsner: > > On Tuesday, September 25, 2018 at 3:13:19 PM UTC+2, Rusty Bird wrote: > > > Rusty Bird: > > > > Marcus Linsner: > > > In other words, `systemd-journald` causes a write as `Total DISK > > WRITE`, but not a sync/flush to disk, so not `Actual DISK WRITE:` , > > then at at most 5-10 sec later `[jbd2/dm-4-8]` is the one that > > causes the sync/flush aka `Actual DISK WRITE:` ! > > 5 seconds is the ext4 default commit interval (see commit= mount > option in the ext4 manpage), so that looks normal to me. OTOH I see > similar timings on btrfs, which supposedly has a 30 second default. > Strange. Great info! I see that with btrfs(on laptop) I've had commit=300 instead xD > > > > > > Maybe's something else I've changed, however I do remember seeing > > > > > the HDD led blink every second after a new Qubes 4.0 install just > > > > > after setting Sensors to refresh every 1 second. > > > > > > > > That's probably just your LED visualizing that the Sensors hard disk > > > > temperature command communicates with the disk (even though it's not a > > > > substantial write). You can test this by running 'hddtemp' in a root > > > > shell. > > Great idea! Thanks! > > From idle state (see the above iotop idle state), the following is > > the only thing that changes for only one refresh(5 sec): > > Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s > > Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s > > The thing is, if your LED is working like mine, it's still going to > blink every time you run 'hddtemp', even though no data is written to > disk. Just a false positive. Yes, I can confirm this even on the laptop. I guess any "talk" with the drive over the (SATA)wires is reflected by the LED. It makes sense, of course. So then, it was the 5 sec ext4 commit= that I was actually writing to disk only every 5 sec. The rest was just the led. All that with default systemd settings and all. The second part of all that was, likely, my modified systemd/sysctl/xen.cfg settings which were causing the Actual Disk Write(reported by iotop) on every dmesg/journald message. (I haven't rechecked though! but it seems to be the case, since this one was immediate, with iotop 1 sec refreshes) Thanks! > > > I haven't yet tried installing an .iso because I need to get an > > empty disk, probably next week, then I'll be back here with > > report(s) :D and re-read Marek's post/apply it... > > Sure, no rush. I'm having second thoughts about using btrfs instead of ext4 now that it's the 2nd time that I've lost files on an Arch Linux laptop due to some btrfs-related kernel crash(oops with 4.19-rc5 now, in some zstd code). In both cases though it happened with -rc kernels, so I guess I had that comming :D The first time was the entire partition unmountable, so I lost everything. But this time only this: 21k files became 0 bytes, files like /bin/mount(because I've updated/reinstalled util-linux package like 20mins earlier). btrfsck --repair didn't fix it (it did say it fixed some other things though). So, I'm thinking with ext4 I'll at least avoid losing files because it's unlikely to crash in btrfs/ext4 code like that. On the other hand, I do want that compression...(why do I have the feeeling that ext4 has one too, without looking whether it is so or not) I haven't decided yet. I do have a backup of the whole partition but I've changed stuff since I've made it, stuff which I'd rather not re-create again, but I clearly have to now :) I've a backup of some text files(like PKGBUILD, *.patch, scripts) that I've changed since the partition backup, but haven't thoroughly checked to see if I did indeed back up all of them. That commit=300 in fstab made things worse also. Every file that got updated/writtento since the last sync (ie. 5mins ago? though for util-linux, its files got updated like 20mins ago, and they all still:) became 0 bytes. The bad part is that after that kernel crash(general protection fault I think, in zstd code; I couldn't save the error anywhere, just look at it in dmesg), any file that I tried to save afterwards became 0 bytes (seen this after the recovery-attempt phase ie. booted from usb stick with mounting ro then btrfsck then mounting ro; so /etc/hosts is 0 bytes too now lol). So now, to avoid the above, I guess I'll have to ensure that panic on oops is set(CONFIG_PANIC_ON_OOPS, and CONFIG_PANIC_TIMEOUT [=-1]), instead of allowing kernel/system to continue, which means I'll have no idea what crashed since dmesg won't be saved anywhere, or journal sync'd(or maybe if I make all the same systemd/sysctl/xen.cfg changes on this Arch Linux laptop that I made in the Qubes computer it will sync on every new dmesg line? hmm, HMM... I should recheck to see what really causes the sync), and worst of all depending
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marcus Linsner: > On Tuesday, September 25, 2018 at 3:13:19 PM UTC+2, Rusty Bird wrote: > > Rusty Bird: > > > Marcus Linsner: > In other words, `systemd-journald` causes a write as `Total DISK > WRITE`, but not a sync/flush to disk, so not `Actual DISK WRITE:` , > then at at most 5-10 sec later `[jbd2/dm-4-8]` is the one that > causes the sync/flush aka `Actual DISK WRITE:` ! 5 seconds is the ext4 default commit interval (see commit= mount option in the ext4 manpage), so that looks normal to me. OTOH I see similar timings on btrfs, which supposedly has a 30 second default. Strange. > > > > Maybe's something else I've changed, however I do remember seeing > > > > the HDD led blink every second after a new Qubes 4.0 install just > > > > after setting Sensors to refresh every 1 second. > > > > > > That's probably just your LED visualizing that the Sensors hard disk > > > temperature command communicates with the disk (even though it's not a > > > substantial write). You can test this by running 'hddtemp' in a root > > > shell. > Great idea! Thanks! > From idle state (see the above iotop idle state), the following is > the only thing that changes for only one refresh(5 sec): > Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s > Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s The thing is, if your LED is working like mine, it's still going to blink every time you run 'hddtemp', even though no data is written to disk. Just a false positive. > I haven't yet tried installing an .iso because I need to get an > empty disk, probably next week, then I'll be back here with > report(s) :D and re-read Marek's post/apply it... Sure, no rush. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJbrRAAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfmcsP/0dvfHQWQcRidOlkU9NVpHdg wsC77rZaMLR/ljm/8sSbfGugTLTznSth18++8f6YtctCv05K9QNb5e3KD2SuIw4j Viq2iVuYuqUBSHAFEQYWf2OZJeLjBQxCkwO76KKGQcw0AwXCRCWyTlXetPykZYbL TXuValFPvgdkb59B0IFZpnMw/jZwUmQJx/UZGm5kUyO8H3yWNiIQp3ipwceuKhvf 9L7Pg/+fZ+5j28oLpVwH9gyBvklvPqqJWfzPjnkPQKRN13/SGV9T92zwTE3n5Fl3 XHtZXNNa+vPcaEfViqA511PadD8fwHmHQIuCvr6bySDEhpAdF6lHxmhKB14c/WAO J/JAwVYzVyGw/ct3buCucKo1436mpzbeUN+ErCKiOOkEpeANQCOqWIMgpQwyRpRb H0pIhJ4h+N7f+0Y4wi1MGeWeOots+4IoGTdc4DylKdHIaFrBn/AXtwc4pZyXvyFy IPqOwH+Th1yB5fHUgQHHkQrVsp2iUToND1cajdeCGZ4h9j2gcRK+DoXfnafD73HM gtnW6sUr3wNCTVGXfOEZk218wxRkx/IbQnHedEnp7CdTUbA7A5WhtDKSG3IYlmDH iNI4fu+m7Wi0irdnPQE4gFQUOeVpnFjJkJjfw38QUQYJg8wYQs67FtKG8woyuoPA ibtKw9RbLnFLc9qZlhA/ =lCQE -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180927171440.GA929%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rusty Bird: > Marcus Linsner: > > 2. in another terminal: sudo iotop > > 3. in a 3rd terminal: logger > > > > every time you press Enter in [3.] [...] "Actual DISK WRITE" is like > > 15KB) > > I can't reproduce this in my dom0, which has vanilla journald.conf/ > sysctl values and kernel/Xen parameters. "Actual DISK WRITE" remains > at zero when I log a line. > > > In /etc/systemd/journald.conf I've the uncommented > > "#SyncIntervalSec=5m" which means it's at its default value. > > > > I'm not sure what level is 5 [...] > > "5m" = 5 minutes, i.e. EMERG/ALERT/CRIT level messages are synced to > disk immediately and other messages once every 300 seconds. Oops, sorry - I thought you had mixed up the log interval and the log priority, but now I see you were referring to the dmesg lines prefixed with <5> in your post. Those would be level NOTICE, so they should not cause an immediate sync. > > Maybe's something else I've changed, however I do remember seeing > > the HDD led blink every second after a new Qubes 4.0 install just > > after setting Sensors to refresh every 1 second. > > That's probably just your LED visualizing that the Sensors hard disk > temperature command communicates with the disk (even though it's not a > substantial write). You can test this by running 'hddtemp' in a root > shell. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJbqjRmXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrforUP/3DChOxeOfZFjKqyf+OuW8rF cMX/yjFzufap7vjX0yikndre9h4Zdynw/5CM1T0t4qUDG1sdbKxxxJo8W0i/+cVm hfFWf+0XiW9tryOkx6m7Rd544YHfE5c895T46RFKKbkr4Fzr0iadkEknv1soS8N9 MNGL4yufiX9z24s+da8MBdprmN5bdrGmiIxGKKAvVmP18JmD02QrUiXdVem/unsk so/F2hgEjsNHpjMMetZO2qu53Q7y5h5d7s7yvvzYJ338VrkfqWWjxDQDFXWzymWY 1nvX4SpUM0bWPzpfVW/rjsBxcVxH9wSPzmDMagXvG5IdA8vGvmZlygImlWcssish jbQ3h5LURxRQh7zwY8L3dia00Ur4L86j+QXAtaGU9+476+ggBXbKgDIcChjXOhjJ K9DMGp6Q/qPHECYSEXoR+QqV+h60dS91Gsf/mG9i5klDEDobm8XJIz5USTifHwVL YdR2G3B9t8AqXtdLOL3yfYpLOyzt3MP1SEq1NnJ6/cB1vqo02CNWS8+HwBPq/Lle f2vHFK6dWDIuUIotIw5AZnEWi+VVJ/rrMwEMQDvjIqzgGxealu2y8RL3F3I4GRly fC+M7ocjoC9ITiOA0La2xMViNN5pVroEWEiukANadwe6qq11lFC+pHR+Mw21Zsb1 lJrPFWNM0EEIYf8cJsXb =5nia -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180925131310.GA2475%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marcus Linsner: > 2. in another terminal: sudo iotop > 3. in a 3rd terminal: logger > > every time you press Enter in [3.] [...] "Actual DISK WRITE" is like > 15KB) I can't reproduce this in my dom0, which has vanilla journald.conf/ sysctl values and kernel/Xen parameters. "Actual DISK WRITE" remains at zero when I log a line. > In /etc/systemd/journald.conf I've the uncommented > "#SyncIntervalSec=5m" which means it's at its default value. > > I'm not sure what level is 5 [...] "5m" = 5 minutes, i.e. EMERG/ALERT/CRIT level messages are synced to disk immediately and other messages once every 300 seconds. > Maybe's something else I've changed, however I do remember seeing > the HDD led blink every second after a new Qubes 4.0 install just > after setting Sensors to refresh every 1 second. That's probably just your LED visualizing that the Sensors hard disk temperature command communicates with the disk (even though it's not a substantial write). You can test this by running 'hddtemp' in a root shell. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJbqWESXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfANMQAJm1KoJekqfR59jiN6T+TCKo nYNYhNF0Ke5CPCrnAEOOOhP0HsZ9jRfIBWAIlgE3xLuoPYwC7Bv+nsPx8IWIe4uK q567hzEZcHnMTRTHB9Z5mKw5e4y5HtmchgFRBzTUWWQFM+ir2vkE0wcsQA4FhIdN 4RhK/kaOGH1QxNYNNxQyu5vly5fdDKipS3Fc2LDytIjqR8vpvV3KgAQX4mQ1Dswc E4FalCOqj/DKR7GnkhuDlAWAESD635rsety3/NG6S69HvnoXRPGRnY6L/6u0c1b3 aIdP+6wZv3IEziOZmb4xoqCCmdScqajVnnNOmw4zr/wmV2gXbNzArDD8SZ2k/dx1 OZ9LzAZLUbQt9npx1F3+oWLe/r+zCqWWvOZXSsW5au0jBbMbVTvrxppgbHrpIPLt tPTi5IUBkI0jacIcTSh69VK1CyBIpiZ6FHd4Arg7/1dEL2LBwR0ZuFYkvAdfKRAy PVzc7EVgeEgk9JTHvwZp/kqPuuIG+yNoSqlaFfpZPVeoBrbEgq3xK/0C/HvQahoz HnVzVt4PFnM3jXMWAUANWFARixecNPMmegzMQINX2HzCYcjvmWm1bO/L0bXOIfx+ msg/gDj0a1R2de4EpZ6z5fO4QVqmPQvBysWsw0wqMi9D+/64DEIroIJczgQtJGOH O+eHHDszWj452vikWbYl =+gnj -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180924221130.GA1288%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Sep 23, 2018 at 07:10:02AM -0700, Marcus Linsner wrote: > On Saturday, September 22, 2018 at 11:55:48 PM UTC+2, Rusty Bird wrote: > > $ gpg --fetch-keys > > https://keys.qubes-os.org/keys/qubes-developers-keys.asc > > $ git clone https://github.com/QubesOS/qubes-builder.git > > $ cd qubes-builder > > $ git verify-commit HEAD || echo DANGER DANGER HIGH VOLTAGE > > $ cp example-configs/qubes-os-r4.0.conf builder.conf > > $ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 > > USE_QUBES_REPO_TESTING=1 > > INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks' > > $ make $variables COMPONENTS='installer-qubes-os builder-rpm' > > get-sources > > $ make $variables COMPONENTS=intel-microcode get-sources qubes > > clean-rpms > > $ sudo chroot chroot-fc25 dnf -y install dnf-yum > > $ make $variables COMPONENTS= iso > > > > If any step fails due to a download error, just rerun it. Unless I > > made a mistake putting everything together (in which case, please say > > so), it should spit out an installer image file in the iso/ directory. > > > > This is amazing! Thanks so much! > > I can't wait to run this in production. (ie. as my main system) So cool! > > > I got an error at this step: `time make $variables COMPONENTS= iso` > Took me a long time to figure out it was because `audit=0` was present in > kernelopts. (...) > subprocess.CalledProcessError: Command '['setfiles', '-e', '/proc', '-e', > '/sys', '-e', '/dev', '-e', '/install', > '/etc/selinux/targeted/contexts/files/file_contexts', '/']' returned non-zero > exit status 255 (...) > Conclusion: audit is necessary(for whatever reason, who wants to guess?) so > I've to make sure audit=0 doesn't exist in /proc/cmdline :) Very interesting find, honestly I have no idea why audit=0 on kernel cmdline change anything in the build process... > Can I maybe still use audit=0 ? ie. another way to fix the above error? > because I don't want to see the audit spam on dmesg (mainly due to journal > being sync-ed to disk, seemingly every time). > > So disk space required is about 12.5G, unless you rerun the `iso` command > after success, then it could go as high as 17.2G or even more for subsequent > runs. Not sure what to clean so it doesn't re-download everything again (like > 393+1069 packages). I think it should be ok to remove qubes-src/installer-qubes-os/work. Most of the cache is in chroot-fc25/var/cache/pungi. > (Note: I've also changed max memory to 14000 MB, after the first time I got > the `setfiles` error) > > I don't suppose there's some way to cache all downloaded rpms in some > intermediate qube, or is there? (sort of like sys-firewall is doing for dom0) > but I mean strictly for these iso building steps, so it would work even after > a clean-chroot or rm -rf qubes-builder. > For now I'm just copying the ./chroot-fc25/var/cache/ dir (it's 5.3G > according to `du`). > > The mirror is ukfast and found within these 2 files(which are identical): > ./qubes-src/installer-qubes-os/conf/travis-iso-full.ks > ./chroot-fc25/home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks > Is there another mirror that can be chosen? (sometimes it's limited to max > 2MBit/sec and it takes like 4G of downloads after a `make clean-chroot`) Yes, see here: https://www.qubes-os.org/downloads/#mirrors This one is there because it works good in travis build env. > Is there some way to avoid downloading some templates like whonix(which I > don't plan on using ever) ? You can try editing conf/qubes-kickstart.ks, specifically removing @whonix. But it may cause build or installation to fail. > More questions :) > > Why is this nonexistent file used: > /tmp/qubes-installer/conf/travis-iso-full.ks > instead of any of these existing ones: > ./qubes-src/installer-qubes-os/conf/travis-iso-full.ks > ./chroot-fc25/home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks > > context: > /bin/sh: line 1: 1370 Killed pungi --name=Qubes --nosource > --nodebuginfo --nogreedy --all-stages --ver="20180923" -c > /tmp/qubes-installer/conf/travis-iso-full.ks > > and > $ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 > USE_QUBES_REPO_TESTING=1 > INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks' > > (I used `find` and it's nonexistent in chroot either, or in real /tmp) It is a symlink _inside_ chroot. Specifically if it points to /home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks, if you look at it from outside it probably will look like a broken link, because the path is different from the outside. But you can use /home/user/qubes-src/installer-qubes-os/conf/travis-iso-full.ks path directly. > Another question: > if I have my own kernel[1], do I compile it after this step `$ make > $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms` ? > and then I execute `$ make
Re: [qubes-devel] Build ISO from official uploaded packages?
On Saturday, September 22, 2018 at 11:55:48 PM UTC+2, Rusty Bird wrote: > $ gpg --fetch-keys > https://keys.qubes-os.org/keys/qubes-developers-keys.asc > $ git clone https://github.com/QubesOS/qubes-builder.git > $ cd qubes-builder > $ git verify-commit HEAD || echo DANGER DANGER HIGH VOLTAGE > $ cp example-configs/qubes-os-r4.0.conf builder.conf > $ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 > USE_QUBES_REPO_TESTING=1 > INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks' > $ make $variables COMPONENTS='installer-qubes-os builder-rpm' get-sources > $ make $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms > $ sudo chroot chroot-fc25 dnf -y install dnf-yum > $ make $variables COMPONENTS= iso > > If any step fails due to a download error, just rerun it. Unless I > made a mistake putting everything together (in which case, please say > so), it should spit out an installer image file in the iso/ directory. > This is amazing! Thanks so much! I can't wait to run this in production. (ie. as my main system) So cool! I got an error at this step: `time make $variables COMPONENTS= iso` Took me a long time to figure out it was because `audit=0` was present in kernelopts. ... Complete! -> Building installer-qubes-os iso for fc25 (logfile: build-logs/installer-qubes-os-iso-fc25.log)... --> build failed! return execWithRedirect(cmd[0], cmd[1:], **kwargs) File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 228, in execWithRedirect env_add=env_add, reset_handlers=reset_handlers, reset_lang=reset_lang)[0] File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 201, in _run_program raise subprocess.CalledProcessError(proc.returncode, argv, output) subprocess.CalledProcessError: Command '['setfiles', '-e', '/proc', '-e', '/sys', '-e', '/dev', '-e', '/install', '/etc/selinux/targeted/contexts/files/file_contexts', '/']' returned non-zero exit status 255 Makefile:58: recipe for target 'iso-installer' failed make[1]: *** [iso-installer] Error 1 make[1]: Leaving directory '/home/user/qubes-src/installer-qubes-os' make: *** [Makefile:519: iso] Error 1 real12m31.230s user4m20.275s sys 0m51.076s In `build-logs/installer-qubes-os-iso-fc25.log` it shows: ... 2018-09-23 06:15:41,475: verifying the installroot verifying the installroot 2018-09-23 06:15:43,721: creating the runtime image creating the runtime image Traceback (most recent call last): File "/usr/sbin/lorax", line 283, in main() File "/usr/sbin/lorax", line 133, in main remove_temp=True, verify=opts.verify) File "/usr/lib/python3.5/site-packages/pylorax/__init__.py", line 327, in run size=size) File "/usr/lib/python3.5/site-packages/pylorax/treebuilder.py", line 197, in create_runtime "Anaconda", size=size) File "/usr/lib/python3.5/site-packages/pylorax/imgutils.py", line 120, in mkrootfsimg runcmd(cmd, root=root) File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 341, in runcmd return execWithRedirect(cmd[0], cmd[1:], **kwargs) File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 228, in execWithRedirect env_add=env_add, reset_handlers=reset_handlers, reset_lang=reset_lang)[0] File "/usr/lib/python3.5/site-packages/pylorax/executils.py", line 201, in _run_program raise subprocess.CalledProcessError(proc.returncode, argv, output) subprocess.CalledProcessError: Command '['setfiles', '-e', '/proc', '-e', '/sys', '-e', '/dev', '-e', '/install', '/etc/selinux/targeted/contexts/files/file_contexts', '/']' returned non-zero exit status 255 Makefile:58: recipe for target 'iso-installer' failed make[1]: *** [iso-installer] Error 1 make[1]: Leaving directory '/home/user/qubes-src/installer-qubes-os' Here's the space usage in /rw: Filesystem 1K-blocks Used Available Use% Mounted on /dev/xvdb 20140648 10474736 9649528 53% /rw This qube has: Initial memory: 1400 MB Max memory: 4000 MB VCPUs no.: 2 [v] Include in memory balancing Kernel: 4.18.9-1 (from [1]) [ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts nopat sysrq_always_enabled audit=0 ipv6.disable=1 rd.luks.options=discard root_trim=yes rd.luks.allow-discards loglevel=15 log_buf_len=16M printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=0 memory_corruption_check=1 pax_sanitize_slab=full systemd.log_target=kmsg systemd.journald.forward_to_console=1 udev.children-max=1256 rd.udev.children-max=1256 it has no swap(disabled in kernel) and this isn't otherwise a clean fedora-28 template (I don't even remember what else I've changed in /etc and packages installed) So either of these doesn't cause the above `setfiles` error: [ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts nopat [ctor@dom0 ~]$ qvm-prefs --get dev02 kernelopts nopat rd.luks.options=discard root_trim=yes rd.luks.allow-discards loglevel=15 log_buf_len=16M printk.always_kmsg_dump=y
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marcus Linsner: > Any chance you could post full steps? like from a newly created qube > based on a fedora-28 template for example. Sure, here you go: $ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-developers-keys.asc $ git clone https://github.com/QubesOS/qubes-builder.git $ cd qubes-builder $ git verify-commit HEAD || echo DANGER DANGER HIGH VOLTAGE $ cp example-configs/qubes-os-r4.0.conf builder.conf $ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 USE_QUBES_REPO_TESTING=1 INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks' $ make $variables COMPONENTS='installer-qubes-os builder-rpm' get-sources $ make $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms $ sudo chroot chroot-fc25 dnf -y install dnf-yum $ make $variables COMPONENTS= iso If any step fails due to a download error, just rerun it. Unless I made a mistake putting everything together (in which case, please say so), it should spit out an installer image file in the iso/ directory. > I'd be very interested into building(and testing) an iso with all of this: > "Rusty Bird have done excellent work and contributed file-reflink storage > driver[20], making use of copy-on-write feature of btrfs, instead of > building device-mapper layer on plain files. > - From now on (including Qubes OS 4.0.1) if you choose btrfs partitioning > layout, by default file-reflink driver will be used. Existing > storage pools are not affected by this change. " > ^ from: https://groups.google.com/d/msg/qubes-devel/MakHbJKbfwk/1PMvmjf3CQAJ > > I wonder if that means what I think it means: no more lvm/thin pools > and instead only btrfs? That'd be crazy good :D (tbh, I'm not even > sure if it makes sense) No, you're right. The only thing you have to do is choose the btrfs layout in your shiny new installer: - On the "Installation Destination" screen, select "I will configure partitioning." and press "Done". - Enter and confirm your desired passphrase. - Switch the drop-down menu from "LVM Thin Provisioning" to "Btrfs". - Press "Click here to create them automatically." and "Done". - Confirm your passphrase again for some reason. - Accept the inscrutable "Summary of Changes". This assumes that the destination hard drive is completely empty. If not, try the "I would like to make additonal space available" option on the "Installation Destination" screen. Let me know if everything works. You'd probably be the second regular user of the file-reflink driver in this particular universe. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJbprgDXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfGPoQAI8KG/sPJQSy2vvFi4p33Pxv qQQ4uTKC6nQCdqFKBDJkv1AWvATVr6WxE4s2NyU10tfAJ3lS/v/xFtZ5wM6LyrT0 6N5aq932HDmBV4qwa18y2mOXxFuzrUEYJuEgObBhMQC1D6We/gIBgyRLYZ85ekpn R0Zgst+haFyU5qI9KEEYrvLl+MzaNAJcGY3NyLetkKbqaW5e7eUhJTo59pN1HMHs 4MXAEMy6NInoDETK31UKavbMzRNA0kx6h9KPE8kLwEwhJtOiCJBFRmFDwvuAp3yL GlTPct3MWFRB7g63VMXel2/YxFhUeZlWXd9M0bA7quBdJq79c/pDvwujZONHtw6Z sbDDLpuataPevTn+j9+RkGTaDXdnpS+vd9oopiJEywbvk8bWvDP/MIESwVLedmMx T17Qu+OjvUV+pkQre3KRTO7L2eDvUdfGp7Bm2iIwdiwK+ymbBFfBprXAGxv3ojHs nXinNwAy1FJp/wfifB4IQ4E/UGZxOSVHSe+sgZjf8l/ctRhxGT7e8vnKsGML8W/0 ewHOYmfq/rRJChVi5cX7AhldAQlrZMzdlrxiAe57Dl8DrEj0R6h6Q3paLD5/ewiJ GQ4rttSWoZlhl+6Gvrwgp0aTzQ4m19xAbxgdKM5/sljka2x7JcPoBlGE4ygP60yI 8DaX8A4yfu7q32IyCNOS =VsyN -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180922214539.GA983%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
On Friday, September 21, 2018 at 10:27:47 PM UTC+2, Rusty Bird wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Marek Marczykowski-Górecki: > > On Fri, Sep 21, 2018 at 11:48:17AM +, Rusty Bird wrote: > > > Now, if I run > > > > > > $ make iso > > > > > > it fails with: > > > > > > -> Installing installer-qubes-os build dependencies in fc25 > > > environment > > > chroot: failed to run command ‘yum’: No such file or directory > > > make: *** [Makefile:519: iso] Error 1 > > > It should use dnf... Anyway try this: > > > > sudo chroot chroot-fc25 dnf install dnf-yum > > That did the trick, thank you. > > Rusty > -BEGIN PGP SIGNATURE- > > iQJ8BAEBCgBmBQJbpVQsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 > NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfjZEP/jPxy6nsSmC6Y8cJoOaWfwYl > xNtAensAbI+0um6pMPlmvJc1q5zDY9AgZGo8kWAzEUMA88CvJyC1xuW23zZtxlwu > 13H2dyRALmxFda73s23IKhutxadARYTPv60GyJnXd9DUHM/ppXkiyMlZjcpq0jNo > pR3bqEQpM8D1L8AugjVmHmO7LkZQ892WoSswYJDVC0jvHIydaIYzNhkx83IpbQ8o > MnDHI6mlDzUm7C+UQCN7uX8DbrQZA+UpYJkzXBFVTGM/nhzVR7k44m1V6NbFMLI1 > MaX+37EarkQCHGtCJZXGxlqGk9RZQMjmRxqUROW8mKvAOlDWvPXY0lHzspCblA4A > zJHfSmYlyRnK3GApeBtwrROA5btzf1oWiOci3TT2VFctEz1KjlV3lua/8/b13RX+ > fqa49Fyr2f8uiJvmZEnaEz84SLjJwomclBRPblnW33HKAZM0v6V8LAyAgImESmut > g/TY4fGh8hVrSuOahvoXk61FGXYTrMeo7qKFGnVaUAbFKUfF9bbbATRSiDtO7QPx > /x8hVe4cST6EQ/3kp4LNmOY85czkJlTnPqJoSWbucvB5k2dRdiDCT8n5j2FsmjE7 > xJfZYJEM3eItZXO/1Orme4sczb/TrlYji1U1MjbuhilN7TlNhubXZtlE92g5o1GM > uD2dZrjHVlXOD1yweUOY > =0WqO > -END PGP SIGNATURE- Any chance you could post full steps? like from a newly created qube based on a fedora-28 template for example. I'd be very interested into building(and testing) an iso with all of this: "Rusty Bird have done excellent work and contributed file-reflink storage driver[20], making use of copy-on-write feature of btrfs, instead of building device-mapper layer on plain files. - From now on (including Qubes OS 4.0.1) if you choose btrfs partitioning layout, by default file-reflink driver will be used. Existing storage pools are not affected by this change. " ^ from: https://groups.google.com/d/msg/qubes-devel/MakHbJKbfwk/1PMvmjf3CQAJ I wonder if that means what I think it means: no more lvm/thin pools and instead only btrfs? That'd be crazy good :D (tbh, I'm not even sure if it makes sense) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/554f043e-591d-404b-aa30-45863e61f4dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marek Marczykowski-Górecki: > On Fri, Sep 21, 2018 at 11:48:17AM +, Rusty Bird wrote: > > Now, if I run > > > > $ make iso > > > > it fails with: > > > > -> Installing installer-qubes-os build dependencies in fc25 environment > > chroot: failed to run command ‘yum’: No such file or directory > > make: *** [Makefile:519: iso] Error 1 > It should use dnf... Anyway try this: > > sudo chroot chroot-fc25 dnf install dnf-yum That did the trick, thank you. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJbpVQsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfjZEP/jPxy6nsSmC6Y8cJoOaWfwYl xNtAensAbI+0um6pMPlmvJc1q5zDY9AgZGo8kWAzEUMA88CvJyC1xuW23zZtxlwu 13H2dyRALmxFda73s23IKhutxadARYTPv60GyJnXd9DUHM/ppXkiyMlZjcpq0jNo pR3bqEQpM8D1L8AugjVmHmO7LkZQ892WoSswYJDVC0jvHIydaIYzNhkx83IpbQ8o MnDHI6mlDzUm7C+UQCN7uX8DbrQZA+UpYJkzXBFVTGM/nhzVR7k44m1V6NbFMLI1 MaX+37EarkQCHGtCJZXGxlqGk9RZQMjmRxqUROW8mKvAOlDWvPXY0lHzspCblA4A zJHfSmYlyRnK3GApeBtwrROA5btzf1oWiOci3TT2VFctEz1KjlV3lua/8/b13RX+ fqa49Fyr2f8uiJvmZEnaEz84SLjJwomclBRPblnW33HKAZM0v6V8LAyAgImESmut g/TY4fGh8hVrSuOahvoXk61FGXYTrMeo7qKFGnVaUAbFKUfF9bbbATRSiDtO7QPx /x8hVe4cST6EQ/3kp4LNmOY85czkJlTnPqJoSWbucvB5k2dRdiDCT8n5j2FsmjE7 xJfZYJEM3eItZXO/1Orme4sczb/TrlYji1U1MjbuhilN7TlNhubXZtlE92g5o1GM uD2dZrjHVlXOD1yweUOY =0WqO -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180921202724.GA2252%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Sep 21, 2018 at 11:48:17AM +, Rusty Bird wrote: > Marek Marczykowski-Górecki: > > On Fri, Sep 21, 2018 at 08:51:52AM +, Rusty Bird wrote: > > > Is there a way to build an up-to-date R4.0 installer ISO from the > > > latest pre-built official packages in current(-testing)? > > > > > > I'd rather not rebuild all of them - just the few for which I have > > > extra patches. > > > > Yes, and it's quite easy. In your builder.conf: > > - clear COMPONENTS (for the build time at least) > > - clear DISTS_VM (unless you want to use local template builds) > > - set USE_QUBES_REPO_VERSION=4.0 > > - optionally set USE_QUBES_REPO_TESTING=1 > > - set INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks > >(file is in qubes-src/installer-qubes-os/conf/, but it's in that path > > inside build chroot) > > > > This will use current-testing repository. If you want "current", edit > > travis-iso-full.ks. > > > > As for COMPONENTS - you still need to download at least > > installer-qubes-os and probably builder-rpm (but I'm not sure if still > > needed). For that, you need to include them in COMPONENTS for `make > > get-sources` call. > > Thanks. I copied example-configs/qubes-os-r4.0.conf to builder.conf, > inserted > > COMPONENTS = > DISTS_VM = > USE_QUBES_REPO_VERSION = 4.0 > USE_QUBES_REPO_TESTING = 1 > INSTALLER_KICKSTART = /tmp/qubes-installer/conf/travis-iso-full.ks > > after the big COMPONENTS block, ran > > $ make COMPONENTS=installer-qubes-os get-sources > > and then > > $ make COMPONENTS=builder-rpm get-sources > $ make COMPONENTS=intel-microcode get-sources qubes > > because builder complained that I need to build at least one fc25 > package to prepare the chroot. (Is there a way to do that without > building a package?) Now, if I run > > $ make iso > > it fails with: > > -> Installing installer-qubes-os build dependencies in fc25 environment > chroot: failed to run command ‘yum’: No such file or directory > make: *** [Makefile:519: iso] Error 1 > > I tried > > $ make COMPONENTS=linux-yum get-sources qubes > > but it didn't help. Looks like I'm missing some step? It should use dnf... Anyway try this: sudo chroot chroot-fc25 dnf install dnf-yum - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAluk3w4ACgkQ24/THMrX 1ywOjQf9EpiFDI3tLPMe/9xpfJh+N3eCacxt5q7Ryo4PfPvU5banMELye1hhUJKu m4JSTuFGpbF3BF2niON3rAiFE9TfNZTKOqOYVnJoCTuDd8V4+9urHXdPovbxFVhp jVE0+iRapIEvPlXur9LB3a1xCv9YDruPAb2vCsVjZpH2BBaf7doooM5jdwh/Cjyv xBaBbmHYOO9XxhEu9D0hilIVX3pFaqCF9cKkcSDy02hZWWFpOtp1pNiPsf3rIvrj /PfhDro7GtDM9FNrUqOJhSjeoGjibjp7PrLczujkLca858mtpMA4xg9Ity52IG4t 5p9YAKtSepGtDzeVvezUtXDrdW91LQ== =fpll -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180921120603.GB1254%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marek Marczykowski-Górecki: > On Fri, Sep 21, 2018 at 08:51:52AM +, Rusty Bird wrote: > > Is there a way to build an up-to-date R4.0 installer ISO from the > > latest pre-built official packages in current(-testing)? > > > > I'd rather not rebuild all of them - just the few for which I have > > extra patches. > > Yes, and it's quite easy. In your builder.conf: > - clear COMPONENTS (for the build time at least) > - clear DISTS_VM (unless you want to use local template builds) > - set USE_QUBES_REPO_VERSION=4.0 > - optionally set USE_QUBES_REPO_TESTING=1 > - set INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks >(file is in qubes-src/installer-qubes-os/conf/, but it's in that path > inside build chroot) > > This will use current-testing repository. If you want "current", edit > travis-iso-full.ks. > > As for COMPONENTS - you still need to download at least > installer-qubes-os and probably builder-rpm (but I'm not sure if still > needed). For that, you need to include them in COMPONENTS for `make > get-sources` call. Thanks. I copied example-configs/qubes-os-r4.0.conf to builder.conf, inserted COMPONENTS = DISTS_VM = USE_QUBES_REPO_VERSION = 4.0 USE_QUBES_REPO_TESTING = 1 INSTALLER_KICKSTART = /tmp/qubes-installer/conf/travis-iso-full.ks after the big COMPONENTS block, ran $ make COMPONENTS=installer-qubes-os get-sources and then $ make COMPONENTS=builder-rpm get-sources $ make COMPONENTS=intel-microcode get-sources qubes because builder complained that I need to build at least one fc25 package to prepare the chroot. (Is there a way to do that without building a package?) Now, if I run $ make iso it fails with: -> Installing installer-qubes-os build dependencies in fc25 environment chroot: failed to run command ‘yum’: No such file or directory make: *** [Makefile:519: iso] Error 1 I tried $ make COMPONENTS=linux-yum get-sources qubes but it didn't help. Looks like I'm missing some step? Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJbpNqBXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfJZ8P/A+g8eViQv7Gz39nzRDjYA6c e9YpuAiRqYX1H1y+bjyfbFzH2qt4TjHxFToACbZrQ1k0fcOTa0Bj4Kb3r6w86LJI Rh8+GkOlKq7XxJeootTAn16S434SzjZCKeeIvn5FjxLHSeIOw/pQ5WVk8qW37oDi fh99LI6FEXLvWsckzCwJCNbuFmEPMiyvtf0fKcjVKnm0UERQ7QNBe1TzqWDG6Ii3 eRua30dm1G7x9tqDmzAMmbgE4DAaOe2wFCosFpcdwHqhb9w+Y2j0Al33ppDge+Dg 8Mk5bFO2xF/pH+OxAEjpf+Uz06ORll+tjXdKKUSKfDDtYS+VuhZgryZtz0/sRGip NLINsJt6aOJ0VHKIEY2pBkUnaiinI5GMhPm8NxAuWQ5cznuMuq6GTj8DAFH7nqGo gUc78pvDeZCgIvCPuILkBJS5HuquGU2Q4n7Ga8hyT3kwyJtzF009CuJe7WpGah/8 nCJFpvPZvsm1b5ouNdIqyDb++HB2nRTfCRS9CT5gRyBE2RP+fmYr3Hgv6myL1r2P MZc2sBVfI36AfqBEv4acKZJ4eXeoTbXaPQ8iaNAtcC/NZoKzh74SLwwo3etjhasQ nT6RYDDDHsCy2XDwMJtH2dRr8HUgz9eyMNIoYEzw4FwbPl9aXTlP9AFKzHHeibFd RGdxATKGmpdV+mUZQBsR =4nYj -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180921114817.GB1633%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Build ISO from official uploaded packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Sep 21, 2018 at 08:51:52AM +, Rusty Bird wrote: > Hi, > > Is there a way to build an up-to-date R4.0 installer ISO from the > latest pre-built official packages in current(-testing)? > > I'd rather not rebuild all of them - just the few for which I have > extra patches. Yes, and it's quite easy. In your builder.conf: - clear COMPONENTS (for the build time at least) - clear DISTS_VM (unless you want to use local template builds) - set USE_QUBES_REPO_VERSION=4.0 - optionally set USE_QUBES_REPO_TESTING=1 - set INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks (file is in qubes-src/installer-qubes-os/conf/, but it's in that path inside build chroot) This will use current-testing repository. If you want "current", edit travis-iso-full.ks. As for COMPONENTS - you still need to download at least installer-qubes-os and probably builder-rpm (but I'm not sure if still needed). For that, you need to include them in COMPONENTS for `make get-sources` call. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlukv8YACgkQ24/THMrX 1yxjdgf/b7xPYjiHq8IPwibzjzhKng/sxwzh+aHkNaPORzaFXPaTdQ0F59/5BomN BcibWuYWoWjIWWP3QIm1/+r5DiHZRlkbFsqXWu6Q9gXhHTCXY8zFCkT6QGtA8A/W 2QmxMM8jNWYtu1mCPwVQODPS+YOFBAj19fwkcpgdzKFPE4SPLqee2cdgkbf+7lgl Yrct5GMpVhw6E2qgJ3R1RorcqFERCT6Tlt4LbytfvKSUIYF+/01p4UtH1nVmmQ2B E/fmJcW+XdKYSCHh138w3ipzC5yK/YqTvUagsy8zDisvfBF75HkCwh3rG4D11Rhp SLPQ9tssQF0A+OwvLlRtuSfkfuaz1Q== =QiT8 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180921095234.GA1254%40mail-itl. For more options, visit https://groups.google.com/d/optout.
