Re: [Dng] [dng] vdev status updates

[Anto]

On 29/04/15 02:03, Jude Nelson wrote:

Hey everyone,

Sorry for being incommunicado these past two weeks--I was working on a 
conference paper that was due last Friday.  Thank you all for being 
patient!


I have the latest news for vdev:

[Status updates]

* Support for booting from LVM2 volumes has been added.  vdevd will 
create all /dev/VG/LV links, /dev/mapper/ symlinks, and 
/dev/disk/by-id/lvm-pv-uuid-XXX links.  I have successfully used vdev 
to boot the Devuan QEMU image from April 24--the one with root and 
swap on LVM.


* Support for /dev/input/by-id has been added, but needs testing.  In 
particular, I'm not sure what kinds of devices other than USB input 
devices go here.  I think maybe old serial and MIDI joysticks might go 
here, but I do not have any to test on (let alone a computer with a 
COM or MIDI port).  If you're not seeing a device symlink that should 
be here, please let me know.


* vdevd's helper scripts now set device ownership and permissions 
correctly, instead of defaulting to root.root and 0600.


[Development]

* Under the hood, I've refactored vdev's subr.sh shell library, such 
that each vdev-specific method is appropriately prefixed (with "vdev_").


* With Scooby's help, I'm getting a list going for package 
dependencies going for vdevd's helper scripts, to make it easier to 
package vdev.  The list is in pkg/dependencies.txt.


[Integration Testing]

* Scooby, Tom H, and Anto have been hitting vdev hard, and Scooby has 
been able to boot to desktop with vdevd (but first by writing an 
xorg.conf).  Their reports have been instrumental in closing the 
functionality gap between vdevd and udevd.  Thank you to everyone who 
participated!


* On initramfs testing:  Anto has helped me uncover some problems with 
my very early, very hack-ish makefile for generating initramfs 
images.  I think the latest commit should fix at least some of the 
problems (but not all of them), but I have not had time to look into 
whether or not the process works for file-rc.


[TODO]

* I still need to figure out how to generate /dev/disk/by-partuuid and 
/dev/v4l/by-path, and possibly others.


* Packaging.  I'm working on a way to automatically build a .deb for 
vdevd that will, among other things, safely generate and install an 
initramfs without having to hack the initramfs tools (as is the case 
today).  Please see [Help Wanted].


* libudev-compat.  No ETA on this, but I'm going to try to make some 
progress on it next week.  Fortunately, a lot of programs can be 
compiled without libudev, so it's not as high of a priority right now.


[Help Wanted]

* Astute readers may notice that one method in 
vdev/helpers/LINUX/subr.sh is called vdev_chown.  This is because for 
whatever reason, Debian's busybox chown does not accept usernames and 
group names when running in the initramfs.  I have tried:
-- copying over /etc/passwd, /etc/passwd-, /etc/group, /etc/group- to 
the initramfs.

-- using GNU chown.
-- strace-ing both GNU chown and busybox to confirm that they access 
/etc/passwd and /etc/group.


It does not appear to be specific to busybox chown; busybox ls doesn't 
resolve UIDs and GIDs to usernames and groups either, for example.  
Anyone familiar with busybox on this list want to weigh in?  The 
vdev_chown shell method is clearly a hack and I'd love to be rid of 
it, but until I figure out why busybox chown is misbehaving, it's 
necessary to set device file ownership in the initramfs (i.e. I think 
it's less evil than using opaque UIDs and GIDs in vdevd's helper scripts).


* As Anto's experience shows, getting a working initramfs is tedious 
to do and easy to get wrong.  This is not only because there are 
multiple init systems that vdevd will need to work with (e.g. sysv-rc, 
file-rc, openrc, etc.), but also init scripts and initramfs scripts 
that come from packages that depend on udev are (unsurprisingly) 
tightly coupled to udev.  This makes it difficult to install vdevd on 
a running Debian system without removing udev (which is in itself 
undesirable, since it will take a large swath of packages out with 
it), since I have to pretty much fork both sets of scripts and try to 
mash them up into a custom initramfs without altering 
/usr/share/initramfs-tools.  This is effectively what my (extremely 
kludgy) initramfs Makefile does.


