[SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

ejmarkow · 2011-03-30 15:47:53

Kernel 2.6.39-rc1 Compilation on Arch Linux Summary:

System Info:

uname -a:  Linux Galicja 2.6.39-rc1-ARCHMOD #1 PREEMPT Wed Mar 30 14:03:36 CEST 2011 x86_64 Genuine Intel(R) CPU 575 @ 2.00GHz GenuineIntel GNU/Linux

Issues:

1) During kernel compilation using 'mkiniticpio' (mkinitcpio -k 2.6.39-rc1-ARCHMOD -g /boot/kernel26-2.6.39-rc1-ARCHMOD.img) to create the initial RAM disk, had the following output with errors (note, the RAM disk still worked):

-----
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [autodetect]
ERROR: Root file system type detection failed.
:: Parsing hook [pata]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [filesystems]
:: Generating module dependencies
:: Generating image '/boot/kernel26-2.6.39-rc1-ARCHMOD.img'...SUCCESS
-----

2) The end of my 'dmesg' output now contains 're-mounted' file system messages (this was not present in the previous stable .38 kernel):

-----
.
.
ip_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
asix 2-5:1.0: eth1: link up, 10Mbps, half-duplex, lpa 0x0000
asix 2-5:1.0: eth1: link up, 10Mbps, half-duplex, lpa 0x0000
r8169 0000:01:00.0: eth0: link down
r8169 0000:01:00.0: eth0: link down
r8169 0000:01:00.0: eth0: link up
NET: Registered protocol family 10
eth1: no IPv6 routers present
eth0: no IPv6 routers present
EXT4-fs (sda5): re-mounted. Opts: commit=0
EXT4-fs (sda8): re-mounted. Opts: commit=0
EXT4-fs (sda2): re-mounted. Opts: commit=0
EXT4-fs (sda9): re-mounted. Opts: commit=0
EXT4-fs (sda6): re-mounted. Opts: commit=0
EXT4-fs (sda7): re-mounted. Opts: commit=0
process `skype' is using obsolete setsockopt SO_BSDCOMPAT
-----

3) When shutting down Arch Linux, the 'Avahi-Daemon' process 'fails' to stop (it started up correctly at boot):

-----
:: Stopping Avahi mDNS/DNS-SD Daemon          [FAIL]
-----

Regardless of some of these issues, this kernel is functional so far.

Last edited by ejmarkow (2011-04-13 07:34:09)

fr33ke · 2011-03-30 17:41:37

No such problems here.

Linux archmini 2.6.39-rc1-victor #53 SMP PREEMPT Wed Mar 30 18:14:16 CEST 2011 x86_64 Intel(R) Atom(TM) CPU N450 @ 1.66GHz GenuineIntel GNU/Linux

mkiniticpio and acpid are working just fine, and I don't think it's remounting more than usual

[root@archmini user]# dmesg | grep -i mounted
[    2.327916] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
[    8.565998] EXT4-fs (sda3): re-mounted. Opts: (null)
[    8.811949] EXT4-fs (sda3): re-mounted. Opts: (null)
[    9.229862] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
[   17.045300] EXT4-fs (sda4): re-mounted. Opts: commit=600

sda3 is / and sda4 is /home. The last remount is probably because of laptop-mode-tools.

My config is kind of an allmodconfig (with the build fix at https://lkml.org/lkml/2011/3/29/485 ), with a slightly modified PKGBUILD from Kernel Compilation from Source on the archwiki.

ejmarkow · 2011-03-31 12:28:27

@fr33ke:

I have two corrections:

1) By enabling the module nls_cp437 in 'make menuconfig', I no longer get "ERROR: module 'nls_cp437' not found"

2) The 'Acpid' process IS actually shutting down properly, it's the 'Ahahi-Daemon' process which isn't.

Corrections are made in my first post.

Last edited by ejmarkow (2011-03-31 14:00:09)

ejmarkow · 2011-03-31 14:14:53

@fr33ke:

I found out what's going on with 'mkinitcpio'. Apparently, running the system within kernel 2.6.39-rc1 somehow causes an issue with the root ("/") filesystem, in my case, /dev/sda5.

Try this: Make sure you are currently in your .39 kernel, and run:

# findmnt -n -u -o source /

I get:

"-" (without the quotes)

Now perform a 'dry run' of mkinitcpio within your .39 kernel:

# mkinitcpio -k 2.6.39-rc1-git1-ARCHMOD

I get:

:: Begin dry run
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [autodetect]
ERROR: Root file system type detection failed.
:: Parsing hook [pata]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [filesystems]
:: Generating module dependencies
:: Dry run complete, use -g IMAGE to generate a real image

Kernel .39 seems to be somehow 'breaking' the root filesystem slightly.

If I run the above commands within the .38 stable kernel, everything runs properly, without any errors, and "# findmnt -n -u -o source /" correctly gives "/dev/sda5".

The reason you had no errors in 'mkinitcpio' is because you built the RAM disk image from within the .38 kernel. Again, now try this within the .39 kernel and show your results. Thanks.

Last edited by ejmarkow (2011-03-31 14:15:50)

fr33ke · 2011-03-31 16:47:26

Hi,

regarding avahi-daemon, it fails to start here on 39-rc1 (it seems to run but the fail is just hidden by the -D flag to /usr/sbin/avahi-daemon ).

Process 11419 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid)
Found user 'avahi' (UID 84) and group 'avahi' (GID 84).
Successfully dropped root privileges.
avahi-daemon 0.6.29 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Successfully called chroot().
Successfully dropped remaining capabilities.
Loading service file /services/sftp-ssh.service.
Loading service file /services/ssh.service.
Loading service file /services/udisks.service.
Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.50.105.
New relevant interface wlan0.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for 192.168.50.105 on wlan0.IPv4.
Registering HINFO record with values 'X86_64'/'LINUX'.
on: registering [archmini.local]: server.c:899: dispatch_packet: Assertion `iface > 0' failed.

