3 ms·

> the mdadm binary in d-i is compiled to have its config at /tmp/mdadm.conf. I don’t know why, but probably there is a good reason. It’s certainly because all

> the mdadm binary in d-i is compiled to have its config at /tmp/mdadm.conf. I don’t know why, but probably there is a good reason. It’s certainly because all else of the installer file system hierarchy is mounted read-only I would think.

JoshTriplett 6y ago
When you're booted in the installer environment, /etc is writable. Some of the sample code in the article shows writing a file in /etc, and the file write works fine, mdadm just doesn't read the file. I believe the reason is that mdadm in the installer exists to create arrays for the installed system, so the installer's RAID configuration needs to supply a configuration file, and for some reason that's handled by having the installer's RAID configuration write it to /tmp/mdadm.conf and having mdadm read it from there. (Rather than, say, writing it to a temporary file and directing mdadm to read that temporary file.)
- Filligree 6y ago
  Well, /etc/mdadm.conf is supposed to describe the running system. Now, the installer doesn't use md, but from a strict philosophical perspective this makes sense.
marcan_42 6y ago
The installer filesystem should be an initramfs, so it should all be in RAM and writable (at least in the netboot case, but I don't see why CDs would do it differently; I expect the extra storage is just used for packages), at least for d-i stuff. Even for proper (not install only) live CDs where the rootfs is really read only, I don't think I've ever seen a distro not mount an overlayfs on top so that changes can be made in RAM. Too much stuff breaks on your average distro if you really try to have a read only rootfs.
nailer 6y ago
> > the mdadm binary in d-i is compiled to have its config at /tmp/mdadm.conf. I don’t know why, but probably there is a good reason As others have said, /etc is writable during the installer. More to the point: whatever other reason is likely bad. An app not using it's own config file in the standard location, losing data clobbering it's own config is, from experience (Red Hat used to do this a lot and our customers HATED it), a mistaken decision.

JoshTriplett 6y ago

When you're booted in the installer environment, /etc is writable. Some of the sample code in the article shows writing a file in /etc, and the file write works fine, mdadm just doesn't read the file. I believe the reason is that mdadm in the installer exists to create arrays for the installed system, so the installer's RAID configuration needs to supply a configuration file, and for some reason that's handled by having the installer's RAID configuration write it to /tmp/mdadm.conf and having mdadm read it from there. (Rather than, say, writing it to a temporary file and directing mdadm to read that temporary file.)

Filligree 6y ago
Well, /etc/mdadm.conf is supposed to describe the running system. Now, the installer doesn't use md, but from a strict philosophical perspective this makes sense.

marcan_42 6y ago

The installer filesystem should be an initramfs, so it should all be in RAM and writable (at least in the netboot case, but I don't see why CDs would do it differently; I expect the extra storage is just used for packages), at least for d-i stuff. Even for proper (not install only) live CDs where the rootfs is really read only, I don't think I've ever seen a distro not mount an overlayfs on top so that changes can be made in RAM. Too much stuff breaks on your average distro if you really try to have a read only rootfs.

nailer 6y ago

> > the mdadm binary in d-i is compiled to have its config at /tmp/mdadm.conf. I don’t know why, but probably there is a good reason As others have said, /etc is writable during the installer. More to the point: whatever other reason is likely bad. An app not using it's own config file in the standard location, losing data clobbering it's own config is, from experience (Red Hat used to do this a lot and our customers HATED it), a mistaken decision.