33374 2017-04-13 20:17:26 +0300 Stable rescue image 2017-04-15 00:05:40 +0300 1 1 3 Distributions Regular rescue не указана all Linux CLOSED WORKSFORME http://en.altlinux.org/starterkits P3 enhancement --- 1 will mike cas oldest_to_newest 163218 0 will 2017-04-13 20:17:26 +0300 I use ALT Linux Rescue from time to time. I also use https://netboot.xyz, so I added an option to netboot into ALT Linux Rescue: https://github.com/antonym/netboot.xyz/pull/138 The netboot.xyz project generates signatures for every file it uses, both the iPXE scripts that drive the menus and the boot images themselves. The normal solution would be for netboot.xyz to download the ALT Linux Rescue image and sign it, but that won't work here. The rescue releases I know about are: http://nightly.altlinux.org/sisyphus/tested/ http://nightly.altlinux.org/sisyphus/snapshots/ The tested/ ISOs are regularly overwritten, which invalidates the signatures and would therefore make the ALT Linux Rescue option unbootable each release. The snapshots/ ISOs do not change their contents, so signatures would remain valid, but since snapshots are deleted after a month, netboot.xyz would need to constantly update its menu and the corresponding signatures. Does ALT Linux publish stable rescue images? If not, are there any plans to make stable rescue images available? Thanks! 163235 1 mike 2017-04-14 16:31:28 +0300 (In reply to comment #0) > Does ALT Linux publish stable rescue images? > If not, are there any plans to make stable rescue images available? Sure: http://nightly.altlinux.org/p8/permalink/alt-p8-rescue-latest-x86_64.iso (both the link and the repository to build those images are stable, see also http://en.altlinux.org/starterkits not just http://en.altlinux.org/rescue; these images change once in a season, on Jan/Mar/Jun/Sep 12). Here's the (way more powerful) mirror just in case: http://mirror.yandex.ru/altlinux-starterkits/permalink/alt-p8-rescue-latest-x86_64.iso > https://github.com/antonym/netboot.xyz/pull/138 Heh, some people (including me) would like more features within but some people (including me!) would like the image to stay slim... If you find something particular irritating, please file a bug either. The most notable "offender" is the kernel which is kept more or less mainline (as opposed to longterm branches which grow slower) to get the newest hardware covered; we can prune some parts of /lib/modules/`uname -r` for this particular project or request that those be moved to separate kernel-modules-*. It's easy to make a specialized image if one doesn't need the latest kernel, UEFI support and most of the utilities; this results in 100+ Mb sized ISO which can be further downsized if this is pursued. I can prepare an image for you within http://nightly.altlinux.org/sisyphus/archive/ given a list of tools needed. PS: thank you for the feedback -- feel free to add a note that would help you to discover p8 builds and permalinks to en.altlinux.org, or to tell me what would be appropriate where. 163261 2 will 2017-04-14 18:21:27 +0300 > Sure: http://nightly.altlinux.org/p8/permalink/alt-p8-rescue-latest-x86_64.iso > (both the link and the repository to build those images are stable, see also > http://en.altlinux.org/starterkits not just http://en.altlinux.org/rescue; > these images change once in a season, on Jan/Mar/Jun/Sep 12). Excellent! I think we'll link to the dated release image (alt-p8-rescue-20170312-x86_64.iso) instead. Quarterly updates are easier to track than ~weekly, and the dated files mean that if the user e.g. attempts to boot the March image in June, it'll fail quickly with a 404 instead of failing slowly by downloading and finding the signature doesn't match. > Here's the (way more powerful) mirror just in case: > http://mirror.yandex.ru/altlinux-starterkits/permalink/alt-p8-rescue-latest-x86_64.iso Would you prefer netboot.xyz users boot from the Yandex mirror? It's just a URL either way. > Heh, some people (including me) would like more features within > but some people (including me!) would like the image to stay slim... It's true! Users (including me) are ridiculous ;-) > It's easy to make a specialized image if one doesn't need the latest kernel, > UEFI support and most of the utilities; this results in 100+ Mb sized ISO which > can be further downsized if this is pursued. I can prepare an image for you > within http://nightly.altlinux.org/sisyphus/archive/ given a list of tools > needed. Awesome. Well, there's definitely unnecessary stuff using the ALT Linux Rescue ISO as a netboot.xyz target. EFI boot support goes unused, media check doesn't make sense, and no one will ever select memtest86+ since they can boot it directly. At the same time, I'm not sure what subset of packages or hardware support would be appropriate to remove from the rescue image itself. My most recent use was because I needed `ipmitool` to change a bunch of BMC configurations, and I knew it was included in ALT Linux Rescue, so there I went. Time before that I needed something that can boot into an SSH server with SAS controller drivers, LVM, and some archivers around. The time before that, etc. etc. As long as we're talking about something specifically for netboot rescue purposes, I think there's easier gains to be had by changing the packaging. iPXE can boot straight from a kernel and ramdisk(s) served over HTTP: http://ipxe.org/cmd/imgfetch If iPXE could download syslinux/alt0/* and the root squashfs without downloading the whole ISO, we'd save 50 MB without changing rescue functionality at all. This might need some "find the root FS" scripting tweaks, but it's probably a better results-per-effort ratio than a separate build. 163262 3 7058 mike 2017-04-14 19:56:33 +0300 Created attachment 7058 regular.mk: initial rescue-netbootxyz flavour (In reply to comment #2) > Quarterly updates are easier to track than ~weekly Almost strictly weekly/quarterly as these are cronjobs, the jitter factors are: - build/upload failures (extremely rare given rc/beta but will impact anything); - me being too busy to test in time (quite rare, impacts tested); - build server load (sometimes any images can be delayed by an hour or two). Otherwise, the symlinks should be updated by some 18:00 GMT each Wednesday (for tested) and around 09:00 GMT on said Jan/Mar/Jun/Sep 12 for starterkits. > [...] and the dated files mean that if the user e.g. attempts to boot > the March image in June, it'll fail quickly with a 404 instead of failing > slowly by downloading and finding the signature doesn't match. Indeed. > Would you prefer netboot.xyz users boot from the Yandex mirror? Rather yes as this should benefit their users better, our ftp's bandwidth gets overwhelmed at times (a bug to be fixed but...); the update times shift about half a day then (I can ask Yandex folks when this particular cronjob runs). > EFI boot support goes unused, media check doesn't make sense, > and no one will ever select memtest86+ since they can boot it directly. Removing HDT either; a few more cuts and tweaks, please check (gpm? remote?): http://nightly.altlinux.org/sisyphus/archive/regular-rescue-netbootxyz-20170414-x86_64.iso [326M] Some more "building blocks" can be omitted or adjusted, the profile's here: http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles.git (see pkg.in/lists/tagged/ and conf.d/regular.mk regarding regular-rescue; haven't pushed the latest changes as these tend to be rewritten locally at times with releases happening on Mondays, the current commit's attached). > As long as we're talking about something specifically for netboot rescue > purposes, I think there's easier gains to be had by changing the packaging. I thought about providing minimalistic ALT netboot image as well but that's been done by hand so far, I can publish this particular image this way still proper integration needed more efforts and these were postponed back in the day. > This might need some "find the root FS" scripting tweaks, > but it's probably a better results-per-effort ratio than a separate build. Might even need none as our stage1 is pretty good at network booting, someone even adapted this very rescue flavour for HPC nodes as it "caused the least trouble and didn't bring in too much bloat" ;-) The only problem with this approach that looms is me hitting "time swap" before getting it done, a separate build of a derivative image is quite easy with mkimage-profiles (that's what it was made for, after all). todo++ though! 163263 4 will 2017-04-15 00:05:40 +0300 Some tinkering. I extracted some bits from the rescue ISO: $ 7z x -oalt-p8-rescue-20170312-x86_64/ alt-p8-rescue-20170312-x86_64.iso syslinux/alt0/ rescue I then made a "rescue.ipxe" script: #!ipxe kernel alt-p8-rescue-20170312/syslinux/alt0/vmlinuz fastboot live stagename=rescue splash=0 showopts initrd alt-p8-rescue-20170312/syslinux/alt0/full.cz initrd alt-p8-rescue-20170312/rescue /rescue boot EOF Booted this way, the squashfs image is available as a /rescue file by the time userspace starts, so all stage1 needs to do is mount it and proceed. That's where I get stuck. It looks like propagator's method_select_and_prepare() *really* wants to find a device that it can mount in order to find the root image, and it doesn't appear to accept "it's already available at /rescue" as an option. 7058 2017-04-14 19:56:33 +0300 2017-04-14 19:56:33 +0300 regular.mk: initial rescue-netbootxyz flavour 0001-regular.mk-initial-rescue-netbootxyz-flavour.patch text/plain 2371 mike RnJvbSA2NDE4OTViZjQ5MTk4OTNmNzE5MDlkYmE1ZmI3YjQ3MDM1NjFkYzdkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNaWNoYWVsIFNoaWdvcmluIDxtaWtlQGFsdGxpbnV4Lm9yZz4K RGF0ZTogRnJpLCAxNCBBcHIgMjAxNyAxOTowMDo0MiArMDMwMApTdWJqZWN0OiBbUEFUQ0hdIHJl Z3VsYXIubWs6IGluaXRpYWwgcmVzY3VlLW5ldGJvb3R4eXogZmxhdm91cgoKVGhpcyBvbmUgaGFz IGJlZW4gc3BsaXQgZnJvbSByZWd1bGFyIHJlc2N1ZSBmb2xsb3dpbmcKZGlzY3Vzc2lvbiB3aXRo IFdpbGwgR2x5bm47IHNvbWUgaGVmdHkgYml0cyBsaWtlIFVFRkkKc3VwcG9ydCBvciBhbiBleHRy YSBzcXVhc2hmcyB0byBjaGVjayB0aGUgaW1hZ2UgaW50ZWdyaXR5CmFyZW4ndCBuZWVkZWQsIHNv IGxldCdzIGp1c3QgYnVpbGQgYSBzbGltbWVyIElTTyBpbnN0ZWFkLgoKU3VnZ2VzdGVkLWJ5OiBX aWxsIEdseW5uIDx3aWxsQHdpbGxnbHlubi5jb20+ClNlZS1hbHNvOiBodHRwczovL2J1Z3ppbGxh LmFsdGxpbnV4Lm9yZy8zMzM3NAotLS0KIGNvbmYuZC9yZWd1bGFyLm1rIHwgMTkgKysrKysrKysr KysrKy0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDEzIGluc2VydGlvbnMoKyksIDYgZGVsZXRpb25z KC0pCgpkaWZmIC0tZ2l0IGEvY29uZi5kL3JlZ3VsYXIubWsgYi9jb25mLmQvcmVndWxhci5tawpp bmRleCBlZWZkZDMwLi44NzQzZTlmIDEwMDY0NAotLS0gYS9jb25mLmQvcmVndWxhci5taworKysg Yi9jb25mLmQvcmVndWxhci5tawpAQCAtMjM0LDE3ICsyMzQsMjQgQEAgZGlzdHJvL3JlZ3VsYXIt a2RlNTogZGlzdHJvLy5yZWd1bGFyLWRlc2t0b3AgXAogIyAgICAgd2hpY2ggd2lsbCBjaGFuZ2Ug cHJvcGFnYXRvcidzIGJlaGF2aW91ciB0byBwcm9iZSBhZGRpdGlvbmFsCiAjICAgICBmaWxlc3lz dGVtcyAocm8gYnV0IG5vIGxvb3ApIHRodXMgcG90ZW50aWFsbHkgd3JpdGluZyB0bwogIyAgICAg YW4gdW5yZWNvdmVyZWQgZmlsZXN5c3RlbSdzIGpvdXJuYWwKLWRpc3Ryby9yZWd1bGFyLXJlc2N1 ZTogZGlzdHJvLy5yZWd1bGFyLWJhc2UgdXNlL3Jlc2N1ZS9ydyB1c2UvbHVrcyBcCi0JdXNlL2Jy YW5kaW5nIHVzZS9lZmkvcmVmaW5kIHVzZS9lZmkvc2hlbGwgdXNlL2VmaS9tZW10ZXN0ODYgXAot CXVzZS9oZHQgdXNlL3N5c2xpbnV4L3VpL21lbnUgdXNlL3N5c2xpbnV4L3RpbWVvdXQvNjAwIFwK LQl1c2Uvc3lzbGludXgvcmVzY3VlX2ZtLmNmZyB1c2Uvc3lzbGludXgvcmVzY3VlX3JlbW90ZS5j ZmcgXAotCXVzZS9maXJtd2FyZS9xbG9naWMgdXNlL21lZGlhY2hlY2sgdGVzdC9yZXNjdWUvbm8t eDExIFwKLQkrd2lyZWxlc3MgK3N5c3Zpbml0CittaXhpbi9yZWd1bGFyLXJlc2N1ZTogdXNlL3Jl c2N1ZSB1c2UvaXNvaHlicmlkIHVzZS9sdWtzIHVzZS9icmFuZGluZyBcCisJdXNlL3N5c2xpbnV4 L3VpL21lbnUgdXNlL3N5c2xpbnV4L3RpbWVvdXQvNjAwIFwKKwl1c2UvZmlybXdhcmUvcWxvZ2lj IHRlc3QvcmVzY3VlL25vLXgxMSArc3lzdmluaXQ7IEA6CisKK2Rpc3Ryby9yZWd1bGFyLXJlc2N1 ZTogZGlzdHJvLy5yZWd1bGFyLWJhc2UgbWl4aW4vcmVndWxhci1yZXNjdWUgIFwKKwl1c2UvcmVz Y3VlL3J3IHVzZS9lZmkvcmVmaW5kIHVzZS9lZmkvc2hlbGwgdXNlL2VmaS9tZW10ZXN0ODYgXAor CXVzZS9oZHQgdXNlL3N5c2xpbnV4L3Jlc2N1ZV9mbS5jZmcgdXNlL3N5c2xpbnV4L3Jlc2N1ZV9y ZW1vdGUuY2ZnIFwKKwl1c2UvbWVkaWFjaGVjayArd2lyZWxlc3MKIAlAJChjYWxsIHNldCxLRkxB Vk9VUlMsdW4tZGVmKQogCUAkKGNhbGwgYWRkLFJFU0NVRV9QQUNLQUdFUyxncG0gbGl2ZWNkLW5l dC1ldGgpCiAJQCQoY2FsbCBhZGQsUkVTQ1VFX0xJU1RTLCQoY2FsbCB0YWdzLGJhc2UgJiYgKHNt YXJ0Y2FyZCB8fCBiZW5jaCkpKQogCUAkKGNhbGwgYWRkLFJFU0NVRV9MSVNUUywkKGNhbGwgdGFn cyxuZXR3b3JrIHNlY3VyaXR5KSkKIAorZGlzdHJvL3JlZ3VsYXItcmVzY3VlLW5ldGJvb3R4eXo6 IGRpc3Ryby8ucmVndWxhci1iYXJlIG1peGluL3JlZ3VsYXItcmVzY3VlCisJQCQoY2FsbCBzZXQs UkVMTkFNRSxlbi5hbHRsaW51eC5vcmcvcmVzY3VlIChuZXRib290Lnh5eiBlZGl0aW9uKSkKKwlA JChjYWxsIHNldCxNRVRBX1ZPTF9JRCxBTFQgUmVzY3VlKQorCUAkKGNhbGwgc2V0LE1FVEFfQVBQ X0lELCQoQVJDSCkpCisKIGRpc3Ryby9yZWd1bGFyLXN5c3YtdGRlOiBkaXN0cm8vLnJlZ3VsYXIt aW5zdGFsbC14MTEtZnVsbCBtaXhpbi9yZWd1bGFyLXRkZQogCUAkKGNhbGwgYWRkLFRIRV9MSVNU UywkKGNhbGwgdGFncyxiYXNlIGRlc2t0b3ApKQogCUAkKGNhbGwgYWRkLFRIRV9MSVNUUywkKGNh bGwgdGFncyxyZWd1bGFyIHRkZSkpCi0tIAoyLjEwLjIKCg==