It doesn't hang on exit though, it just fails. Works fine on 37.

About mkinitcpio, it seems you are right, I have the same results on 39-rc1. It seems something is screwed up with ext4, it recognizes my ext2 /boot and /proc etc.

Last edited by fr33ke (2011-03-31 17:19:35)

fr33ke · 2011-03-31 18:08:50

Diving deeper into the findmnt issue, it seems libmount from util-linux chokes on lines in /proc/self/mountinfo that have optional values that have a "-" (hyphen) in them. See mnt_parse_mountinfo_line in tab_parse.c. Such an optional value was introduced in commit 93f1c20bc8cdb757be50566eff88d65c3b26881f (vfs: Export file system uuid via /proc/<pid>/mountinfo) which is implemented for ext4 (commit f2fa2ffc2046fdc35f96366d1ec8675f4d578522) and ext3 (commit 03cb5f03dcb26846fcad345d8c15aae91579a53d), at least.

edit:

I've reported this bug to both util-linux and linux kernel devs, with you (ejmarkow) in CC.

Last edited by fr33ke (2011-03-31 20:28:52)

ejmarkow · 2011-04-01 08:53:05

Look at a comparison between the .38 & .39 kernels with 'mtab' and 'findmnt'. Notice, with .39, in the 'mtab' file only root ("/") contains "-" and the UUID, however, the 'findmnt' command results in every Ext4 partition containing "-" and the UUID.

Kernel 2.6.38.2:
=========

# cat /etc/mtab
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=248106,mode=755 0 0
/dev/sda5 / ext4 rw,commit=0 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
devpts /dev/pts devpts rw 0 0
shm /dev/shm tmpfs rw,nosuid,nodev 0 0
/dev/sda1 /other ntfs ro,gid=10,umask=7227 0 0
/dev/sda8 /usr ext4 rw,commit=0 0 0
/dev/sda2 /boot ext4 rw,commit=0 0 0
/dev/sda9 /tmp ext4 rw,commit=0 0 0
/dev/sda6 /var ext4 rw,commit=0 0 0
/dev/sda7 /home ext4 rw,commit=0 0 0

# findmnt
TARGET                       SOURCE    FSTYPE   OPTIONS
/                            /dev/sda5 ext4     rw,relatime,barrier=1,data=ordered
├─/proc                      proc      proc     rw,nosuid,nodev,noexec,relatime
├─/sys                       sys       sysfs    rw,nosuid,nodev,noexec,relatime
│ └─/sys/fs/fuse/connections fusectl   fusectl  rw,relatime
├─/dev                       udev      devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=248106,mode=755
│ ├─/dev/pts                 devpts    devpts   rw,relatime,mode=600,ptmxmode=000
│ └─/dev/shm                 shm       tmpfs    rw,nosuid,nodev,relatime
├─/other                     /dev/sda1 ntfs     ro,relatime,uid=0,gid=10,umask=07227,nls=iso8859-1,errors=continue,mft_zone_mu
├─/usr                       /dev/sda8 ext4     rw,relatime,barrier=1,data=ordered
├─/boot                      /dev/sda2 ext4     rw,relatime,barrier=1,data=ordered
├─/tmp                       /dev/sda9 ext4     rw,relatime,barrier=1,data=ordered
├─/var                       /dev/sda6 ext4     rw,relatime,barrier=1,data=ordered
└─/home                      /dev/sda7 ext4     rw,relatime,barrier=1,data=ordered

Kernel 2.6.39-rc1-git1:
=============

