date:20220216

Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?

2022-02-16 Thread Reco

Hi.

On Thu, Feb 17, 2022 at 12:32:48AM -0600, Flacusbigotis wrote:
> Thanks Reco & Greg.  I did see the
> /lib/systemd/network/73-usb-net-by-mac.link file. Thanks for that.
> 
> I don't know exactly what is happening, but the MAC address of the device
> keeps changing  after an ifdown/ifup cycle post boot.

You should've said that first.
If the MAC address of the NIC is not persistent, that means udev will
provide you with different interface name each time you boot.
That means that you've hit yet another case of unpredictability of so
called Predictable Network Interface Names.

> I also tried adding a udev file (/etc/udev/rules.d/99_fix_usb.rules) with
> the following content to try to force the addr_assign_type to 0, but this
> did nothing:
> 
> SUBSYSTEMS=="usb", SUBSYSTEM=="net", ATTR{addr_assign_type}="0"

Try this:

1) Create a file called /etc/systemd/network/00-usb.link with the following
contents:

[Match]
Driver=ax88179_178a

[Link]
MACAddressPolicy=none
NamePolicy=kernel

You may have to create an appropriate directory, and the file name has
to start with double zeroes.

2) Invoke (really needed):

update-initramfs -k all -u

3) Reboot.

4) Watch your network interface is called usb0 from now then.

Now, this approach has its caveats, so:

1) If you ever plug-in two USB devices that both served with
"ax88179_178a" - you won't be able to distinguish between them. They
will be called usb0, usb1, etc without any meaningful order.

2) If they decide to rename "ax88179_178a" in the kernel - this link
file will cease to work for obvious reasons.

Reco

Re: Installing bullseye into previously existing encrypted disk with buster

2022-02-16 Thread John Crawley

On 16/02/2022 05:26, Nitebirdz wrote:

On Sat, Feb 12, 2022 at 09:36:45AM +1100, David wrote:

I'm not really paying attention to the latest capabilites that the
installer might have, or to what any other distros are doing, but when
I have attempted this in the past it appeared to me that the Debian
installer does not directly support installing a fresh installation
into a previously created LUKS encrypted volume.

However it is certainly "possible" with some complicated tricks, and
if you are prepared to risk accidentally destroying the whole
encrypted volume if you make a mistake. That's what happened to me the
first time I tried it. But I have adequate backups and alternative
machines, so that didn't bother me.

It is possible to trick the installer into opening the existing
encrypted volume. Then (with numerous fiddly steps and using great
caution not to make a mistake) the installer can then install into a
new partition inside that, in the usual way.

However the installation it creates will be broken and likely not
bootable. Because we have tricked the installer beyond what it
understands, it makes many mistakes. There will be problems with grub,
with the cryptsetup configuration, and with the initramfs. That all
then needs to be fixed by rebooting into an alternative environment
that has cryptsetup tools available. Maybe the installer rescue system
is capable of doing that, but I'm not sure because ...

Indeed. I did some further searching (it's not an easy thing to search
for), and ended up finding the following document:

https://consolematt.wordpress.com/2013/06/19/reinstalling-debian-on-existing-lukslvm-partition/

I tested it on a VM inside QEMU, and it worked.

So, basically, once we reach the point where we detect the hard drive,
we need to drop to the shell, install additional software into the
installation environment, and then run the commands to configure the
already existing volume group and logical volumes. After that, we can
return to the installer, and partman will see everything. We can then
configure the proper mounts, and go on with the rest of the standard
installation steps.

However, as you explained, the installation is not bootable, it fails to
recognize the encrypted volume group, and it just drops to the initramfs
prompt. However, from there, we can run the commands documented in that
blog entry, and it all works.

While not disagreeing that the process is messy, I don't think it's quite as
difficult in 2022 as it was in 2013.
I used these two links to read up on it:
https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/
https://linuxconfig.org/how-to-install-debian-on-an-existing-luks-container
and FWIW summarized my experience here:
https://forums.bunsenlabs.org/viewtopic.php?pid=118486#p118486
It wasn't all that hard to re-use one of the encrypted partitions and keep the
others. (Though I made the mistake of overwriting the previous boot partition,
so the old installation would have needed a new /boot created in order to boot.
I didn't bother because the partition was still accessible from the new system.)

55 matches

Mail list logo