Bug 33374

(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.

> 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.

Created attachment 7058 [details]
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!

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.