What I'm going to make my next priority is making a .deb for vdevd 
that automatically generates the initramfs in a "safe" manner.  I'd 
need to do this in a way that disables, but does not remove the udev 
scripts.  This is easier said than done due to tight integration with 
udev, but I don't think it's insurmountable.


What we'll need is a well-written .deb post-install script that:
* sets up config files needed to generate persistent device names
* installs our versions of the initramfs scripts for things like lvm, 
suspend/resume, etc.

* disables the udev versions, but does not uninstall them
* safely builds the initramfs from our scripts.
* 

Re: [Dng] acpi and systemd

[Hendrik Boom]

On Sun, Apr 26, 2015 at 12:31:16AM +0200, Franco Lanza wrote:
> On Sat, Apr 25, 2015 at 05:16:42PM -0400, Hendrik Boom wrote:
> > 
> > acpid and acpi-support-base have already been removed from tasksel.
> 
> 
> We already forked tasksel, so, it should not be an issue for us as long
> as those two packages are maintained, or we will need to fork both acpid
> and acpi-support-base too.

Indeed.  Is there a mechanism in place to watch for this kind of thing?  
Should there be?

There might be a lot of packages dropped if Debian decides that systemd 
supplants or conflicts with them,

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] by-uuid and by-partuuid

[Hendrik Boom]

On Tue, Apr 28, 2015 at 08:49:29PM -0700, Isaac Dunham wrote:
> On Tue, Apr 28, 2015 at 08:03:02PM -0400, Jude Nelson wrote:
> > [TODO]
> > 
> > * I still need to figure out how to generate /dev/disk/by-partuuid and
> > /dev/v4l/by-path, and possibly others.
> 
> /dev/disk/by-partuuid does not exist on my udev-based Jessie install.
> It would presumably be the PARTUUID="..." field of blkid.

I don't have a /dev/disk/by-partuuid either on my Debian Jessie.
But I do have a /dev/disk/by-uuid:

hendrik@notlookedfor:~$ ls /dev/disk/by-uuid -l
total 0
lrwxrwxrwx 1 root root 10 Apr 27 20:19 5b2a2232-0b2a-47be-ba14-a30114b3bff6 -> 
../../dm-0
lrwxrwxrwx 1 root root 10 Apr 27 20:19 6632df41-993a-48ca-9420-0f04d69993b6 -> 
../../dm-1
lrwxrwxrwx 1 root root 10 Apr 27 20:19 708411CB841194A6 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 27 20:19 84c0e2c4-b484-4e1f-acf2-7437e9fbc584 -> 
../../sda7
lrwxrwxrwx 1 root root 10 Apr 27 20:19 b925e3ae-4576-460b-809d-3e67511a5bc4 -> 
../../sda6
lrwxrwxrwx 1 root root 10 Apr 27 20:19 CCED-990E -> ../../sda3
lrwxrwxrwx 1 root root 10 Apr 27 20:19 fe576e95-07c6-4845-baeb-35096a358498 -> 
../../sda5
hendrik@notlookedfor:~$ 

Is by-partuuid something different?  Should I have one?

It doesn't seem to be necessary for a running Debian Jessie.  Mind you, 
this Jessie is the result or frequent upgrades all the way back to when 
it was the testing stage of wheezy, and it uses sysv-init, so a fresh 
install might produce something different.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] OT: How do I keep my Wheezy from upgrading itself to Jessie?

[Luke Diamand]

On 28 April 2015 at 14:27, Steve Litt  wrote:
> Hi all,
>
> While I wait for Dng to mature and become my daily driver OS, I'm
> continuing to limp along on Debian Wheezy initted by sysvinit. What I
> want to make sure of is that when I run apt-get update & apt-get
> upgrade that my computer doesn't try to convert itself to Jessie,
> because then I'd face a situation where I'd need to shut down my
> business and immediately convert to Manjaro OpenRC edition. I'd rather
> make an orderly transition to Dng, on my own timetable.
>
> So, anyone know how to prevent my Wheezy box from converting itself to
> Jessie?

FWIW, I've been using the nosystemd angband repo and it seems to have
survived the transition.

So /etc/apt/sources.list looks like:

deb http://angband.pl/debian/ nosystemd main
deb http://ftp.uk.debian.org/debian/ stable main contrib non-free

And then I've got the usual "Pin-Priority: -1" for systemd-sysv and systemd.

With that, I have no systemd related packages, but otherwise it's
basically Jessie.

Luke
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Steve Litt]

On Tue, 28 Apr 2015 20:03:02 -0400
Jude Nelson  wrote:


> * Packaging.  I'm working on a way to automatically build a .deb for
> vdevd that will, among other things, safely generate and install an
> initramfs without having to hack the initramfs tools (as is the case
> today).  Please see [Help Wanted].

[snip]


> * Astute readers may notice that one method in
> vdev/helpers/LINUX/subr.sh is called vdev_chown.  This is because for
> whatever reason, Debian's busybox chown does not accept usernames and
> group names when running in the initramfs.  I have tried:
> -- copying over /etc/passwd, /etc/passwd-, /etc/group, /etc/group- to
> the initramfs.
> -- using GNU chown.
> -- strace-ing both GNU chown and busybox to confirm that they access

[snip]

> 
> * As Anto's experience shows, getting a working initramfs is tedious
> to do and easy to get wrong.  This is not only because there are
> multiple init systems that vdevd will need to work with (e.g.
> sysv-rc, file-rc, openrc, etc.), but also init scripts and initramfs
> scripts that come from packages that depend on udev are
> (unsurprisingly) tightly coupled to udev.

Hi Jude,

You probably know this, but in case you don't, the Debian-User list
reports that Jessie itself has initramfs problems.

Let me ask you something else about initramfs...

What I say in the following paragraphs is based on the Epoch init
system and might not be useful with sysvinit, but maybe it might
help... 

I'm under the impression you can do most or all of what needs to be
done in the actual init, rather than the initramfs. This gets a little
complicated now that Linux has been "improved" by having /sbin
and /bin be symlinks to /usr/bin, which might not be mounted in early
boot, but aside from that, I think once you have possession of /bin
and /sbin, then assuming that /etc is not a mountpoint, I think most
other stuff can be delayed til the real init, always assuming that it's
easier to put stuff in the on-disk init than in initramfs.

LOL, we could always cheat and put copies of programs that should be
in /sbin and /bin in the pre-mounted versions of those directories. Who
knows, maybe then we could eliminate the initramfs step entirely. :-)

I don't know how practical any of this would be, but I've never been a
big fan of initrd/initramfs, and the one on my Wheezy has hair and
teeth.

SteveT

Steve Litt 
April 2015 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Didier Kryn]

Le 29/04/2015 16:47, Steve Litt a écrit :

  maybe then we could eliminate the initramfs step entirely.:-)


Sure that would be nice. It's something you can do for each 
machine, but is not practical for a distro intended for all. Some 
drivers, notably disk, raid, lvm, are necessary to mount your root 
partition, and these drivers are so many, to match all possible hardware 
configs, that they would bloat the kernel if they were built "in 
kernel". Instead they are built as loadable modules, so that only the 
drivers needed for the booting machine are finaly loaded. This implies a 
first step of initialization in which the modules can be read from 
/lib/modules. The alternative, for a distro would be to build all 
existing drivers in the kernel. This is my understanding, at least :-)



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] Feedback installing Devuan through debootstrap in Debian Testing.

[Edward Bartolo]

I am using the Devuan patched debootstrap in Debian Testing.
debootstrap failed with the following message:

# debootstrap --arch amd64 stable /mnt/sda8 http://packages.devuan.org/devuan
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
E: Release signed by unknown key (key id 94532124541922FB)

Any helpful pointers are much appreciated.
Thanks.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Feedback installing Devuan through debootstrap in Debian Testing.

[Edward Bartolo]

Update 2:

I replaced stable with jessie as follows. debootstrap did better but
failed. These are the results:

