#2213 Issue `closed`: WiFi with ReaR?¶

Labels: enhancement, needs sponsorship, no-issue-activity

adatum opened issue at 2019-08-13 16:30:¶

ReaR version ("/usr/sbin/rear -V"): 2.5 rpm built from git

Is it possible to use WiFi when booted from the ReaR recovery media?

When booting from ReaR on a laptop, I noticed a message, about starting the DHCP daemon, that stayed on screen an unusually long time (maybe over a minute) compared to the boot time in a VM, before finally arriving at the login prompt.

On the laptop with WiFi enabled but no ethernet cable plugged in, there was no network connectivity. After plugging in an ethernet cable and waiting a bit, the network connection works.

It's unclear to me whether ReaR supports WiFi connections at all.

If so, does ReaR store the necessary information such as SSID, access point, password, perhaps via config file variables that must be set? Or can a WiFi connection be set up manually once booted from ReaR?

schlomo commented at 2019-08-13 19:40:¶

There is nothing speaking against WiFi support in ReaR, just so far nobody provided code for this. Most of ReaR usage seems to happen on servers or desktops/laptops with an Ethernet connection (maybe also due to the higher and more reliable transfer speeds).

If you want to submit a pull request then it will be very welcome.

If your inquiry is about reducing the boot time for a laptop without a network connection then please update the title and description and provide more details.

adatum commented at 2019-08-13 20:08:¶

Thanks for the reply @schlomo.

There is nothing speaking against WiFi support in ReaR, just so far nobody provided code for this.

To clarify, does this mean that ReaR could in principle support WiFi but that it is not currently implemented?

Is it possible to establish a WiFi connection manually in the recovery environment, or does it require some implementation in ReaR?

Unfortunately I'm not sufficiently well-versed in neither ReaR nor networking to make a pull request, but I'm happy to help with testing.

If your inquiry is about reducing the boot time for a laptop without a network connection then please update the title and description and provide more details.

No, your first interpretation was correct. I will make another issue for the slow boot as that may be unrelated.

schlomo commented at 2019-08-13 20:27:¶

Yes, there is no code at present to copy the required files and daemons for WiFi support to the rescue system. That is the reason why manually activating WiFi is currently not possible.

jsmeix commented at 2019-08-14 12:12:¶

@adatum
regarding how the main networking setup happens in the recovery system see
https://github.com/rear/rear/issues/2214#issuecomment-521217612

Regarding manual WiFi setup:

Use COPY_AS_IS and PROGS in your etc/rear/local.conf to specify the needed files
and programs for WiFi setup to be included into the ReaR recovery system.

After you booted the ReaR recovery system log in as root and manually
set up WiFi networking.

When you know the right commands to set up WiFi networking you can
automate that via NETWORKING_PREPARATION_COMMANDS,
see in default.conf the section starting at
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2484

jsmeix commented at 2019-08-14 12:26:¶

@adatum
a general side note regarding "using ReaR on a laptop":

Current ReaR is primarily meant to be used to recover server systems
where the user usually has many same pieces of server hardware
(or many same kind of virtual machines) so that same replacement
hardware (where "hardware" could be also virtual hardware) is available,
cf. the section "Fully compatible replacement hardware is needed" in
https://en.opensuse.org/SDB:Disaster_Recovery

Usually when one particular laptop hardware breaks down
there is no "fully compatible replacement hardware" available
because the currently sold laptops are already different.
As far as I know in particular WiFi hardware changes all the time.

This means to recreate the system on different replacement hardware
is what we call a "migration" and in this case arbitrary issues could get
into your way up to the point that it is impossible to recreate the system
with ReaR (with reasonable effort).

This does not mean ReaR usually fails to recreate on different hardware
but it does mean you should be prepared that it may not work with ReaR
so that you would have to install the system anew from scratch,
cf. "Be prepared for the worst case" in
https://en.opensuse.org/SDB:Disaster_Recovery

adatum commented at 2019-08-16 04:29:¶

@jsmeix

Thanks for the warning about potential failure to recreate on different hardware. I hope that there is at least a good chance of success if the replacement hardware is supported by the built-in drivers in the linux kernel. But I'll keep this possibility in mind.

The more likely migration scenario is adding or upgrading an SSD and wanting to change the file system mount points and/or partition sizes.

Back on the subject of WiFi, I was able to get a connection by adapting this guide:

PROGS=( "${PROGS[@]}" iw wpa_supplicant wpa_passphase )

Then in the ReaR recovery environment I did:

ip link set wlp2s0 up
wpa_passphrase [SSID] >> /etc/wpa_supplicant.conf
Enter WiFi passphrase at prompt
wpa_supplicant -B -i wlp2s0 -c /etc/wpa_supplicant.conf

iw wlp2s0 link indicated the WiFi connection was established. Sometimes it would take a few moments for pings and dns to get working.

I also tried

NETWORKING_PREPARATION_COMMANDS=( 'ip link set wlp2s0 up' 'echo "Enter WiFi passphrase:"' 'wpa_passphrase [SSID] >> /etc/wpa_supplicant.conf' 'wpa_supplicant -B -i wlp2s0 -c /etc/wpa_supplicant.conf' )

which prompts for the password during the boot process, and upon login the WiFi connection is up and running. There might be a more elegant way of doing this, but at least it works and gives me lots of options. Thanks for the pointers @jsmeix !

