[DNG] Broken package version numbers in ascii
After upgrading from Devuan Jessie to Devuan Ascii, I found that some packages were not properly upgraded because of wrong version numbers. Example: desktop-base is version 1:0.99 in ascii, but had a higher version number in Jessie before, so the dist-upgrade kept the Jessie version. I cleaned those packages with synaptic, downgraded such packages to the "testing" version, or removed and reinstalled these, where a downgrade was not possible because of dependencies. I now have a clean ascii install without orphaned packages. But now I'm missing some Devuan theme files, like grub oder slim theme. Which package contains the Devuan theme files in ascii? Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Broken package version numbers in ascii
Am 2017-12-26 17:37, schrieb J. Fahrner: I now have a clean ascii install without orphaned packages. But now I'm missing some Devuan theme files, like grub oder slim theme. Which package contains the Devuan theme files in ascii? I found my old netbook which yet has Jessie installed. The Jessie version of desktop-base is 1:1.2 and contains the slim theme. The Ascii version is 1:0.99 and does NOT contain the slim theme. Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Broken package version numbers in ascii
On 12/26/2017 11:57 AM, J. Fahrner wrote: > Am 2017-12-26 17:37, schrieb J. Fahrner: > >> I now have a clean ascii install without orphaned packages. But now >> I'm missing some Devuan theme files, like grub oder slim theme. Which >> package contains the Devuan theme files in ascii? > > I found my old netbook which yet has Jessie installed. The Jessie version > of desktop-base is 1:1.2 and contains the slim theme. The Ascii version is > 1:0.99 and does NOT contain the slim theme. > > Jochen The new version of desktop-base for ascii will probably be version 2.0, and it should be in the repo soon. (within a couple of days, I think.) You will be able to upgrade from either the jessie version or the old ascii version. You could use the jessie version (1.2) and the clearlooks-phenix-purpy-theme, but some elements of the theme won't work right because of gtk3. fsmithred ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] eudev missing dependency
Hi, udevd calls mtp-probe: udevd[436]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe /sys/devices/pci:00/:00:14.0/usb3/3-4 3 2': No such file or directory mtp-probe is contained in libmtp-runtime, so eudev should have a dependency to libmtp-runtime. Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] eudev naming of network interfaces
Hi, is there some problem with the naming of network interfaces? I have the following lines in my boot log: Sat Dec 23 10:41:48 2017: [] Configuring network interfaces...ifquery: unknown interface eth0 Sat Dec 23 10:41:48 2017: ifup: unknown interface eth0 Sat Dec 23 10:41:48 2017: FAIL failed. My /etc/network/interfaces contains no eth0: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev naming of network interfaces
On 171226-19:17+0100, J. Fahrner wrote: > Hi, > is there some problem with the naming of network interfaces? > > I have the following lines in my boot log: > > Sat Dec 23 10:41:48 2017: [] Configuring network interfaces...ifquery: > unknown interface eth0 > Sat Dec 23 10:41:48 2017: ifup: unknown interface eth0 > Sat Dec 23 10:41:48 2017: FAIL failed. > > My /etc/network/interfaces contains no eth0: > > # This file describes the network interfaces available on your system > # and how to activate them. For more information, see interfaces(5). > > # The loopback network interface > auto lo > iface lo inet loopback What ethers you have? Try: # ip l show and get back with the output. If no ethers recognized: drivers missing? The ethN (where N can be 0,1... ) has been discussed a few times over on this ML. Try searching on https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng (included in all mails) E.g. the important file is: /etc/udev/rules.d/70-persistent-net.rules (comments there to read) I have eudev, and I always set that file up manually to my liking. I also have: # cat /etc/default/grub | grep ifnames GRUB_CMDLINE_LINUX="net.ifnames=0" # to rid me of stupid --and non-persistent, falsely claiming to be persistent-- naming. -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev naming of network interfaces
On Tue, 2017-12-26 at 19:17 +0100, J. Fahrner wrote: > Hi, > is there some problem with the naming of network interfaces? > > I have the following lines in my boot log: > > Sat Dec 23 10:41:48 2017: [] Configuring network > interfaces...ifquery: unknown interface eth0 > Sat Dec 23 10:41:48 2017: ifup: unknown interface eth0 > Sat Dec 23 10:41:48 2017: FAIL failed. > > My /etc/network/interfaces contains no eth0: > > # This file describes the network interfaces available on your system > # and how to activate them. For more information, see interfaces(5). > > # The loopback network interface > auto lo > iface lo inet loopback Please state which version of eudev you have installed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev naming of network interfaces
Am 2017-12-26 19:47, schrieb Svante Signell: Sat Dec 23 10:41:48 2017: [] Configuring network interfaces...ifquery: unknown interface eth0 Sat Dec 23 10:41:48 2017: ifup: unknown interface eth0 Sat Dec 23 10:41:48 2017: FAIL failed. Please state which version of eudev you have installed. eudev 3.2.2-9 from Ascii. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev naming of network interfaces
Am 2017-12-26 19:41, schrieb Miroslav Rovis: What ethers you have? Try: # ip l show $ ip l show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 3c:97:0e:cb:ce:d7 brd ff:ff:ff:ff:ff:ff 3: wwan0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 26:77:58:61:50:ac brd ff:ff:ff:ff:ff:ff 4: wlan0: mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000 link/ether 6c:88:14:9d:7d:70 brd ff:ff:ff:ff:ff:ff eth0 works normal in network-manager. The error is only during boot. I'm wondering why ifup tries to activate eth0, since this is not in /etc/network/interfaces. Where does this info come from, that it should enable eth0? Does it come from udevd? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev naming of network interfaces
On 171226-20:04+0100, J. Fahrner wrote: > Am 2017-12-26 19:41, schrieb Miroslav Rovis: > > What ethers you have? Try: > > > > # ip l show > > $ ip l show > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode > DEFAULT group default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > 2: eth0: mtu 1500 qdisc pfifo_fast state > DOWN mode DEFAULT group default qlen 1000 > link/ether 3c:97:0e:cb:ce:d7 brd ff:ff:ff:ff:ff:ff > 3: wwan0: mtu 1500 qdisc noop state DOWN mode DEFAULT > group default qlen 1000 > link/ether 26:77:58:61:50:ac brd ff:ff:ff:ff:ff:ff > 4: wlan0: mtu 1500 qdisc mq state UP mode > DORMANT group default qlen 1000 > link/ether 6c:88:14:9d:7d:70 brd ff:ff:ff:ff:ff:ff So the drivers are compiled fine and working. > eth0 works normal in network-manager. I don't use network-manager. > The error is only during boot. I'm > wondering why ifup tries to activate eth0, since this is not in > /etc/network/interfaces. Where does this info come from, that it should > enable eth0? Does it come from udevd? Dunno. Look up: /etc/init.d/networking /etc/default/networking /run/network/* for clues... Ah, I remember on Gentoo (long months ago now that I'm not running it), if you didn't want an interface, or wanted no interface, we could set it up in the conf file of our package which was/is called netifrc IIRC. Maybe you shouldn't just leave /etc/network/interfaces completely unconfigured... But don't know. BTW I'm running Ceres, which is probably certainly less comfortable than Ascii, a suspected bugs here and there (never yet time enough to study them and report them --it's also insfufficient knowledge--), or simply incompletenesses... I hoped otherwise, but Ceres almost looks to big to me to digest :-( . Will still be trying to sort it for a little while longer... Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev naming of network interfaces
J. Fahrner wrote on 27/12/17 06:04: [snio] eth0 works normal in network-manager. The error is only during boot. I'm wondering why ifup tries to activate eth0, since this is not in /etc/network/interfaces. Where does this info come from, that it should enable eth0? Does it come from udevd? Yes, eudev has code to test the interfaces from 80-ifupdown.rules, which causes /lib/idev/ifupdown-hotplug to run, and that will use ifquery for checking whether the interface concerned has an allow-hotplug in /etc/network/interfaces. I would guess that your machine offers a race between the kernel establishing the interfaces, and the running of ifquery, since the latter can't find the eventually existing eth0. That's the beauty of parallelism in the bootstrap. Assuming the log shows that error systematically, you might test the situation by adding in a "sleep 1" at the top of /lib/udev/ifupdown-hotplug, which should make the error go away. If not, I'm wrong. If you can "confirm" the problem, please lodge a bug report. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] repository clashes
Hello, can someone provide me with proper and full repository list for ascii, including proposed updates, security, updates and backports? I am noticing some strange behavior with packages.devuan.org/devuan and auto.mirror.devuan.org/merged - not all packages available in both repos so I guess I need to have both enabled? For example, some packages are available in the former while rsyslog with its dependecies - only in the latter. So what would be the proper and the complete repository list for ascii, including contrib and non-free packages? -- Regards, Yevgeny ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Request file system reviews and recomendations.
As I understand it, there are a few new file systems somewhat available on Linux -- ZFS, XFS, and Btrfs. But soe are still under development, ZFS is pparently under a prolematic license, and I don't know about XFS. I've onece heard about one of the new systems that one shouldn't bother using it unless one has at least 8 gigabytes of RAM. Now, just how mature are these, how easily managed, how reliable. I'll be populating a new device with a (I hope) high-reliablity file system soon. It doesn't have a lot of RAM, but the RAM does have parity checking. Long-term data preservation is more important than speed. Currently on another system I'm using ext4 over LLVM over software RAID-1. I know RAID isn't a reliable backup system; I make separate off-line backups. What should I be considering for the new system? The same? Are the new systems stale and well enough established in the Linux ecosystem to be candidates? -- hendrik On Fri, Dec 22, 2017 at 04:13:34PM +0100, Jaromil wrote: > On Fri, 22 Dec 2017, Chris Dos wrote: > > > Know nothing about zfs? Well, don't start learning it as you will probably > > not want to use anything else. > > I confirm this :^) real pity for the licensing... but yea, btrfs still > can't cover all functionalities of ZFS, just some. I run a ZRAID since > years and wow. > > cheers > > ___ > 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] Request file system reviews and recomendations.
Quoting Hendrik Boom (hend...@topoi.pooq.com):
> As I understand it, there are a few new file systems somewhat
> available on Linux -- ZFS, XFS, and Btrfs.
>
> But soe are still under development, ZFS is pparently under a
> prolematic license, and I don't know about XFS.
>
> I've onece heard about one of the new systems that one shouldn't
> bother using it unless one has at least 8 gigabytes of RAM.
>
> Now, just how mature are these, how easily managed, how reliable.
>
> I'll be populating a new device with a (I hope) high-reliablity file
> system soon. It doesn't have a lot of RAM, but the RAM does have
> parity checking.
>
> Long-term data preservation is more important than speed.
>
> Currently on another system I'm using ext4 over LLVM over software
> RAID-1. I know RAID isn't a reliable backup system; I make separate
> off-line backups.
Specifically, RAID isn't backup at all. It's redundancy (except for
varieties like RAID0 that aren't even that). See: 'Backup Fallacies /
Pitfalls' on http://linuxmafia.com/kb/Admin/
> What should I be considering for the new system? The same?
You've just asked one of the more inherently debatable questions in all
of Linux system administration.
I can only recommend that you study what the strengths and weaknesses,
advantages and disadvantages, are of the various options at hand, and
then design a system that implements your choices.
For my own home server rebuild, I'm going with ext4, with all
filesystems RAID1-mirrored across a pair of SSDs, and a weekly cron job
applying TRIM. No swap (because SSDs).
XFS is mainline kernel code under GPLv2. It is particularly good for
filesystems with mny very large files, e.g., audio/video. It isn't
quite as fast and massively QAed as ext3/ext4 (though the performance
difference is smaller than it used to be) . XFS is _not_ new. SGI
ported it to Linux in 2000. Like ext3/ext4 and unlike ZFS/btrfs, XFS
lacks checksum protection against silent data corruption.
ZFS is indeed under a GPLv2-incompatible licence[1] (CDDL). It's the one
that requires larger RAM overhead, but has a number of very compelling
features[2] especially for extremely large (multi-terabyte) filesystems.
The driver code is (obviously) not part of the mainline kernel, but
rather runnable either as a large external patchset or as a FUSE
Filesystem in Userspace subsystem. The latter has a performance
penalty. The former... entails running an out-of-tree kernel.
btrfs is still scarily beta after rather a lot of years of development.
Its prospects have dimmed further now that Red Hat have dropped it from
their roadmap.
[1] Canonical, Ltd. have asserted their recent distribution of
binary-compiled ZFS module code for Ubuntu to be lawful. My
interpretation is that they know this is false, that it is clearly
copyright infringement, but have taken a calculated risk that kernel
stakeholders won't sue them, and that the Linux-using public won't
object overly to Canonical lying to them for PR advantage.
[2] Volume manager is integrated into the filesystmem. Snapshots and
replication built in. All storage kept vetted by checksumming and as
necessary corrected. Automated self-healing. Smarter data-striping
('ZRAID') than conventional RAID modes. Native data compression /
deduping (which, however, is RAM-hungry). And a lot more: It's pretty
impressive.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Request file system reviews and recomendations.
On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:
> Quoting Hendrik Boom (hend...@topoi.pooq.com):
>
> > As I understand it, there are a few new file systems somewhat
> > available on Linux -- ZFS, XFS, and Btrfs.
> >
> > But soe are still under development, ZFS is pparently under a
> > prolematic license, and I don't know about XFS.
> >
> > I've onece heard about one of the new systems that one shouldn't
> > bother using it unless one has at least 8 gigabytes of RAM.
> >
> > Now, just how mature are these, how easily managed, how reliable.
> >
> > I'll be populating a new device with a (I hope) high-reliablity file
> > system soon. It doesn't have a lot of RAM, but the RAM does have
> > parity checking.
> >
> > Long-term data preservation is more important than speed.
> >
> > Currently on another system I'm using ext4 over LLVM over software
> > RAID-1. I know RAID isn't a reliable backup system; I make separate
> > off-line backups.
>
> Specifically, RAID isn't backup at all. It's redundancy (except for
> varieties like RAID0 that aren't even that). See: 'Backup Fallacies /
> Pitfalls' on http://linuxmafia.com/kb/Admin/
It's not backup in any normally robust sense of the word. It does
provide a bit of backup against one potential threat -- minor
localized hard drive failures. That's why I also keep separate
off-line backups.
>
> > What should I be considering for the new system? The same?
>
> You've just asked one of the more inherently debatable questions in all
> of Linux system administration.
I know.
>
> I can only recommend that you study what the strengths and weaknesses,
> advantages and disadvantages, are of the various options at hand, and
> then design a system that implements your choices.
>
> For my own home server rebuild, I'm going with ext4, with all
> filesystems RAID1-mirrored across a pair of SSDs, and a weekly cron job
> applying TRIM. No swap (because SSDs).
TRIM because SSDs?
>
> XFS is mainline kernel code under GPLv2. It is particularly good for
> filesystems with mny very large files, e.g., audio/video. It isn't
> quite as fast and massively QAed as ext3/ext4 (though the performance
> difference is smaller than it used to be) . XFS is _not_ new. SGI
> ported it to Linux in 2000. Like ext3/ext4 and unlike ZFS/btrfs, XFS
> lacks checksum protection against silent data corruption.
I like the checksum protection of ZFS and btrfs. If I could get it
with ext4 I'd be happy.
> ZFS is indeed under a GPLv2-incompatible licence[1] (CDDL). It's the one
> that requires larger RAM overhead, but has a number of very compelling
> features[2] especially for extremely large (multi-terabyte) filesystems.
> The driver code is (obviously) not part of the mainline kernel, but
> rather runnable either as a large external patchset or as a FUSE
> Filesystem in Userspace subsystem. The latter has a performance
> penalty. The former... entails running an out-of-tree kernel.
I'll have about half a gig of RAM. Does this rule out ZFS or just
make it moderately slower? I'm not going to be running millions of
transactions a day on my home server.
>
> btrfs is still scarily beta after rather a lot of years of development.
> Its prospects have dimmed further now that Red Hat have dropped it from
> their roadmap.
Scarily beta, yes. I'd consider it if it ever stops being scarily
beta.
>
>
> [1] Canonical, Ltd. have asserted their recent distribution of
> binary-compiled ZFS module code for Ubuntu to be lawful. My
> interpretation is that they know this is false, that it is clearly
> copyright infringement, but have taken a calculated risk that kernel
> stakeholders won't sue them, and that the Linux-using public won't
> object overly to Canonical lying to them for PR advantage.
>
> [2] Volume manager is integrated into the filesystmem. Snapshots and
> replication built in. All storage kept vetted by checksumming and as
> necessary corrected. Automated self-healing. Smarter data-striping
> ('ZRAID') than conventional RAID modes. Native data compression /
> deduping (which, however, is RAM-hungry). And a lot more: It's pretty
> impressive.
> ___
> 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] Request file system reviews and recomendations.
Quoting Hendrik Boom (hend...@topoi.pooq.com): [RAID1:] > It's not backup in any normally robust sense of the word. It does > provide a bit of backup against one potential threat -- minor > localized hard drive failures. Which is properly called rendundancy, in contrast to backup. (You might continue to choose to differ, in which case we agree to disagree, please.) > That's why I also keep separate off-line backups. Which is properly called backup. ;-> > TRIM because SSDs? That's what TRIM (capitalised not as an acronym but rather because it's a style convention for the names of ATA commands) applies to. Your question lacks context and clarity as stated, so I don't know whether you're saying you are fundamentally unfamiliar with the issue. You might be saying that. If you are: https://en.wikipedia.org/wiki/Trim_(computing) https://wiki.debian.org/SSDOptimization https://wiki.archlinux.org/index.php/Solid_State_Drives https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4519 Also covers block alignment and other issues raised by SSD. > I like the checksum protection of ZFS and btrfs. If I could get it > with ext4 I'd be happy. Don't hold you breath waiting. ;-> > I'll have about half a gig of RAM. Does this rule out ZFS or just > make it moderately slower? I'm not going to be running millions of > transactions a day on my home server. I'm pretty sure it totally rules out ZFS. The usual RAM suggestions start at 8GB, and go upwards from there. It's possible to have a crawling^W running system with less (like, as low as 1GB), but you wouldn't like it. [btrfs:] > Scarily beta, yes. I'd consider it if it ever stops being scarily > beta. Don't hold you breath waiting. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Request file system reviews and recomendations.
On 12/26/17 6:22 PM, Hendrik Boom wrote: > On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote: >> Quoting Hendrik Boom (hend...@topoi.pooq.com): >> [ DELETED ] > > I'll have about half a gig of RAM. Does this rule out ZFS or just > make it moderately slower? I'm not going to be running millions of > transactions a day on my home server. I am a long time user of ZFS on FreeBSD, Ubuntu, and Debian. This is my opinion. My opinion and $5.00 will get you a Happy Meal. A good place to start is ZFS On Linux (http://zfsonlinux.org/) This project is being run by the bright boys and girls at Lawrence Livermore National Lab, our tax dollars at work. Yes, it is covered by a GPLv2-incompatible licence[1] (CDDL), but I consider the advantages of ZFS enough to ignore the license issue. I mostly run Debian and ZFS works like a charm. The minimum amount of RAM you need to run ZFS is 8 gb BUT you will not be happy. Realistically you should have a minimum of 16 gb. My ZFS at home has 64 gb and is quite happy. Also you must be running a 64 bit OS. Another point to keep in mind is that with RaidZ1 (RAID5) or RaidZ2 (RAID6) should never get above 80% usage. [ DELETED ] Josef -- Josef Grosch | Another day closer | jgro...@gmail.com | to Redwood Heaven | Berkeley, Ca. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev naming of network interfaces
Am 2017-12-26 23:56, schrieb Ralph Ronnquist: Yes, eudev has code to test the interfaces from 80-ifupdown.rules, which causes /lib/idev/ifupdown-hotplug to run, and that will use ifquery for checking whether the interface concerned has an allow-hotplug in /etc/network/interfaces. Thanks for that explanation. And sorry, the problem is away after removing eth0 from /etc/network/interfaces. It was my fault that I did not realize that. I only saw a red message appearing on boot screen, and I didn't realize that bootlogd appends to /var/log/boot instead of writing a new log on each boot. So I didn't realize that I was looking at old messages ;-) The remaining red message comes from another problem. See my next post. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] udev-finish: No such file or directory
Hi, after upgrading to Ascii I have the following failure on boot. Any ideas what's causing this? Wed Dec 27 07:24:25 2017: [info] Loading kernel module lp. Wed Dec 27 07:24:25 2017: [info] Loading kernel module ppdev. Wed Dec 27 07:24:25 2017: [info] Loading kernel module parport_pc. Wed Dec 27 07:24:25 2017: [ ok ] Cleaning up temporary files... /tmp. Wed Dec 27 07:24:25 2017: [ ok ] Mounting local filesystems...done. Wed Dec 27 07:24:25 2017: [ ok ] Activating swapfile swap...done. Wed Dec 27 07:24:25 2017: [ ok ] Cleaning up temporary files Wed Dec 27 07:24:25 2017: udev-finish: No such file or directory Wed Dec 27 07:24:25 2017: [ ok ] Setting kernel variables...done. Wed Dec 27 07:24:25 2017: [ ok ] Configuring network interfaces...done. Wed Dec 27 07:24:25 2017: [ ok ] Cleaning up temporary files Wed Dec 27 07:24:25 2017: [ ok ] Setting up ALSA...done. Wed Dec 27 07:24:25 2017: [ ok ] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix. Wed Dec 27 07:24:25 2017: [FAIL] startpar: service(s) returned failure: udev udev-finish ... failed! Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] udev-finish: No such file or directory
J. Fahrner wrote on 27/12/17 17:41: Hi, after upgrading to Ascii I have the following failure on boot. Any ideas what's causing this? Wed Dec 27 07:24:25 2017: [info] Loading kernel module lp. Wed Dec 27 07:24:25 2017: [info] Loading kernel module ppdev. Wed Dec 27 07:24:25 2017: [info] Loading kernel module parport_pc. Wed Dec 27 07:24:25 2017: [ ok ] Cleaning up temporary files... /tmp. Wed Dec 27 07:24:25 2017: [ ok ] Mounting local filesystems...done. Wed Dec 27 07:24:25 2017: [ ok ] Activating swapfile swap...done. Wed Dec 27 07:24:25 2017: [ ok ] Cleaning up temporary files Wed Dec 27 07:24:25 2017: udev-finish: No such file or directory Wed Dec 27 07:24:25 2017: [ ok ] Setting kernel variables...done. Wed Dec 27 07:24:25 2017: [ ok ] Configuring network interfaces...done. Wed Dec 27 07:24:25 2017: [ ok ] Cleaning up temporary files Wed Dec 27 07:24:25 2017: [ ok ] Setting up ALSA...done. Wed Dec 27 07:24:25 2017: [ ok ] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix. Wed Dec 27 07:24:25 2017: [FAIL] startpar: service(s) returned failure: udev udev-finish ... failed! Probably you have the dangling link /etc/rcS.d/S11udev-finish (or similar), which would be a remnant from the udev package, and it should have been removed when udev was removed. Possibly there is also a dangling /etc/rcS.d/S02udev. It's unclear to me why it gets left, but I had them too. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] udev-finish: No such file or directory
Am 2017-12-27 07:57, schrieb Ralph Ronnquist: Probably you have the dangling link /etc/rcS.d/S11udev-finish (or similar), which would be a remnant from the udev package, and it should have been removed when udev was removed. Possibly there is also a dangling /etc/rcS.d/S02udev. It's unclear to me why it gets left, but I had them too. Thank you very much! That solved it! Now my bootlog is clean :-) Strange: that only happend on 1 of my 3 upgraded systems. Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