# debootstrap --arch amd64 jessie /mnt/sda8 http://packages.devuan.org/devuan/
W: Cannot check Release signature; keyring file not available
/usr/share/keyrings/devuan-keyring.gpg
I: Retrieving Release
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://packages.devuan.org/devuan...
I: Validating devuan-keyring 2015.04.11
I: Validating bsdutils 1:2.25.2-4.1+devuan1
I: Validating libblkid1 2.25.2-4.1+devuan1
I: Validating libmount1 2.25.2-4.1+devuan1
I: Validating libsmartcols1 2.25.2-4.1+devuan1
I: Validating libuuid1 2.25.2-4.1+devuan1
I: Validating mount 2.25.2-4.1+devuan1
I: Validating util-linux 2.25.2-4.1+devuan1
I: Chosen extractor for .deb packages: dpkg-deb
I: Extracting bsdutils...
I: Extracting libblkid1...
I: Extracting libmount1...
I: Extracting libsmartcols1...
I: Extracting libuuid1...
I: Extracting mount...
I: Extracting util-linux...
W: Failure trying to run: chroot /mnt/sda8 mount -t proc proc /proc
W: See /mnt/sda8/debootstrap/debootstrap.log for details


Contents of debootstrap.log:

gpgv: Signature made Sat Apr 25 18:26:22 2015 UTC using RSA key ID 541922FB
gpgv: Can't check signature: public key not found
gpgv: Signature made Sat Apr 25 18:26:22 2015 UTC using RSA key ID 541922FB
gpgv: Can't check signature: public key not found
gpgv: Signature made Sat Apr 25 18:26:22 2015 UTC using RSA key ID 541922FB
gpgv: Can't check signature: public key not found
gpgv: Signature made Sat Apr 25 18:26:22 2015 UTC using RSA key ID 541922FB
gpgv: Can't check signature: public key not found
dpkg-deb: error: error reading archive magic version number from file
/mnt/sda8/: Is a directory
chroot: failed to run command 'mount': No such file or directory
dpkg-deb: error: error reading archive magic version number from file
/mnt/sda8/: Is a directory
chroot: failed to run command 'mount': No such file or directory


On 29/04/2015, Edward Bartolo  wrote:
> I am using the Devuan patched debootstrap in Debian Testing.
> debootstrap failed with the following message:
>
> # debootstrap --arch amd64 stable /mnt/sda8
> http://packages.devuan.org/devuan
> I: Retrieving Release
> I: Retrieving Release.gpg
> I: Checking Release signature
> E: Release signed by unknown key (key id 94532124541922FB)
>
> Any helpful pointers are much appreciated.
> Thanks.
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Steve Litt]

On Wed, 29 Apr 2015 18:13:04 +0200
Didier Kryn  wrote:

> 
> 
> Le 29/04/2015 16:47, Steve Litt a écrit :
> >   maybe then we could eliminate the initramfs step entirely.:-)
> 
>  Sure that would be nice. It's something you can do for each 
> machine, but is not practical for a distro intended for all. Some 
> drivers, notably disk, raid, lvm, are necessary to mount your root 
> partition, and these drivers are so many, to match all possible
> hardware configs, that they would bloat the kernel if they were built
> "in kernel". 

I think I see what you're saying. If I hear you correctly, you're saying
that if you're using lvm, disk encryption, or raid, you can't even
mount the root partition without adding the drivers (with modprobe, I
assume), before the root partition is even mounted. And of course, to
do that, you'd have to have a functioning /dev tree.

Makes sense. Back when I used to go without initrd/initramfs, I used
ordinary ext? partitions and had all necessary commands and drivers on
the root filesystem. That would probably still work if I meet those two
conditions, but it's not a general solution.

Did I understand what you were saying?

Thanks,

SteveT

Steve Litt 
April 2015 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Feedback installing Devuan through debootstrap in Debian Testing.

[Franco Lanza]

On Wed, Apr 29, 2015 at 04:18:00PM +, Edward Bartolo wrote:
> 
> I am using the Devuan patched debootstrap in Debian Testing.
> debootstrap failed with the following message:

patched in debian testing would say the devuan debootstrao or the debian
one + patch?

dpkg -l | grep debootstrap  please

> # debootstrap --arch amd64 stable /mnt/sda8 http://packages.devuan.org/devuan
> I: Retrieving Release
> I: Retrieving Release.gpg
> I: Checking Release signature
> E: Release signed by unknown key (key id 94532124541922FB)
> 
> Any helpful pointers are much appreciated.
> Thanks.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 

