[arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.2-1, net-tools-1.60-15, udev-171-2, yp-tools-2.12-2
Hi guys, After the discussion regarding initscripts-2011.06.1 we decided that things would be simpler if we move all the above packages in one go (thanks to Gaetan and Thomas for the help!), so please test and sign off. Below is a summary of changes, I will write a nicer summary for the front page before moving to core. ---- udev ---- As mentioned in several previous emails, we have been working to remove modules-load.sh from udev. This should simplify the package significantly (so it should be easier to submit bugs upstream and we will benefit more easily from any fixes and improvements they do), at least on my machine I also notice a small but significant speedup in boot time (2,5 sec, or about 10%). In this release of udev, modules-load.sh is finally removed. This means that our custom blacklisting of modules no longer works, but this should not be a problem as modprobe has native support for blacklisting. For details see 'man modprobe.conf'. Furthermore, as of the latest modules-init-tools release you can blacklist modules on the kernel command line by using the following syntax: "modprobe.blacklist=mod1,mod2,mod3". Alternatively modules can be disabled by using the syntax "mod1.disable=1". ---- net-tools ---- It is now more than a decade since the last net-tools release, so we no longer want to rely on this package. With these changes it is not installed by default any longer, but can be used by those who prefer to keep the old behavior. In order to do this we did three things: 1) initscripts now defaluts to using iproute2 2) hostname is now provided by coreutils 3) nisdomainname is now provided by yp-tools ---- Initscripts: ---- Big changes: 1) We gain support for iproute2, and net-tools is now optional (thanks to Dave Reisner). If you don't update your rc.conf, everything should work as before (using net-tools), pleas shout if it does not. 2) MOD_AUTOLOAD no longer has any effect (modules are always autoloaded). 3) blacklisting modules in the MODULES array is no longer supported, use modprobe's native blacklisting instead (see 'man modprobe.conf'). An announcement will be made about this before moving to core. 4) We no set domainname at boot. Supporting this was complicated by the move of the binary to yp-tools, and is done in the ypbind rc script instead. Otherwise there are some bugfixes, and quite a bit of improvements made to rc.d. Thanks to all who contributed: Clément Démoulins (1): Add a zsh completion script for the command rc.d. Dave Reisner (3): network/rc.sysinit: remove dead code network: deprecate net-tools, add iproute2 support rc.d: declare ENV as an array Eric Bélanger (1): rc.d: Add error message when daemon script is not found Gerardo Exequiel Pozzi (2): use mount -n for devpts and shm add killall5 omit pid functionality Sebastien Luttringer (8): Add syntax to vim modeline in rc.d script Add TERM var to rc.d cleaned env Improve coloring on light and transparent term Add rc.d bash completion rc.d bash completion detect running daemon rc.d zsh completion detect running daemons rc.d: Remove cd from the loop rc.d: print usage if not enough argument Thomas Bächler (1): Fix typo Tom Gundersen (13): releasing: update instructinos after going through it once makefile: do not make functions executable udev: generate blacklist on boot fixup: also clear /tmp if it is a mountpoint Merge remote-tracking branch 'seblu/master' Revert "udev: generate blacklist on boot" depraction: MOD_AUTOLOAD and MODULES blacklisting net: add examples Merge branch 'snowman' agetty: keep baud rate from kernel if possible fixup: stat_busy/stat_done -> status fixup: network: deprecate net-tools nisdomainname: remove support
On 2 June 2011 18:28, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
After the discussion regarding initscripts-2011.06.1 we decided that things would be simpler if we move all the above packages in one go (thanks to Gaetan and Thomas for the help!), so please test and sign off.
The net-tools package in [testing] still ships the man page for hostname(1), which also exists in the coreutils package (also in [testing]): Targets (4): coreutils-8.12-2 udev-171-2 initscripts-2011.06.2-1 net-tools-1.60-15 Total Download Size: 0.00 MB Total Installed Size: 15.27 MB Proceed with installation? [Y/n] (4/4) checking package integrity [######################] 100% (4/4) checking for file conflicts [######################] 100% error: failed to commit transaction (conflicting files) /usr/share/man/man1/hostname.1.gz exists in both 'coreutils' and 'net-tools'
[2011-06-02 19:16:29 +0300] Evangelos Foutras:
The net-tools package in [testing] still ships the man page for hostname(1), which also exists in the coreutils package (also in [testing]):
My bad. I'll upload a new version soon. -- Gaetan
[2011-06-02 18:26:39 +0200] Gaetan Bisson:
[2011-06-02 19:16:29 +0300] Evangelos Foutras:
The net-tools package in [testing] still ships the man page for hostname(1), which also exists in the coreutils package (also in [testing]):
My bad. I'll upload a new version soon.
Done. -- Gaetan
On 2 June 2011 09:52, Gaetan Bisson <bisson@archlinux.org> wrote:
[2011-06-02 18:26:39 +0200] Gaetan Bisson:
[2011-06-02 19:16:29 +0300] Evangelos Foutras:
The net-tools package in [testing] still ships the man page for hostname(1), which also exists in the coreutils package (also in [testing]):
My bad. I'll upload a new version soon.
Done.
Signoff x86_64.
Complete the load-modules.sh removal. Module blacklisting/disabling now only works with the methods Tom described for the initscripts changes. load_modules=off is no longer supported. Please sign off. Dan McGee (1): Don't print success/failure result on same line Thomas Bächler (3): mkinitcpio.conf: Fix modprobe.conf location in the FILES= example Remove load-modules.sh. Requires the udev 171-2 package. Release version 0.6.13
On 2 June 2011 10:57, Thomas Bächler <thomas@archlinux.org> wrote:
Complete the load-modules.sh removal. Module blacklisting/disabling now only works with the methods Tom described for the initscripts changes. load_modules=off is no longer supported.
Please sign off.
Signoff x86_64.
On Thu, Jun 2, 2011 at 7:57 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Complete the load-modules.sh removal. Module blacklisting/disabling now only works with the methods Tom described for the initscripts changes. load_modules=off is no longer supported.
Please sign off.
Dan McGee (1): Don't print success/failure result on same line
Thomas Bächler (3): mkinitcpio.conf: Fix modprobe.conf location in the FILES= example Remove load-modules.sh. Requires the udev 171-2 package. Release version 0.6.13
Signoff x86_64
On 03/06/11 10:15, Tom Gundersen wrote:
On Thu, Jun 2, 2011 at 7:57 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Complete the load-modules.sh removal. Module blacklisting/disabling now only works with the methods Tom described for the initscripts changes. load_modules=off is no longer supported.
Please sign off.
Dan McGee (1): Don't print success/failure result on same line
Thomas Bächler (3): mkinitcpio.conf: Fix modprobe.conf location in the FILES= example Remove load-modules.sh. Requires the udev 171-2 package. Release version 0.6.13
Signoff x86_64
Signoff i686, Allan
Am 02.06.2011 19:57, schrieb Thomas Bächler:
Complete the load-modules.sh removal. Module blacklisting/disabling now only works with the methods Tom described for the initscripts changes. load_modules=off is no longer supported.
Please sign off.
Dan McGee (1): Don't print success/failure result on same line
Thomas Bächler (3): mkinitcpio.conf: Fix modprobe.conf location in the FILES= example Remove load-modules.sh. Requires the udev 171-2 package. Release version 0.6.13
This is incomplete as Dave noticed: disablemodules= still works for the MODULES= stuff from mkinitcpio.conf - this should be removed.
On 03/06/11 01:28, Tom Gundersen wrote:
Hi guys,
After the discussion regarding initscripts-2011.06.1 we decided that things would be simpler if we move all the above packages in one go (thanks to Gaetan and Thomas for the help!), so please test and sign off.
Below is a summary of changes, I will write a nicer summary for the front page before moving to core.
<snip> Signoff i686, Allan
On Thu, Jun 2, 2011 at 11:28 AM, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
After the discussion regarding initscripts-2011.06.1 we decided that things would be simpler if we move all the above packages in one go (thanks to Gaetan and Thomas for the help!), so please test and sign off.
The error messages I mentionned in an earlier signoff thread are back: http://mailman.archlinux.org/pipermail/arch-dev-public/2011-May/020434.html I was also getting them with the previous versions of these packages in testing/core. I'll reboot with udev_log set to debug. Maybe that will give us more info.
On Thu, Jun 2, 2011 at 10:53 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Thu, Jun 2, 2011 at 11:28 AM, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
After the discussion regarding initscripts-2011.06.1 we decided that things would be simpler if we move all the above packages in one go (thanks to Gaetan and Thomas for the help!), so please test and sign off.
The error messages I mentionned in an earlier signoff thread are back: http://mailman.archlinux.org/pipermail/arch-dev-public/2011-May/020434.html
I was also getting them with the previous versions of these packages in testing/core.
I'll reboot with udev_log set to debug. Maybe that will give us more info.
That won't help unless there's a way to save it. The text scroll so fast that I can't read it. I booted the LTS kernel and I got the same message. Also, my loopback interface didn't started. When I ran "/usr/sbin/ip link set up dev lo" manually in a terminal, it started fine. I don't know why it didn't work when booting up.
On Fri, Jun 3, 2011 at 7:17 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Thu, Jun 2, 2011 at 10:53 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Thu, Jun 2, 2011 at 11:28 AM, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
After the discussion regarding initscripts-2011.06.1 we decided that things would be simpler if we move all the above packages in one go (thanks to Gaetan and Thomas for the help!), so please test and sign off.
The error messages I mentionned in an earlier signoff thread are back: http://mailman.archlinux.org/pipermail/arch-dev-public/2011-May/020434.html
What happens when you try to execute the commands in question manually after boot?
I'll reboot with udev_log set to debug. Maybe that will give us more info.
That won't help unless there's a way to save it. The text scroll so fast that I can't read it. I booted the LTS kernel and I got the same message.
debug is probably too much information, try warning first. The messages should be in "dmesg", /var/log/boot or /var/log/everythnig.
Also, my loopback interface didn't started. When I ran "/usr/sbin/ip link set up dev lo" manually in a terminal, it started fine. I don't know why it didn't work when booting up.
Do you see anything in the above logs? Thanks for reporting, Tom
On Fri, Jun 3, 2011 at 7:37 AM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Jun 3, 2011 at 7:17 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Thu, Jun 2, 2011 at 10:53 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Thu, Jun 2, 2011 at 11:28 AM, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
After the discussion regarding initscripts-2011.06.1 we decided that things would be simpler if we move all the above packages in one go (thanks to Gaetan and Thomas for the help!), so please test and sign off.
The error messages I mentionned in an earlier signoff thread are back: http://mailman.archlinux.org/pipermail/arch-dev-public/2011-May/020434.html
What happens when you try to execute the commands in question manually after boot?
They work as expected. The error is not fatal. My raid array gets assembled without user intervention. Either it is eventually done by the initscripts (I can't find where, I think that code parthas been removed) or by something else.
I'll reboot with udev_log set to debug. Maybe that will give us more info.
That won't help unless there's a way to save it. The text scroll so fast that I can't read it. I booted the LTS kernel and I got the same message.
debug is probably too much information, try warning first. The messages should be in "dmesg", /var/log/boot or /var/log/everythnig.
FWIW, the instructive comments in udev.conf doesn't mention "warning" as a valid value. I tried it and the error message doesn't get printed. Dmesg doesn't have the error message and the logs are useless since the error happens when the kernel is booting, i.e. rc.sysinit isn't running yet. I suppose it's mkinitcpio/udev related.
Also, my loopback interface didn't started. When I ran "/usr/sbin/ip link set up dev lo" manually in a terminal, it started fine. I don't know why it didn't work when booting up.
Do you see anything in the above logs?
I found the source of this error. My /usr is on it's own partition. So when rc.sysinit attemps to setup the loopback interface with /usr/sbin/ip, my /usr partition is not mounted yet. So it fails. I don't know what would be the best way to fix. Maybe moving ip to /sbin or to postpone the lo interface setup after the partitions are mounted. OT: I noticed that the /var/log/boot is somewhat hard to read because of the presence of the ansi escape sequences for the colored output. Would it be a good idea (or even possible) to removed these perhaps with a sed line after bootlogd has finished its stuff?
Thanks for reporting,
Tom
Am 04.06.2011 05:41, schrieb Eric Bélanger:
OT: I noticed that the /var/log/boot is somewhat hard to read because of the presence of the ansi escape sequences for the colored output. Would it be a good idea (or even possible) to removed these perhaps with a sed line after bootlogd has finished its stuff?
You can 'sed' them out (you need to replace the '^[' with a proper escape character). But there are other problems, some lines are truncated.
On Sat, Jun 4, 2011 at 9:23 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 04.06.2011 05:41, schrieb Eric Bélanger:
OT: I noticed that the /var/log/boot is somewhat hard to read because of the presence of the ansi escape sequences for the colored output. Would it be a good idea (or even possible) to removed these perhaps with a sed line after bootlogd has finished its stuff?
You can 'sed' them out (you need to replace the '^[' with a proper escape character). But there are other problems, some lines are truncated.
A patch implementing a sensible heuristic for what to do with this would be very welcome. -t
Am 04.06.2011 10:41, schrieb Tom Gundersen:
You can 'sed' them out (you need to replace the '^[' with a proper escape character). But there are other problems, some lines are truncated.
A patch implementing a sensible heuristic for what to do with this would be very welcome.
I can't find the sed line in my history anymore. However, the truncation problem is already present in the source file.
On Sat, Jun 4, 2011 at 10:56 AM, Thomas Bächler <thomas@archlinux.org> wrote:
However, the truncation problem is already present in the source file.
Ah, I read your message too quickly. I don't think we can do much about this (except sending patches upstream), as there is no way to configure the output from bootlog. -t
On Sat, Jun 4, 2011 at 4:41 AM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 4, 2011 at 9:23 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 04.06.2011 05:41, schrieb Eric Bélanger:
OT: I noticed that the /var/log/boot is somewhat hard to read because of the presence of the ansi escape sequences for the colored output. Would it be a good idea (or even possible) to removed these perhaps with a sed line after bootlogd has finished its stuff?
You can 'sed' them out (you need to replace the '^[' with a proper escape character). But there are other problems, some lines are truncated.
A patch implementing a sensible heuristic for what to do with this would be very welcome.
-t
I don't see any truncated lines in /var/log/boot. Either it's system dependent or I don't look at the right place. Anyway I'll look into a patch for the ansi code. Even if we can't make the output format as we would wish, cleaning it up wouldn't hurt.
On Sat, Jun 4, 2011 at 6:02 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
I don't see any truncated lines in /var/log/boot. Either it's system dependent or I don't look at the right place. Anyway I'll look into a patch for the ansi code. Even if we can't make the output format as we would wish, cleaning it up wouldn't hurt.
It would be nice to be able to use "less -r" to view the file... -t
On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
FWIW, the instructive comments in udev.conf doesn't mention "warning" as a valid value.
Oops, I meant to say "info".
I tried it and the error message doesn't get printed. Dmesg doesn't have the error message and the logs are useless since the error happens when the kernel is booting, i.e. rc.sysinit isn't running yet. I suppose it's mkinitcpio/udev related.
If rc.sysinit is not running, then this is an mkinitcpio problem. I guess the reason you are seeing it again might be a race? We have sped things up quite a bit with this release, so things might race differently than before.
They work as expected. The error is not fatal. My raid array gets assembled without user intervention. Either it is eventually done by the initscripts (I can't find where, I think that code parthas been removed) or by something else.
My guess is that the error you are seeing is from udev in mkinitcpio, and the udev in rc.sysinit works correctly. To change the error reporting you would need to run mkinitcpio -p kernel26 after updating udev.conf.
Also, my loopback interface didn't started. When I ran "/usr/sbin/ip link set up dev lo" manually in a terminal, it started fine. I don't know why it didn't work when booting up.
Do you see anything in the above logs?
I found the source of this error. My /usr is on it's own partition. So when rc.sysinit attemps to setup the loopback interface with /usr/sbin/ip, my /usr partition is not mounted yet. So it fails. I don't know what would be the best way to fix. Maybe moving ip to /sbin or to postpone the lo interface setup after the partitions are mounted.
Ahhhh. I think this might cause many more problems than just the loopback. In particular, anything called in udev rules may reside on /usr. This means the rule will fail and it will not be rerun. Have a look at "grep /usr /lib/udev/rules.d/*" to see examples of what might be broken. Most other distros, and upstream projects have given up on supporting a separate /usr, so it will be buggy. I suggest moving your /usr to your rootfs, regardless of this particular problem. As to the loopback device. I don't think it is a good idea to delay this to after /usr is mounted. If anything we might want to move it earlier in boot. That leaves moving ip out of /usr. Does anyone know the consequences of this? Do we want to keep supporting a separate /usr? Cheers, Tom
On Sat, Jun 4, 2011 at 4:58 AM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
FWIW, the instructive comments in udev.conf doesn't mention "warning" as a valid value.
Oops, I meant to say "info".
I also tried info when I tried with debug. I didn't noticed any difference with debug as far as the excessive output go. I could try it again and check dmesg more carefully.
I tried it and the error message doesn't get printed. Dmesg doesn't have the error message and the logs are useless since the error happens when the kernel is booting, i.e. rc.sysinit isn't running yet. I suppose it's mkinitcpio/udev related.
If rc.sysinit is not running, then this is an mkinitcpio problem. I guess the reason you are seeing it again might be a race? We have sped things up quite a bit with this release, so things might race differently than before.
That's what I believe. I didn't mentionned it but dmesg contains output saying that the raid was assemble and all mirrors are active. So despite the error message from udevd, the kernel still manage to assemble the raid array. Also, I can't find the hook or config file that contains the mdadm command line displayed in the error message. I looked in /etc and /lib/initcpio but it's not there.
They work as expected. The error is not fatal. My raid array gets assembled without user intervention. Either it is eventually done by the initscripts (I can't find where, I think that code parthas been removed) or by something else.
My guess is that the error you are seeing is from udev in mkinitcpio, and the udev in rc.sysinit works correctly. To change the error reporting you would need to run mkinitcpio -p kernel26 after updating udev.conf.
I was updating my initcpio file when changing the udev.conf.
Also, my loopback interface didn't started. When I ran "/usr/sbin/ip link set up dev lo" manually in a terminal, it started fine. I don't know why it didn't work when booting up.
Do you see anything in the above logs?
I found the source of this error. My /usr is on it's own partition. So when rc.sysinit attemps to setup the loopback interface with /usr/sbin/ip, my /usr partition is not mounted yet. So it fails. I don't know what would be the best way to fix. Maybe moving ip to /sbin or to postpone the lo interface setup after the partitions are mounted.
Ahhhh. I think this might cause many more problems than just the loopback. In particular, anything called in udev rules may reside on /usr. This means the rule will fail and it will not be rerun.
Have a look at "grep /usr /lib/udev/rules.d/*" to see examples of what might be broken.
Most other distros, and upstream projects have given up on supporting a separate /usr, so it will be buggy. I suggest moving your /usr to your rootfs, regardless of this particular problem.
I recall you mentionning that on another ML thread. I wanted to ask you for details at the time but did get to. I'll move my /usr to my rootfs. I use lvm2 so the resizing/repartionning should be easy.
As to the loopback device. I don't think it is a good idea to delay this to after /usr is mounted. If anything we might want to move it earlier in boot. That leaves moving ip out of /usr.
Does anyone know the consequences of this? Do we want to keep supporting a separate /usr?
If I'm the only one with the problem, you can also keep things as they are now, i.e. not support /usr on a separate partition. As I'll be moving my /usr, that problem will become moot. Eric
Cheers,
Tom
On Sat, Jun 4, 2011 at 6:30 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
That's what I believe. I didn't mentionned it but dmesg contains output saying that the raid was assemble and all mirrors are active. So despite the error message from udevd, the kernel still manage to assemble the raid array. Also, I can't find the hook or config file that contains the mdadm command line displayed in the error message. I looked in /etc and /lib/initcpio but it's not there.
It is called from udev (both in the initramfs, which fails, and in the real fs, which succeeds). The rule is /lib/udev/rules.d/64-md-raid.rules. Could it be that your initramfs lacks some modules? I guess Thomas would know this better than me...
If I'm the only one with the problem, you can also keep things as they are now, i.e. not support /usr on a separate partition. As I'll be moving my /usr, that problem will become moot.
There probably will be more affected people once it reaches [core], so we should either decide not to support separate /usr, or fix it. -t
On Sat, Jun 4, 2011 at 12:45 PM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 4, 2011 at 6:30 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
That's what I believe. I didn't mentionned it but dmesg contains output saying that the raid was assemble and all mirrors are active. So despite the error message from udevd, the kernel still manage to assemble the raid array. Also, I can't find the hook or config file that contains the mdadm command line displayed in the error message. I looked in /etc and /lib/initcpio but it's not there.
It is called from udev (both in the initramfs, which fails, and in the real fs, which succeeds). The rule is /lib/udev/rules.d/64-md-raid.rules. Could it be that your initramfs lacks some modules? I guess Thomas would know this better than me...
I could try my fallback initcpio. I don't remember if I tried that. My /etc/mkinitcpio.conf has: MODULES="pata_amd ata_generic sata_nv sata_sil24 floppy dm-mod raid1 raid456" HOOKS="base udev autodetect pata scsi sata usbinput keymap mdadm lvm2 filesystems" md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda2,/dev/sdb2
If I'm the only one with the problem, you can also keep things as they are now, i.e. not support /usr on a separate partition. As I'll be moving my /usr, that problem will become moot.
There probably will be more affected people once it reaches [core], so we should either decide not to support separate /usr, or fix it.
-t
On Sat, Jun 4, 2011 at 1:12 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sat, Jun 4, 2011 at 12:45 PM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 4, 2011 at 6:30 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
That's what I believe. I didn't mentionned it but dmesg contains output saying that the raid was assemble and all mirrors are active. So despite the error message from udevd, the kernel still manage to assemble the raid array. Also, I can't find the hook or config file that contains the mdadm command line displayed in the error message. I looked in /etc and /lib/initcpio but it's not there.
It is called from udev (both in the initramfs, which fails, and in the real fs, which succeeds). The rule is /lib/udev/rules.d/64-md-raid.rules. Could it be that your initramfs lacks some modules? I guess Thomas would know this better than me...
I could try my fallback initcpio. I don't remember if I tried that.
My /etc/mkinitcpio.conf has: MODULES="pata_amd ata_generic sata_nv sata_sil24 floppy dm-mod raid1 raid456"
HOOKS="base udev autodetect pata scsi sata usbinput keymap mdadm lvm2 filesystems" md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda2,/dev/sdb2
Same problem with fallback image. Using the info log level doesn't help at all. It scrolls too fast to read and it's not recorded anywhere. dmesg only contains a message that udevd has started, I guess it's because the output is produced by udevd and not the kernel. The logs are useless because the loggers are not running yet. I think I'll just ignore the message for now.
If I'm the only one with the problem, you can also keep things as they are now, i.e. not support /usr on a separate partition. As I'll be moving my /usr, that problem will become moot.
There probably will be more affected people once it reaches [core], so we should either decide not to support separate /usr, or fix it.
-t
On Tue, Jun 7, 2011 at 11:28 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Same problem with fallback image. Using the info log level doesn't help at all. It scrolls too fast to read and it's not recorded anywhere. dmesg only contains a message that udevd has started, I guess it's because the output is produced by udevd and not the kernel. The logs are useless because the loggers are not running yet. I think I'll just ignore the message for now.
cc'ing arch-projects: Maybe we should add bootlogd (orsomething similar) to mkinitcpio and keep those logs in /run so that these kind of issues can be debugged more easily? -t
On Tue, Jun 7, 2011 at 4:41 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Jun 7, 2011 at 11:28 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Same problem with fallback image. Using the info log level doesn't help at all. It scrolls too fast to read and it's not recorded anywhere. dmesg only contains a message that udevd has started, I guess it's because the output is produced by udevd and not the kernel. The logs are useless because the loggers are not running yet. I think I'll just ignore the message for now.
cc'ing arch-projects:
Maybe we should add bootlogd (orsomething similar) to mkinitcpio and keep those logs in /run so that these kind of issues can be debugged more easily?
Isn't this what minilogd [1] was intended for? -Dan [1] http://projects.archlinux.org/initscripts.git/tree/minilogd.c
On Tue, Jun 7, 2011 at 11:45 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Isn't this what minilogd [1] was intended for?
Hmmm... it would be neat if we can make that work. However, I'm not sure it would. If I understand correctly, minilogd will buffer all messages to /dev/log until syslog-ng is started, and then minilogd will push it's log into the normal syslog. However, if we have a minilogd instance in initramfs I guess we would have to kill it before starting init, so it will not be able to pass on its messages. Or am I wrong? I really don't know the details of how this is supposed to work. Cheers, Tom
On Tue, Jun 7, 2011 at 5:41 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Jun 7, 2011 at 11:28 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Same problem with fallback image. Using the info log level doesn't help at all. It scrolls too fast to read and it's not recorded anywhere. dmesg only contains a message that udevd has started, I guess it's because the output is produced by udevd and not the kernel. The logs are useless because the loggers are not running yet. I think I'll just ignore the message for now.
cc'ing arch-projects:
Maybe we should add bootlogd (orsomething similar) to mkinitcpio and keep those logs in /run so that these kind of issues can be debugged more easily?
-t
Isn't the filesystems ro at that point in time?
On Tue, Jun 7, 2011 at 11:50 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Isn't the filesystems ro at that point in time?
That's the beauty of /run, it is rw from initramfs until shutdown ;-) -t
On Tue, Jun 7, 2011 at 5:52 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Jun 7, 2011 at 11:50 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Isn't the filesystems ro at that point in time?
That's the beauty of /run, it is rw from initramfs until shutdown ;-)
-t
I tried adding "> /run/boot.log 2>&1" at the end of the udevd line in /lib/initcpio/init but it didn't work. It was still showing the output and the logfile was empty. I also tried Thomas suggestion in IRC: Snowman: can you try to comment out #SCRIPT="mdadm" in /lib/initcpio/install/mdadm That made the system unbootable. It was dropping me in the busybox recovery shell.
On Fri, Jun 3, 2011 at 7:17 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Also, my loopback interface didn't started. When I ran "/usr/sbin/ip link set up dev lo" manually in a terminal, it started fine. I don't know why it didn't work when booting up.
I'm not able to reproduce this... Anyone else? -t
participants (7)
-
Allan McRae
-
Dan McGee
-
Eric Bélanger
-
Evangelos Foutras
-
Gaetan Bisson
-
Thomas Bächler
-
Tom Gundersen