# cat /etc/mtab
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=248086,mode=755 0 0
- / 8185-4264-82bc-24011cebf784 rw,commit=0 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
devpts /dev/pts devpts rw 0 0
shm /dev/shm tmpfs rw,nosuid,nodev 0 0
/dev/sda1 /other ntfs ro,gid=10,umask=7227 0 0
/dev/sda8 /usr ext4 rw,commit=0 0 0
/dev/sda2 /boot ext4 rw,commit=0 0 0
/dev/sda9 /tmp ext4 rw,commit=0 0 0
/dev/sda6 /var ext4 rw,commit=0 0 0
/dev/sda7 /home ext4 rw,commit=0 0 0

# findmnt
TARGET                       SOURCE    FSTYPE       OPTIONS
/                            -         8185-4264-82 rw,relatime,ext4
├─/proc                      proc      proc         rw,nosuid,nodev,noexec,relatime
├─/sys                       sys       sysfs        rw,nosuid,nodev,noexec,relatime
│ └─/sys/fs/fuse/connections fusectl   fusectl      rw,relatime
├─/dev                       udev      devtmpfs     rw,nosuid,relatime,size=10240k,nr_inodes=248086,mode=755
│ ├─/dev/pts                 devpts    devpts       rw,relatime,mode=600,ptmxmode=000
│ └─/dev/shm                 shm       tmpfs        rw,nosuid,nodev,relatime
├─/other                     /dev/sda1 ntfs         ro,relatime,uid=0,gid=10,umask=07227,nls=iso8859-1,errors=continue,mft_zon
├─/usr                       -         eff0-4c55-a3 rw,relatime,ext4
├─/boot                      -         c5d9-4735-b0 rw,relatime,ext4
├─/tmp                       -         d423-4efa-bc rw,relatime,ext4
├─/var                       -         1952-4365-9e rw,relatime,ext4
└─/home                      -         50d8-462e-b4 rw,relatime,ext4

Thanks.

Last edited by ejmarkow (2011-04-06 11:20:33)

ejmarkow · 2011-04-06 08:51:23

The Avahi issue has been fixed with the recent release of the "avahi 0.6.30-1" package on 2011-04-05 in the Extra Repository.

fr33ke wrote:

My config is kind of an allmodconfig (with the build fix at https://lkml.org/lkml/2011/3/29/485 ), with a slightly modified PKGBUILD from Kernel Compilation from Source on the archwiki.

Btw, I thoroughly enjoy using Kernel Compilation from Source for New Users on the ArchWiki. It's script based, non-pkgbuild, easy, fast, and works.

Last edited by ejmarkow (2011-04-06 11:34:53)

ejmarkow · 2011-04-13 07:33:27

Just compiled Linux kernel version 2.6.39-rc3-git1 and the 'ext4' filesystem issue has been resolved with the following included kernel patch: Revert "vfs: Export file system uuid via /proc/<pid>/mountinfo"

Revert "vfs: Export file system uuid via /proc/<pid>/mountinfo"
author    Linus Torvalds <torvalds@linux-foundation.org>    
    Tue, 12 Apr 2011 20:35:56 +0000 (13:35 -0700)
committer    Linus Torvalds <torvalds@linux-foundation.org>    
    Tue, 12 Apr 2011 20:35:56 +0000 (13:35 -0700)
commit    be85bccaa5aa5a11dcaf85f9e945ffefd253f631
tree    342a0c1529d077ec499f62dfa01ff4697387f1ab    tree | snapshot
parent    16ad56972ca3161eb97583897f17c1ead0c4ebd0    commit | diff
Revert "vfs: Export file system uuid via /proc/<pid>/mountinfo"

This reverts commit 93f1c20bc8cdb757be50566eff88d65c3b26881f.

It turns out that libmount misparses it because it adds a '-' character
in the uuid string, which libmount then incorrectly confuses with the
separator string (" - ") at the end of all the optional arguments.

Upstream libmount (in the util-linux tree) has been fixed, but until
that fix actually percolates up to users, we'd better not expose this
change in the kernel.

Let's revisit this later (possibly by exposing the UUID without any '-'
characters in it, avoiding the user-space bug).

Reported-by: Dave Jones <davej@redhat.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Karel Zak <kzak@redhat.com>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fs/namespace.c         diff | blob | history
include/linux/fs.h         diff | blob | history

Arch Linux

#1 2011-03-30 15:47:53

[SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

#2 2011-03-30 17:41:37

Re: [SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

#3 2011-03-31 12:28:27

Re: [SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

#4 2011-03-31 14:14:53

Re: [SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

#5 2011-03-31 16:47:26

Re: [SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

#6 2011-03-31 18:08:50

Re: [SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

#7 2011-04-01 08:53:05

Re: [SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

#8 2011-04-06 08:51:23

Re: [SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

#9 2011-04-13 07:33:27

Re: [SOLVED] Some Minor Issues with Kernel 2.6.39-rc1 Compilation

Board footer