Franco (nextime) Lanza
Lonate Pozzolo (VA) - Italy
SIP://c...@casa.nexlab.it
web: http://www.nexlab.net

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
---
echo 
16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq
 | dc
---



signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Hendrik Boom]

On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote:
> 
> I'm under the impression you can do most or all of what needs to be
> done in the actual init, rather than the initramfs. This gets a little
> complicated now that Linux has been "improved" by having /sbin
> and /bin be symlinks to /usr/bin, which might not be mounted in early
> boot, but aside from that, I think once you have possession of /bin
> and /sbin, then assuming that /etc is not a mountpoint, I think most
> other stuff can be delayed til the real init, always assuming that it's
> easier to put stuff in the on-disk init than in initramfs.

Is that Linux that has been "improved" by turning /sbin and /bin into 
symlinks?  Or is it Debian?  Or the systemd collection of distros?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Didier Kryn]

Le 29/04/2015 19:07, Steve Litt a écrit :

On Wed, 29 Apr 2015 18:13:04 +0200
Didier Kryn  wrote:



Le 29/04/2015 16:47, Steve Litt a écrit :

   maybe then we could eliminate the initramfs step entirely.:-)

  Sure that would be nice. It's something you can do for each
machine, but is not practical for a distro intended for all. Some
drivers, notably disk, raid, lvm, are necessary to mount your root
partition, and these drivers are so many, to match all possible
hardware configs, that they would bloat the kernel if they were built
"in kernel".

I think I see what you're saying. If I hear you correctly, you're saying
that if you're using lvm, disk encryption, or raid, you can't even
mount the root partition without adding the drivers (with modprobe, I
assume), before the root partition is even mounted. And of course, to
do that, you'd have to have a functioning /dev tree.

Makes sense. Back when I used to go without initrd/initramfs, I used
ordinary ext? partitions and had all necessary commands and drivers on
the root filesystem. That would probably still work if I meet those two
conditions, but it's not a general solution.

Did I understand what you were saying?

Yep. That's what I mean. Including not only lvm and raid but also 
the whole menagerie of disk drivers and filesystems. If you tune the OS 
for one hardware config, then better build the kernel with drivers included.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Didier Kryn]

Le 29/04/2015 22:34, Hendrik Boom a écrit :

On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote:

I'm under the impression you can do most or all of what needs to be
done in the actual init, rather than the initramfs. This gets a little
complicated now that Linux has been "improved" by having /sbin
and /bin be symlinks to /usr/bin, which might not be mounted in early
boot, but aside from that, I think once you have possession of /bin
and /sbin, then assuming that /etc is not a mountpoint, I think most
other stuff can be delayed til the real init, always assuming that it's
easier to put stuff in the on-disk init than in initramfs.

Is that Linux that has been "improved" by turning /sbin and /bin into
symlinks?  Or is it Debian?  Or the systemd collection of distros?

-- hendrik


Here's the story I read about /usr, and it sounds like the truth:

When people built the first Unix machine, the first disk, 
containing /bin went full but they needed to add more files to /bin . 
They decided to put them on the second disk which contained user data 
and was therefore mounted at /usr. Hence /usr/bin. It was a technical 
workaround for disk-size limitation.


Nowadays some distros got rid of /usr but still make it a symlink 
to / because of softwares that rely on it. If Debian is now doing sort 
of the opposite, it must be some trick. I've nothing against; as long as 
you keep /usr, use it at your will; it's all about convenience tricks.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Jude Nelson]

On Wed, Apr 29, 2015 at 5:46 PM, Didier Kryn  wrote:

>
>
> Le 29/04/2015 22:34, Hendrik Boom a écrit :
>
>> On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote:
>>
>>> I'm under the impression you can do most or all of what needs to be
>>> done in the actual init, rather than the initramfs. This gets a little
>>> complicated now that Linux has been "improved" by having /sbin
>>> and /bin be symlinks to /usr/bin, which might not be mounted in early
>>> boot, but aside from that, I think once you have possession of /bin
>>> and /sbin, then assuming that /etc is not a mountpoint, I think most
>>> other stuff can be delayed til the real init, always assuming that it's
>>> easier to put stuff in the on-disk init than in initramfs.
>>>
>> Is that Linux that has been "improved" by turning /sbin and /bin into
>> symlinks?  Or is it Debian?  Or the systemd collection of distros?
>>
>> -- hendrik
>>
>>  Here's the story I read about /usr, and it sounds like the truth:
>
> When people built the first Unix machine, the first disk, containing
> /bin went full but they needed to add more files to /bin . They decided to
> put them on the second disk which contained user data and was therefore
> mounted at /usr. Hence /usr/bin. It was a technical workaround for
> disk-size limitation.
>
> Nowadays some distros got rid of /usr but still make it a symlink to /
> because of softwares that rely on it. If Debian is now doing sort of the
> opposite, it must be some trick. I've nothing against; as long as you keep
> /usr, use it at your will; it's all about convenience tricks.


Even these days, in some UNIXes (OpenBSD comes to mind), /bin and /sbin
differ from /usr/bin and /usr/sbin in that they only contain
statically-linked programs.  This is useful for doing things like upgrading
the rest of the system, so you have a way to recover from catastrophic
errors (like /usr or /lib becoming unusable).

-Jude
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Didier Kryn]

Le 29/04/2015 23:54, Jude Nelson a écrit :


On Wed, Apr 29, 2015 at 5:46 PM, Didier Kryn > wrote:




Le 29/04/2015 22:34, Hendrik Boom a écrit :

On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote:

I'm under the impression you can do most or all of what
needs to be
done in the actual init, rather than the initramfs. This
gets a little
complicated now that Linux has been "improved" by having /sbin
and /bin be symlinks to /usr/bin, which might not be
mounted in early
boot, but aside from that, I think once you have
possession of /bin
and /sbin, then assuming that /etc is not a mountpoint, I
think most
other stuff can be delayed til the real init, always
assuming that it's
easier to put stuff in the on-disk init than in initramfs.

Is that Linux that has been "improved" by turning /sbin and
/bin into
symlinks?  Or is it Debian?  Or the systemd collection of distros?

-- hendrik

Here's the story I read about /usr, and it sounds like the truth:

When people built the first Unix machine, the first disk,
containing /bin went full but they needed to add more files to
/bin . They decided to put them on the second disk which contained
user data and was therefore mounted at /usr. Hence /usr/bin. It
was a technical workaround for disk-size limitation.

Nowadays some distros got rid of /usr but still make it a
symlink to / because of softwares that rely on it. If Debian is
now doing sort of the opposite, it must be some trick. I've
nothing against; as long as you keep /usr, use it at your will;
it's all about convenience tricks.


Even these days, in some UNIXes (OpenBSD comes to mind), /bin and 
/sbin differ from /usr/bin and /usr/sbin in that they only contain 
statically-linked programs. This is useful for doing things like 
upgrading the rest of the system, so you have a way to recover from 
catastrophic errors (like /usr or /lib becoming unusable).

-Jude
That's a very sensible reason; you may have noticed I like static 
linking :-) . Another argument is that /usr/bin and /usr/lib are bloated 
and may be mounted on a different partition, while basic tools in /bin 
and /lib/libc.so, which are needed at startup, are in the root filesystem.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Joerg Reisenweber]

On Wed 29 April 2015 23:46:51 Didier Kryn wrote:
> They decided to put them on the second disk which contained user data 
> and was therefore mounted at /usr
AFAIK that's "Unix System Resources" or somesuch, not "User"
/j

signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Feedback installing Devuan through debootstrap in Debian Testing.

[David Hare]

debootstrap --exclude systemd,systemd-sysv,libsystemd0 jessie .

without specifying a URL is working here (are the excludes needed?)

However after I chroot it and apt update:

W: GPG error: http://packages.devuan.org jessie InRelease: The following 
signatures were invalid: BADSIG 94532124541922FB Devuan Repository 
(Primary Devuan signing key) 


"devuan-keyring" is installed.




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Isaac Dunham]

