When manually setting the key management, this will actually cause wifi to not connect if a different type is used by the access point.
WPA supplicant typically can detect the key management from the access point's broadcast, and not overriding it has a bigger chance of succeeding.
As a `wpa_cli` newbie, I just followed the instructions in the manual on the minimal install disk and they didn't work. I tried setting `key_mgmt` what was shown in the scan results, but `wpa_cli` barfed at the string (quoted or unquoted). Only when dropping the `set key_mgmt` line entirely, it worked. So I think this would provide a better help for people using the minimal install disk.
Apologies to the non-flake users; your repl isn't quite as fancy,
but at least evaluates your config exactly as you would expect,
unlike flakes which are only evaluated impurely for now.
In my earlier commit
manual: Don't suggest exposing VM port to local network.
I made a side change titled
Use `127.0.0.1` also on the VM side, otherwise connections to
services that, in the VM, bind to `127.0.0.1` only
(doing the safe approach) do not work.
Unfortunately, that was wrong:
QEMU inside the VM always communicates via the virtualised
Ethernet interface, not via the VM's loopback interface.
So trying to connect to `127.0.0.1` on the VM's side cannot work.
The setting
QEMU_NET_OPTS="hostfwd=tcp::2222-:22"
caused the VM's port 2222 to be advertised on the host as
`0.0.0.0:2222`, thus anybody in the local network of the host
could SSH into the VM.
Instead, port-forward to localhost only.
Use `127.0.0.1` also on the VM side, otherwise connections to
services that, in the VM, bind to `127.0.0.1` only
(doing the safe approach) do not work.
See e.g. https://github.com/NixOS/nixpkgs/issues/100192
for more info why localhost listening is the best default.
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
For GPT partition tables, there is no primary/logical/extended
partition type, and the layout of the mkpart command options slightly
differs depending on whether parted operates on an MBR or a GPT
partition table.
This has so far resulted in the string `primary` being assigned to the
GUID partition name field, which is probably unintended.
Rectify this by giving the GUID partitions sensible names and setting
`fs-type` where applicable.
the nixos manual contains enough examples to support them as a proper
toc entity with specialized rendering, and if in the future the nixpkgs
wants to use nixos-render-docs we will definitely have to support them.
this also allows us to restore some examples that were lost in previous
translation steps because there were too few to add renderer support
back then.
this adds support for structural includes to nixos-render-docs.
structural includes provide a way to denote the (sub)structure of the
nixos manual in the markdown source files, very similar to how we used
literal docbook blocks before, and are processed by nixos-render-docs
without involvement of xml tooling. this will ultimately allow us to
emit the nixos manual in other formats as well, e.g. html, without going
through docbook at all.
alternatives to this source layout were also considered:
a parallel structure using e.g. toml files that describe the document
tree and links to each part is possible, but much more complicated to
implement than the solution chosen here and makes it harder to follow
which files have what substructure. it also makes it much harder to
include a substructure in the middle of a file.
much the same goes for command-line arguments to the converter, only
that command-lined arguments are even harder to specify correctly and
cannot be reasonably pulled together from many places without involving
another layer of tooling. cli arguments would also mean that the manual
structure would be fixed in default.nix, which is also not ideal.
since support for kbd elements was added with explicit intent in #175128
it seems like a good idea to support this in nixos-render-docs instead
of just dropping it in favor of `*F12*` etc. since it's a very rare
thing in the manual and purely presentational it makes sense to use
bracketed spans instead of a new myst role.
the html-elements.lua plugin is now somewhat misnamed, but it'll go away
very soon so we don't want to bother renaming it.
pandoc drops .title classes when rendering to docbook, so these are
effectively just paragraphs anyway. without support for including them
in a table of contents the complexity of parsing them in
nixos-render-docs won't be warranted.
pandoc renders these to multiple docbook paragraphs in a single
definition for the term, not multiple *actual* definitions for the same
term. this is most likely not what is intended here, so let's use
multiple paragraphs instead.
The nixos-generate-config command mentioned in the manual fails with error:
nixos-generate-config: no need to specify `/` with `--root`, it is the default
This was introduced in 611b8c4472
(#161034). Now, the command should be called without any arguments.
- Update download URLs
- Replace "USB stick"/"USB Drive" with "USB flash drive" as that seem more correct
https://en.wikipedia.org/wiki/USB_flash_drivehttps://elementary.io/docs/installation#choose-operating-system
- Don't mention CD as easiest option anymore,
as all modern systems should be able to boot from USB,
but many don't have a CD drive. Burning CDs is also usually wasteful as you
can't burn them again.
- Remove link to NixOS Wiki (Making_the_installation_media) as it is not needed
- Add Etcher and USBImager as graphical tools to create install drive
- Make dd command consistent and use block size of 4 MB for faster flashing
- More consistent text
- Add instructions for "Booting from the install medium"
Inspired by 9a91b0f495/docs/installation.md (booting-from-the-install-drive-booting-from-the-installation-medium-clear-float-2)
- Add instructions for "Graphical Installation"
- Restructure headings and anchors for "Manual Installation"
- Adding legacy anchors for "Manual Installation" to not break links
Co-authored-by: j-k <dev@j-k.io>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: Robert Schütz <github@dotlambda.de>
Co-authored-by: Jörg Thalheim <Mic92@users.noreply.github.com>
Co-authored-by: Thiago Kenji Okada <thiagokokada@gmail.com>
$ parted /dev/nvme1n1 -- mkpart primary linux-swap -8GiB 100%
Warning: The resulting partition is not properly aligned for best performance: 3108850352s % 2048s != 0s
Ignore/Cancel?
Information: You may need to update /etc/fstab.
When using GB than parted seems to round up itself.
Without configuring the block size a default of 512 bytes is used, which can
slow down the transfer speed massively.
In a test I've done with a semi-decent USB stick, I only get a transfer speed
of around 180 KB/sec when not specifying the block size but see 27 MB/sec when
setting the block size to 1 MB. This makes the transfer of the minimal
installation ISO take half a minute instead of an hour.