A couple of notes:

You mentioned

After you booted the ReaR recovery system log in as root

but I've noticed that the login always logs in as root no matter what is typed at the login prompt. Is that normal?
nano seems to be glitched in ReaR. Moving the cursor over text file contents changes what is displayed on screen. It seems to shift some characters over by a space or so. Almost as though the cursor's "view" can lag or skip relative to what it should be displaying. vi/vim seem unaffected.

jsmeix commented at 2019-08-16 09:08:¶

@adatum
thank you for your explanatory description how you made WiFi work in your case.
This can help a lot to be able in the future (as time permits)
to implement a generic working way to support WiFi in ReaR.

Regarding your notes:

Yes, root (without password) is the only user in the ReaR recovery system.
Who can boot a machine from an external boot medium can do anything
he wants so root login without password from the ReaR recovery medium
does not make anything worse.

I never used nano but I guess it may not work well in the ReaR recovery system
because the ReaR recovery system is very minimal, for example it has no
localization support (only plain US ASCII),
cf. the section about "Character encoding" in
https://github.com/rear/rear/wiki/Coding-Style
and the recovery system has likely no special terminal support
(basically only the plain Linux kernel console - perhaps you could
specify appropriate kernel command line parameters for the console)
or things like that what nano might need to run normally.
With sufficient additional things in COPY_AS_IS you can enhance the
ReaR recovery system files as you need but this makes it bigger but
the current usual use case of ReaR is to recreate (many) server systems.
Because the ReaR recovery system is specific for each system where
is was made by "rear mkrescue/mkbackup", users who have many servers
need to store many ReaR recovery system ISO images which is the reason
behind why the ReaR recovery system is as small as reasonably possible.
Of course what is considered to be reasonable depends on the particular case,
for an example cf.
https://github.com/rear/rear/issues/2041
see also the part about "MODULES=( 'all_modules' )" in
http://relax-and-recover.org/documentation/release-notes-2-5

jsmeix commented at 2019-08-16 10:27:¶

Since ReaR 2.5 there is in default.conf MODULES=( 'all_modules' )
cf. http://relax-and-recover.org/documentation/release-notes-2-5
so that "there is at least a good chance of success if the replacement
hardware is supported by the built-in drivers in the linux kernel".

But substantially changing the disk layout can get soon complicated.
To do that you would have to adapt the disklayout.conf file to the right
values that match the changed disk(s) on the replacement hardware
or during "rear recover" you could adapt the diskrestore.sh script,
see in
https://github.com/rear/rear/blob/master/doc/user-guide/06-layout-configuration.adoc
in the section "Restore to different hardware" the parts
"The Ad-Hoc Way" versus "Planning In Advance".
The screenshots therein are a bit outdated (the current user dialogs look different)
but the general information is still right.

When you have the replacement hardware already availabe so that
you can play around with it and do trial and error attempts
using RECOVERY_UPDATE_URL (see its description in default. conf)
can help here (but the actual changes need to be done manually),
for an example see in particular
https://github.com/rear/rear/issues/943#issuecomment-236547810
and for a possible pitfall in a special case see
https://github.com/rear/rear/issues/943#issuecomment-237544630

When you do not have the replacement hardware already available
(e.g. because your laptop has fallen down the stairs and broken into pieces
so you had to buy a new one that is available right now in the next shop)
and you intend to do a substantial change of the disk layout at the same time,
then you likely run into too many various kind of issues at the same time.

But usually laptops have only one single disk and usually a SSD should
behave same as a traditional spinning harddisk (except special kind
of NVME-like "disks") so the only usual change should be that the new disk
is much bigger than the old one was.

Normally it should work straightforward to migrate a single disk onto
a new bigger single disk, cf. AUTORESIZE_PARTITIONS
and its related config variables in default.conf
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L372

A precondition to make migrating onto a bigger disk "just work" is that
the last partition on the disk is the one and only one that should be enlarged.
E.g. it would be bad to have the swap partition as the last one on the disk
(in such cases one must do the migration adaptions manually).

In general cf.
https://en.opensuse.org/SDB:Disaster_Recovery#Inappropriate_expectations
(excerpt)

The simpler the system, the simpler and easier the recovery.

adatum commented at 2019-08-18 03:21:¶

I'm really glad about MODULES=( 'all_modules' ). Thanks for adding this. I think it's great for increasing versatility with little to no cost.

For disk replacement or addition, yes, I think I will have to become well-acquainted with disklayout.conf and diskrestore.sh and manually edit. In the future I plan to add an NVME SSD to my desktop, and I try to think ahead to make migration easier. I'm not sure if ReaR is the right tool for that. Given the rarity and uniqueness of such events, it's fine if it requires manual intervention. In any case, that's not urgent now.

About the nano glitch, this bug report is the closest description I've found: https://bugzilla.redhat.com/show_bug.cgi?id=1412575 The video attachment demonstrates the problem well. It's not clear what the issue was, with the suggestion that it may have to do with the terminal.

As for the root login on the recovery system, of course it makes sense. It's just confusing to be asked to log in, though, since there is no anticipation of user accounts and since anything typed as the username gets accepted and logs in as root. Maybe in the future the login prompt can be omitted?

github-actions commented at 2020-06-27 01:33:¶

Stale issue message

[Export of Github issue for rear/rear.]

#2213 Issue closed: WiFi with ReaR?¶