On Wed, Apr 29, 2015 at 12:33:52AM -0400, Jude Nelson wrote:
> Hi Isaac,
> 
> [Snip]
> 
> >
> > Theoretically, it *should* work if /etc/{passwd,group} are present in the
> > initramfs, with those paths. It's possible to mistakenly copy them to /
> > instead of /etc, but I assume that you've already checked that.
> >
> > Detail that shouldn't make a difference but might:
> > static or non-static busybox?
> 
> Not sure; will find out and let you know if it makes a difference.

If you installed "busybox" and not "busybox-static", it's dynamically linked.

[snip]
> > -double-check that you have a non-empty passwd/groups file, containing
> > the same users/groups and world-readable.

> Does it have to be world-readable even if the chown(2) happens from a
> process with uid=0?  I verified that they're non-empty, and verified that I
> was unable to (as root) use busybox chown from the initramfs shell.

In theory, you only need the process to be able to read /etc/passwd and
/etc/group, which should be enough for getpwent()/getgrent() to succeed.
Standard is chmod 0644, since every user and program may lookup the
username.

I've tried replicating, and cannot; I use busybox-static.
Example (from memory):

cat /etc/group
# note that "netdev" is a valid group
cat /etc/passwd
# note that only "root" is a user now
touch /tmp/tbnetdev
ls -l /tmp/tbnedev
# note that this is root:root
chown root:netdev /tmp/tbnetdev
ls -l /tmp/tbnetdev
# note that it is now root:netdev


> > To debug it:
> > -Add ltrace (with dependencies) and a *non-static* busybox to your
> > initramfs and try running
> >  ltrace busybox chown USER:GROUP FILE
> >
> > This shows you the functions that are called, so you can check if they
> > return success.
> 
> I will add ltrace (and ldd) to my initramfs and try this out :)
 
OK, I'm curious to hear your results.

> > > * As Anto's experience shows, getting a working initramfs is tedious to
> > do
> > > and easy to get wrong.  This is not only because there are multiple init
> > > systems that vdevd will need to work with (e.g. sysv-rc, file-rc, openrc,
> > > etc.), but also init scripts and initramfs scripts that come from
> > packages
> > > that depend on udev are (unsurprisingly) tightly coupled to udev.  This
> > > makes it difficult to install vdevd on a running Debian system without
> > > removing udev (which is in itself undesirable, since it will take a large
> > > swath of packages out with it), since I have to pretty much fork both
> > sets
> > > of scripts and try to mash them up into a custom initramfs without
> > altering
> > > /usr/share/initramfs-tools.  This is effectively what my (extremely
> > kludgy)
> > > initramfs Makefile does.
> >
> > Check what I did with mdev (in hooks/ directory of github.com/idunham/mdev
> > );
> > I did *not* find that initramfs-tools was at all tightly coupled with udev,
> > to the point that dropping the correct scripts into
> > /usr/share/initramfs-tools and convincing dpkg that it didn't need udev
> > was quite adequate.

> Thanks for the link!  It's good to get feedback from someone who's packaged
> a device manager before :)

Glad to help.
Reading the mkinitramfs manpage, I see that "-d" looks like it would be
useful to you.

> Regarding setting up the initramfs, my experience is a bit more involved.
> I had to patch initramfs-tool's init script so it wouldn't try to mount
> devtmpfs, and wouldn't try to pull in udev config files or migrate udev's
> info from /run.  This is because to the best of my knowledge, the only
> reason devtmpfs needs to be mounted at all is because udev no longer
> creates device files on its own (it only changes ownership and adds
> symlinks).  However, using devtmpfs will be problematic for libudev-compat,
> which relies on inotify(2) to detect device changes (i.e. a device file
> that shows up in devtmpfs from the kernel does not generate an inotify
> event).

Rats.
Does mknod(...) = -1 EEXIST trigger an inotify event?

> > > What we'll need is a well-written .deb post-install script that:
> > > * sets up config files needed to generate persistent device names
> >
> > Install config files, marked as such.
> 
> It's more involved than that--the /etc/vdev/ifnames.conf file needs to be
> generated from the host's network interfaces, for example (like the
> /etc/udev/rules.d directory).  But obviously surmountable :)
 
Ah, yes. "*Persistent* device names".
Personally, I've never had an occasion to use them, and figure that
loading the drivers manually in order would be enough if I wanted that.

/sys/class/net// may have the information on Linux.
 
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng