Re: [Dng] Live ISO's (Jessie with no systemd)
Don't know why but some of my posts didn't seem to make the mailing list properly so will try again! On 13/04/15 13:57, David Hare wrote: On 13/04/15 06:19, Franco Lanza wrote: What about being devuan maintainers and contribute those packages to devuan? Well, my intention is to promote Devuan and in future contribute whatever I can. I'm quite new to packaging and began this late 2014 before any Devuan structure existed, for my own use. Some of them are now outdated. Others (e.g. consolekit2, sane-utils) seem unavailable elsewhere so far. These packages are freely available, mostly including sources. I now use in preference Devuan packages, if available. what is the default root password XFCE image: user user root root TDE image (same as standard Debian-live): user live No root password set Sudo is configured for both images so will work. The XFCE image was made from a clean (devuan version) debootstrap using --exclude=systemd-sysv From there *systemd* was exluded in apt preferences, Devuan and other repos configured then Devuan util-linux packages installed in chroot. It was then possible to purge *all* *systemd* components and build the rest of the system, using package lists piped to apt. No systemd shim is used. The custom script I use is posted at the same location as the iso, as is the installed package list (from which you can grep "nosystemd" to view the modified package versions). I've always liked the Refracta look. +1. Before I saw Refracta I thought XFCE could not be other than butt-ugly. I added a set of themes and user configs similar to Refracta7 as well as the Refracta tools (snapshot, installer, refracta2usb). This is partly aimed at also helping the Refracta project although I don't know if an "official" Refracta Jessie ISO is actually planned. Regarding TDE, the DE itself has nothing requiring systemd except dbus, for which clean Devuan packages are available. GTK and QT4 are also not required since TDE has forked QT3, so also less bloat. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Live ISO's (Jessie with no systemd)
On 04/16/2015 09:37 AM, David Hare wrote: > Don't know why but some of my posts didn't seem to make the mailing list > properly so will try again! Make sure you click "Reply List" and not "Reply". I've done that a couple times. > > On 13/04/15 13:57, David Hare wrote: >> On 13/04/15 06:19, Franco Lanza wrote: >>> what is the default root password >> >> XFCE image: >> >> user user root root >> There appears to be no root password in the xfce image. There's only an asterisk in /etc/shadow. >> >> +1. Before I saw Refracta I thought XFCE could not be other than >> butt-ugly. I added a set of themes and user configs similar to >> Refracta7 as well as the Refracta tools (snapshot, installer, >> refracta2usb). This is partly aimed at also helping the Refracta >> project although I don't know if an "official" Refracta Jessie ISO is >> actually planned. >> I don't know if there will be an official Refracta Jessie, either. Still haven't decided. But yours (David) looks more like refracta than the current refracta isos, so it's a candidate for officialdom. On 04/13/2015 03:00 PM, Richard wrote:> > > *2. # sudo apt-get update* failed, > reporting conflicting distros ... (expected sid but got ceres); > also NO_PUBKEY. Just for information, I know it's still fresh. > I don't think Richard got an answer to this question. I was able to make those error messages go away, but I don't know if it's the best course of action (especially for the devuan repo.) If there's some reason for NOT doing the following, somebody please speak up. - edit /etc/sources.list.d/devuan.list and change "sid" to "ceres". - get the gpg key for the angband repo with the following commands: gpg --recv-keys 719DCC80BED007F9 gpg --export --armor 719DCC80BED007F9 | apt-key add - (and don't forget the dash at the end of the line) Then apt-get update. fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Live ISO's (Jessie with no systemd)
Yes, I think it is a worthwhile candidate for Refracta. The above should fix the update errors. Will do it later. I massaged fstab to get it to play well with other distros. And it looks good with no systemd. On Thu, Apr 16, 2015 at 10:59 AM, fsmithred wrote: > On 04/16/2015 09:37 AM, David Hare wrote: > > Don't know why but some of my posts didn't seem to make the mailing list > > properly so will try again! > > Make sure you click "Reply List" and not "Reply". I've done that a couple > times. > > > > > On 13/04/15 13:57, David Hare wrote: > >> On 13/04/15 06:19, Franco Lanza wrote: > > >>> what is the default root password > >> > >> XFCE image: > >> > >> user user root root > >> > > There appears to be no root password in the xfce image. There's only an > asterisk in /etc/shadow. > > >> > >> +1. Before I saw Refracta I thought XFCE could not be other than > >> butt-ugly. I added a set of themes and user configs similar to > >> Refracta7 as well as the Refracta tools (snapshot, installer, > >> refracta2usb). This is partly aimed at also helping the Refracta > >> project although I don't know if an "official" Refracta Jessie ISO is > >> actually planned. > >> > > I don't know if there will be an official Refracta Jessie, either. Still > haven't decided. But yours (David) looks more like refracta than the > current refracta isos, so it's a candidate for officialdom. > > > > On 04/13/2015 03:00 PM, Richard wrote:> > > > > *2. # sudo apt-get update* failed, > > reporting conflicting distros ... (expected sid but got ceres); > > also NO_PUBKEY. Just for information, I know it's still fresh. > > > > I don't think Richard got an answer to this question. I was able to make > those error messages go away, but I don't know if it's the best course of > action (especially for the devuan repo.) If there's some reason for NOT > doing the following, somebody please speak up. > > - edit /etc/sources.list.d/devuan.list and change "sid" to "ceres". > - get the gpg key for the angband repo with the following commands: > gpg --recv-keys 719DCC80BED007F9 > gpg --export --armor 719DCC80BED007F9 | apt-key add - > (and don't forget the dash at the end of the line) > > Then apt-get update. > > fsr > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Live ISO's (Jessie with no systemd)
There appears to be no root password in the xfce image. There's only an asterisk in /etc/shadow. Maybe my mistake, there was meant to be. However should work (from where you can set a root password if wanted) That's the usual debian-live type setup anyway. For anyone interested in the TDE image, it's worth noting that TDE is fully functional without many of the gtk-orientated packages which had to be recompiled (consolekit, policykit udisks2 et al) Also TDE does not need GTK nor QT4. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Purpose of systemd-shim
On 2015-04-15 19:01, Hendrik Boom wrote: > On Wed, Apr 15, 2015 at 06:39:29PM +0200, Franco Lanza wrote: > > On Wed, Apr 15, 2015 at 01:22:28PM +0200, Paul van der Vlis wrote: > > > > > > systemd-shim is for when you *don't* want systemd. > > > > Yes, but cause of you have things that depend on components of systemd. > > We don't want systemd nor anything depending on components from systemd, > > so, we don't want the shim too. > > > > systemd-shim is for who don't want to have systemd in pid 1 but accept > > other systemd components. We don't want systemd at all. > > Is this really true? Or is systemd to handle components that have > nothing to do with systemd except that they were, unfortunately, > developed on a system where they had to use systemd to access system > services that were formerly, and are elsewhere, handled by other, more > traditional means? > > -- hendrik Heyo. Wanted to see how things are going. The main purpose of a systemd-shim is to allow code that depends on systemd to be compiled and execute cleanly, without having to actually introduce a binary dependency on systemd. Whether or not that is actually a laudable goal is the subject of much debate. >From a user standpoint, it lets them use software that they might not otherwise have on Devuan. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Purpose of systemd-shim
On Thu, Apr 16, 2015 at 2:51 AM, T.J. Duchene wrote: > From a user standpoint, it lets them use software that they might not > otherwise have on Devuan. Yet. Right? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Purpose of systemd-shim
On 16/04/15 03:51, T.J. Duchene wrote: Heyo. Wanted to see how things are going. The main purpose of a systemd-shim is to allow code that depends on systemd to be compiled and execute cleanly, without having to actually introduce a binary dependency on systemd. Whether or not that is actually a laudable goal is the subject of much debate. From a user standpoint, it lets them use software that they might not otherwise have on Devuan. Hello T.J., This is my personal opinion and I don't know what will happen to Devuan even in the next 6 months or so. I think your comment apply to all available software for Linux, so none is available in Devuan at the moment. As far as I understood, the sort term plan of Devuan is to cherry pick the most important Debian packages containing anything linked to systemd and strip them up. I think after the release of the initial Devuan version, along the time the "good to have" packages from Debian will be stripped as well step by step. So in the end, your comment is not valid any more as Devuan users can use all available packages for Linux without systemd and anything related to systemd. I see no point for Devuan to provide any kind of shims so that the users can use packages that depend on systemd component, as I can just use Debian now. Let's see the progress next year whether that will really happen or there will be no Devuan at all. Cheers, Anto ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Purpose of systemd-shim
On Thu, 4/16/15, Anto wrote: Subject: Re: [Dng] Purpose of systemd-shim To: dng@lists.dyne.org Date: Thursday, April 16, 2015, 1:05 PM > This is my personal opinion and I don't know what will happen to Devuan > even in the next 6 months or so. > > I think your comment apply to all available software for Linux, so none > is available in Devuan at the moment. As far as I understood, the sort > term plan of Devuan is to cherry pick the most important Debian packages > containing anything linked to systemd and strip them up. I think after > the release of the initial Devuan version, along the time the "good to > have" packages from Debian will be stripped as well step by step. So in > the end, your comment is not valid any more as Devuan users can use all > available packages for Linux without systemd and anything related to > systemd. > > I am looking forward to packages stripped of systemd. If I want one that has dependencies, I will consider that it excellent opportunity for a donation. :D golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Fwd: [dng] vdev status update
Hi Anto, Sorry for the late reply; I had been super busy with work over the last 24 hours. On Wed, Apr 15, 2015 at 2:43 PM, Anto wrote: > On 15/04/15 05:20, Jude Nelson wrote: > >> Hi Anto, >> >> >> Don't you want to know my setup? >> >> Yes, eventually :)  However, I don't want to waste your time either, at >> least until I am more confident that the vdev installation process works >> correctly. >>  >> >> Maybe there are some packages required by your vdev, but I don't >> have them installed on my PC. Or maybe the kernel 3.18.10 that I >> use require different treatment, so I need to use different kernel >> version to test your vdev. I think knowing that could help you >> troubleshoot the problem. I am really not sure the requirements to >> properly test your vdev at this stage. So perhaps having the same >> setup as your development environment could avoid any unnecessary >> issues. >> >> >> Well, there is one thing, if you're not too busy and it's not too >> inconvenient for you. Vdev logs its early boot messages to >> /run/vdev/vdevd.boot.log. If you could capture that file and send it to >> me, that would not only help me understand your setup, but also why vdev is >> misbehaving. >> >> Better yet, from the initramfs shell, if you could run "vdevd -v2 -f -c >> /etc/vdev/vdevd.conf --once /dev > /tmp/vdev-debugging.log" and send me the >> contents of /tmp/vdev-debugging.log, that will not only populate /dev >> (assuming vdevd works correctly on that invocation), but also generate a >> lot of extra debugging information in /tmp/vdev-debugging.log that would >> help me diagnose the problem. >> >> No worries if you're too busy or have better things to do, though :) >> >> Thanks again, >> Jude >> > > Hello Jude, > > Let's just say that I am doing this egoistically all for myself. :) So I > will devote my time to test your vdev as much as I can. > > Unfortunately, I cannot get the debugging log that you are after. Using > kernel 3.18.10 and 3.18.11, the keyboard was not being detected after it > got to the (initramfs) prompt, so I could not type anything. I managed to > execute the debugging command using kernel 3.2.0, but it didn't seem to > write the log to the /tmp directory. I think that is due the disk was not > detected. I could only capture the last messages using the camera of my old > mobile phone, so the quality is not good. Please have a look on > https://minifora.eu/public/devuan/vdev/vdev_debugging_15Apr15_3.jpg. > Thanks for sending me the picture :) The "rc = -17" error code means that the device exists (i.e. it's -EEXIST). If you look in /dev from the initramfs, you should see a bunch of device files. The "rc = -2" at the end is a minor bug--vdevd didn't create /dev/pts/ptmx, so it couldn't look up any metadata under /dev/vdev for it (i.e. rc == -2 is -ENOENT). That by itself shouldn't prevent root from mounting, though. Do you have devtmpfs mounted on /dev? That could be the reason it doesn't boot. At this time, if a device file exists that vdevd did not create, vdevd won't run any helper scripts for it when it processes it. If your root partition device file exists (e.g. /dev/sda1) since e.g. devtmpfs created it, and your /etc/fstab identifies your root device partition using a persistent path (e.g. /dev/disk/by-uuid/... or the like), vdevd won't generate the persistent path, since that's done by the helper scripts for /dev/sda1. As such, the script routines that parse /etc/fstab won't find the root device, and the initramfs init will abort and drop you into a shell. For those who don't know, devtmpfs is basically a no-frills devfs that modern udev now requires to be mounted to work correctly (i.e. devtmpfs makes the device files these days, not udev). vdevd is currently not compatible with devtmpfs, since it expects to create all the device files itself. I'll update the Linux port to check of devtmpfs is mounted before running, so vdevd will still run the helper scripts even if devtmpfs created the device files already. > I am not sure if this would be relevant. I am using file-rc instead of > sysv-rc, so I didn't actually have any /etc/rc?.d directories. After the > installation of the "example", /etc/rcS.d directory and S02vdev link under > it got created. It could possibly be a problem later on, but I think I will > worry about that (add it into /etc/runlevel.conf) after the boot process > can reach it. > That is relevant! I had assumed in the Makefile that the user is using sysv-rc, with the /etc/rc*.d/ directories. I'm not familiar with using file-rc, but I don't think it's involved in the initramfs boot process (at least, not directly). That's all controlled by the files in /usr/share/initramfs-tools/. However, I'd be happy to patch the Makefile in example/ to install the vdev init script correctly for file-rc users :) I just need to know what to do--could you maybe send me a small script that would achieve this? Th
Re: [Dng] Fwd: [dng] vdev status update
On 16/04/15 21:49, Jude Nelson wrote: Hi Anto, Sorry for the late reply; I had been super busy with work over the last 24 hours. Don't worry, Jude. You are not working for anyone or any companies who breath on your neck to complete vdev tomorrow, are you? :) Thanks for sending me the picture :) You are welcome. The quality of the picture is bad as I was quite hungry that night and I wanted to go out. So I just took it with any camera around me. I will try to get a better picture next time. Or it would better if you could let me know how to log that kind of early stage boot messages, possibly via Ethernet or USB interfaces (if that would be possible at all), so that you can have a complete error messages. The "rc = -17" error code means that the device exists (i.e. it's -EEXIST). If you look in /dev from the initramfs, you should see a bunch of device files. The "rc = -2" at the end is a minor bug--vdevd didn't create /dev/pts/ptmx, so it couldn't look up any metadata under /dev/vdev for it (i.e. rc == -2 is -ENOENT). That by itself shouldn't prevent root from mounting, though. Do you have devtmpfs mounted on /dev? That could be the reason it doesn't boot. At this time, if a device file exists that vdevd did not create, vdevd won't run any helper scripts for it when it processes it. If your root partition device file exists (e.g. /dev/sda1) since e.g. devtmpfs created it, and your /etc/fstab identifies your root device partition using a persistent path (e.g. /dev/disk/by-uuid/... or the like), vdevd won't generate the persistent path, since that's done by the helper scripts for /dev/sda1. As such, the script routines that parse /etc/fstab won't find the root device, and the initramfs init will abort and drop you into a shell. I am not really sure if I understood what you explained. I don't think I have devtmpfs on my PC when I use the working initrd. The one mounted on /dev with the type of devtmpfs is udev. Here are the output of mount and the content of my fstab. root@hp8530w:~# uname -a Linux hp8530w 3.18.11-1v1-hp8530w #1 SMP Wed Apr 15 00:49:22 CEST 2015 x86_64 GNU/Linux root@hp8530w:~# root@hp8530w:~# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=492536,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=401084k,mode=755) /dev/disk/by-uuid/c0e1e620-5636-48f2-90dd-4d246d58b815 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1641020k) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) /dev/sda2 on /home type ext4 (rw,relatime,data=ordered) root@hp8530w:~# root@hp8530w:~# cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # # / was on /dev/sda1 during installation UUID=c0e1e620-5636-48f2-90dd-4d246d58b815 / ext4 errors=remount-ro 0 1 # /home was on /dev/sda2 during installation UUID=5be7af77-0d10-4685-989f-1004b1eabec8 /home ext4 defaults0 2 # swap was on /dev/sda3 during installation UUID=3a37a27d-84cc-4d06-9920-5419bb4ccbae noneswap sw 0 0 # /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/cdrom1/media/cdrom0 udf,iso9660 user,noauto 0 0 # /dev/cdrom/media/cdrom0 udf,iso9660 user,noauto 0 0 root@hp8530w:~# For those who don't know, devtmpfs is basically a no-frills devfs that modern udev now requires to be mounted to work correctly (i.e. devtmpfs makes the device files these days, not udev). vdevd is currently not compatible with devtmpfs, since it expects to create all the device files itself. I'll update the Linux port to check of devtmpfs is mounted before running, so vdevd will still run the helper scripts even if devtmpfs created the device files already. I am not sure if this would be relevant. I am using file-rc instead of sysv-rc, so I didn't actually have any /etc/rc?.d directories. After the installation of the "example", /etc/rcS.d directory and S02vdev link under it got created. It could possibly be a problem later on, but I think I will worry about that (add it into /etc/runlevel.conf) after the boot process can reach it. That is relevant! I had assumed in the Makefile that the user is using sysv-rc, with the /etc/rc*.d/ directories. I'm not familiar with using file-rc, but I don't think it's involved in the initramfs boot process
Re: [Dng] Purpose of systemd-shim
On Thu, 16 Apr 2015 12:17:43 -0700 Go Linux wrote: > > > On Thu, 4/16/15, Anto wrote: > > Subject: Re: [Dng] Purpose of systemd-shim > To: dng@lists.dyne.org > Date: Thursday, April 16, 2015, 1:05 PM > > > > This is my personal opinion and I don't know what will happen to > > Devuan even in the next 6 months or so. > > > > I think your comment apply to all available software for Linux, so > > none is available in Devuan at the moment. As far as I understood, > > the sort term plan of Devuan is to cherry pick the most important > > Debian packages containing anything linked to systemd and strip > > them up. I think after the release of the initial Devuan version, > > along the time the "good to have" packages from Debian will be > > stripped as well step by step. So in the end, your comment is not > > valid any more as Devuan users can use all available packages for > > Linux without systemd and anything related to systemd. > > > > > > I am looking forward to packages stripped of systemd. If I want one > that has dependencies, I will consider that it excellent opportunity > for a donation. :D > > golinux Also, if one really, really, really needs a systemd burdened software, he could always run it in a Docker container. Unless Docker starts requiring systemd. SteveT Steve Litt 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] Fwd: [dng] vdev status update
Hi Anto, I just committed preliminary support for using vdevd with devtmpfs. vdevd should automatically detect whether or not devtmpfs is mounted on /dev, and nevertheless run device setup scripts (by using its own device metadata tree in /dev/vdev/ to see whether or not the device was actually processed). NB for developers: this problem isn't specific to Linux--I expect to encounter it with FreeBSD as well, since it has a full-blown in-kernel devfs. vdevd will keep track of "OS quirks" in the future--one of which is the "Device Already Exists" quirk, whereby vdevd simply expects the OS to provide the device file (regardless of the mechanism). The Linux-specific vdevd back-end now checks to see if vdevd will create files on a devtmpfs filesystem, and enables that quirk if so. Funny, undocumented (!!) discovery: the devtmpfs filesystem type (see statfs(2)) is the same (!!) as the tmpfs filesystem type, despite being a fundamentally different filesystem. I'm surprised that this wasn't caught during the devtmpfs code review--guess I'll have to file a bug report. Anyway, if you find yourself wondering why vdev has to detect devtmpfs by parsing /proc/mounts and verifying that the realpath of the mountpoint is the same as or is a subdirectory of a devtmpfs mountpoint, that's why--we (currently) can't rely on the f_fsid in statfs(2) or statvfs(2). Thanks, Jude On Thu, Apr 16, 2015 at 8:28 PM, Jude Nelson wrote: > Hi Anto, > > [snip] > >> I am not really sure if I understood what you explained. I don't think I >> have devtmpfs on my PC when I use the working initrd. The one mounted on >> /dev with the type of devtmpfs is udev. Here are the output of mount and >> the content of my fstab. >> >> root@hp8530w:~# uname -a >> Linux hp8530w 3.18.11-1v1-hp8530w #1 SMP Wed Apr 15 00:49:22 CEST 2015 >> x86_64 GNU/Linux >> root@hp8530w:~# >> root@hp8530w:~# mount >> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) >> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) >> udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_ >> inodes=492536,mode=755) >> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime, >> gid=5,mode=620,ptmxmode=000) >> tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime, >> size=401084k,mode=755) >> /dev/disk/by-uuid/c0e1e620-5636-48f2-90dd-4d246d58b815 on / type ext4 >> (rw,relatime,errors=remount-ro,data=ordered) >> tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec, >> relatime,size=5120k) >> tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec, >> relatime,size=1641020k) >> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) >> /dev/sda2 on /home type ext4 (rw,relatime,data=ordered) >> root@hp8530w:~# >> > > You have devtmpfs mounted. It's this line here: > > > udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_ > inodes=492536,mode=755) > > If you run "mount" while in the initramfs, you might see devtmpfs as > well. If so, then please make sure that you're using vdev's initramfs > "init" script in example/initramfs/init, instead of the one in > /usr/share/initramfs-tools/init. Vdev's init does not mount devtmpfs, but > initramfs-tool's init does. Devtmpfs cannot be mounted on /dev while vdev > is running (but I'll fix this soon). > > >> root@hp8530w:~# cat /etc/fstab >> # /etc/fstab: static file system information. >> # >> # Use 'blkid' to print the universally unique identifier for a >> # device; this may be used with UUID= as a more robust way to name devices >> # that works even if disks are added and removed. See fstab(5). >> # >> # >> # / was on /dev/sda1 during installation >> UUID=c0e1e620-5636-48f2-90dd-4d246d58b815 / ext4 >> errors=remount-ro 0 1 >> # /home was on /dev/sda2 during installation >> UUID=5be7af77-0d10-4685-989f-1004b1eabec8 /home ext4 defaults >> 0 2 >> # swap was on /dev/sda3 during installation >> UUID=3a37a27d-84cc-4d06-9920-5419bb4ccbae noneswap sw >> 0 0 >> # /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 >> /dev/cdrom1/media/cdrom0 udf,iso9660 user,noauto 0 0 >> # /dev/cdrom/media/cdrom0 udf,iso9660 user,noauto 0 0 >> root@hp8530w:~# > > > This is more evidence to me that the reason you got dropped into a shell > in the initramfs was because vdev saw the /dev/sd* device files from > devtmpfs, and (incorrectly) thought that they had already been processed > and thus didn't go on to generate > /dev/disk/by-uuid/c0e1e620-5636-48f2-90dd-4d246d58b815, > /dev/disk/by-uuid/5be7af77-0d10-4685-989f-1004b1eabec8, and > /dev/disk/by-uuid/3a37a27d-84cc-4d06-9920-5419bb4ccbae. Again, the fix > for now is to ensure that devtmpfs isn't mounted :) > > >> >> >> For those who don't know, devtmpfs is basically a no-frills devfs that >>> modern udev now requires to be mounted to work correctly (i.e. devtmpfs >>> makes the device files these days, not udev). vdevd is currently not >>> compatible with
[Dng] Devuan financial report
The donations page [0] says "Next one is due by the end of March 2015." Did I miss it? == hk [0]: https://devuan.org/donate.html -- _ _ We are free to share code and we code to share freedom (_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan financial report
On April 17, 2015 6:30:12 AM GMT+02:00, hellekin wrote: >The donations page [0] says "Next one is due by the end of March 2015." > >Did I miss it? no, I am late. I'm about to do it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
