You are not logged in.
Arch still boots fine, I'm just wondering why this comes up:
:: Waiting for UDev events to be processed
udev[196]: error opening ATTR{/sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sda/sda3/queue/rotational} for writing: No such file or directory
udev[197]: error opening ATTR{/sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sda/sda4/queue/rotational} for writing: No such file or directory
udev[193]: error opening ATTR{/sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sda/sda1/queue/rotational} for writing: No such file or directory
Only other place I've found something like this is on a Red Hat bug report for Fedora.
Last edited by YAOMTC (2011-12-20 06:45:34)
Offline
What kind of disk is your /dev/sda ?
Offline
What kind of disk is your /dev/sda ?
It's the main storage of my Eee PC 900. I think it uses flash memory rather than an SSD like a newer one might.
Offline
It does not make much sense to write to that file, so that is a bit weird for starters. Could you check that you don't have any leftover udev rules in /etc/udev/rules.d ? If there is nothing there, then try "grep rotational /lib/udev/rules.d/*".
If nothing there either please paste the output of
udevadm info -n /dev/sda1 -a
Offline
$ grep rotational /lib/udev/rules.d/*
/lib/udev/rules.d/61-eee-ssd.rules:# ensure our SSD drive is set up as non-rotational
/lib/udev/rules.d/61-eee-ssd.rules:ACTION=="add" SUBSYSTEM=="block", SUBSYSTEMS=="pci", ATTRS{subsystem_vendor}=="0x1043", ATTRS{subsystem_device}=="0x82d8", ATTR{queue/rotational}="0"
/lib/udev/rules.d/61-eee-ssd.rules:ACTION=="add" SUBSYSTEM=="block", SUBSYSTEMS=="pci", ATTRS{subsystem_vendor}=="0x1043", ATTRS{subsystem_device}=="0x830f", ATTR{queue/rotational}="0"
Thought I'd go ahead and try this too:
Offline
Ok, so that rule (61-eee-ssd.rules) does not make much sense. Where does it come from? You should file a bug report against that package. This can be safely ignored I think.
Offline
What package are we talking about here?
Offline
Don't know, never seen such files before. `pacman -Qo /lib/udev/rules.d/61-eee-ssd.rules` will tell you.
Offline
Oh, kernel-eee. I'm not sure I even ever used that. I'm also not sure whether it's kernel-eee-lts or kernel-eeepc-901 (probably the former since mine is a 900)... Oh well, it's been removed. Thanks!
EDIT: This solved the problem, the error is now gone.
Now all I have left to do is figure out why mtab / mounting local filesystem fails. Which doesn't seem to impact anything either. I looked at my fstab and it looks alright...
EDIT(2): Wait, why is there a swap? I never set that up... I disabled swap. Hm... Okay, I removed that line, and now mtab doesn't fail, though "Mounting Local Filesystems" still does. Oh well, no big deal.
Last edited by YAOMTC (2011-12-17 19:14:43)
Offline
What do you mean "mtab failed"? Are you using the latest initscripts from testing? If "mounting local filesystems" fails that sounds like bad news...
Offline
What do you mean "mtab failed"? Are you using the latest initscripts from testing? If "mounting local filesystems" fails that sounds like bad news...
I mean when I'm booting, and it's listing the status of each part of the startup process.
:: Adjusting system time and setting kernel timezone [DONE]
:: Starting UDev Daemon [DONE]
:: Triggering UDev uevents [DONE]
:: Loading User-specified Modules [DONE]
:: Waiting for UDev uevents to be processed [DONE]
:: Bringing up loopback interface [DONE]
:: Checking Filesystems [DONE]
:: Remounting Root Read/Write [DONE]
:: Creating mtab [DONE]
:: Mounting Local Filesystems [FAIL]
:: Activating Swap [DONE]
and so on. Come to think of it, before I removed the swap line from fstab today, the "Activating Swap" line was always [FAIL], but now it says [DONE]. That's weird, 'cause I'm sure I disabled swap on install...
Anyway, I haven't noticed any filesystem problems. I just figured I'd fix whatever's "broken", though it doesn't seem to be affecting anything.
Offline
tomegun wrote:What do you mean "mtab failed"? Are you using the latest initscripts from testing? If "mounting local filesystems" fails that sounds like bad news...
I mean when I'm booting, and it's listing the status of each part of the startup process.
:: Adjusting system time and setting kernel timezone [DONE] :: Starting UDev Daemon [DONE] :: Triggering UDev uevents [DONE] :: Loading User-specified Modules [DONE] :: Waiting for UDev uevents to be processed [DONE] :: Bringing up loopback interface [DONE] :: Checking Filesystems [DONE] :: Remounting Root Read/Write [DONE] :: Creating mtab [DONE] :: Mounting Local Filesystems [FAIL] :: Activating Swap [DONE]
and so on. Come to think of it, before I removed the swap line from fstab today, the "Activating Swap" line was always [FAIL], but now it says [DONE]. That's weird, 'cause I'm sure I disabled swap on install...
Anyway, I haven't noticed any filesystem problems. I just figured I'd fix whatever's "broken", though it doesn't seem to be affecting anything.
Ah, now it is clear. I was stupidly looking at the wrong release of initscripts (in the most recent one we no longer have the "Creating mtab" line).
The swap stuff makes sense: you disabled it, but there was still that stray line in your fstab, so when initscripts tried to enable it it did not work (as your /dev/sda2 was not a swap partition). Now there is no line in fstab, so enabling nothing succeeds ;-)
It is odd that mounting local filesystems fails. Could you check that all your filesystems are indeed mounted (with findmnt), and if not tell me the result of "mount -a"? If everything is indeed mounted then please check if the most recent initscripts still gives the failure on boot, in that case this is a false negative that we should somehow figure out...
Offline
It is odd that mounting local filesystems fails. Could you check that all your filesystems are indeed mounted (with findmnt), and if not tell me the result of "mount -a"? If everything is indeed mounted then please check if the most recent initscripts still gives the failure on boot, in that case this is a false negative that we should somehow figure out...
$ findmnt
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda3 ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered
├─/proc proc proc rw,nosuid,nodev,noexec,relatime
├─/sys /sys sysfs rw,nosuid,nodev,noexec,relatime
├─/dev udev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=127204,mode=755
│ ├─/dev/pts devpts rw,relatime,mode=600,ptmxmode=000
│ └─/dev/shm tmpfs rw,relatime
│ └─/dev/shm tmpfs rw,relatime
├─/run /run tmpfs rw,nosuid,nodev,relatime,size=10240k,mode=755
├─/boot /dev/sda1 ext2 rw,relatime,errors=continue
└─/home /dev/sda4 ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered
└─/home/chris/.gvfs gvfs-fuse-daemon fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
Don't see anything wrong there, do you?
Not sure what file I look at for the initscripts... /etc/rc.sysinit?
Offline
Looks all good. If there is a mistake it would be in rc.sysinit (or possibly /etc/rc.d/functions). If you notice any more weirdness, please let me know, but otherwise don't worry...
Offline
Looks all good. If there is a mistake it would be in rc.sysinit (or possibly /etc/rc.d/functions). If you notice any more weirdness, please let me know, but otherwise don't worry...
Relevant sections from rc.sysinit:
# mount /proc, /sys, /run, /dev, /run/lock, /dev/pts, /dev/shm (the api filesystems)
mountpoint -q /proc || mount -n -t proc proc /proc -o nosuid,noexec,nodev
mountpoint -q /sys || mount -n -t sysfs sys /sys -o nosuid,noexec,nodev
mountpoint -q /run || mount -n -t tmpfs run /run -o mode=0755,nosuid,nodev
mountpoint -q /dev || mount -n -t devtmpfs udev /dev -o mode=0755,nosuid ||
mount -n -t tmpfs udev /dev -o mode=0755,nosuid
mkdir -p -m 1777 /run/lock
mkdir -p /dev/{pts,shm}
mountpoint -q /dev/pts || mount -n /dev/pts &>/dev/null ||
mount -n -t devpts devpts /dev/pts -o mode=0620,gid=5,nosuid,noexec
mountpoint -q /dev/shm || mount -n /dev/shm &>/dev/null ||
mount -n -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev
if [[ ! -e /run/initramfs/fsck-root ]]; then
# remount root ro to allow for fsck later on, we remount now to
# make sure nothing can open files rw on root which would block a remount
findmnt / --options ro &>/dev/null ||
status "Mounting Root Read-Only" mount -n -o remount,ro /
fi
run_hook sysinit_premount
status "Mounting Local Filesystems" \
mount_all
run_hook sysinit_postmount
from functions:
mount_all() {
mount -a -t "nosysfs,no${NETFS//,/,no}" -O no_netdev
}
I'm not worried, seeing as I've had no filesystem problems. I'm just thinking it'd be best to have everything go just the way it should, so as to be more efficient or clean or something.
Last edited by YAOMTC (2011-12-20 03:01:50)
Offline
$ findmnt TARGET SOURCE FSTYPE OPTIONS / /dev/sda3 ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered ├─/proc proc proc rw,nosuid,nodev,noexec,relatime ├─/sys /sys sysfs rw,nosuid,nodev,noexec,relatime ├─/dev udev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=127204,mode=755 │ ├─/dev/pts devpts rw,relatime,mode=600,ptmxmode=000 │ └─/dev/shm tmpfs rw,relatime │ └─/dev/shm tmpfs rw,relatime ├─/run /run tmpfs rw,nosuid,nodev,relatime,size=10240k,mode=755 ├─/boot /dev/sda1 ext2 rw,relatime,errors=continue └─/home /dev/sda4 ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered └─/home/chris/.gvfs gvfs-fuse-daemon fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
Don't see anything wrong there, do you?
Are you sure that this is OK?
TARGET SOURCE FSTYPE OPTIONS
.
.
├─/dev udev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=127204,mode=755
│ ├─/dev/pts devpts rw,relatime,mode=600,ptmxmode=000
│ └─/dev/shm tmpfs rw,relatime
│ └─/dev/shm tmpfs rw,relatime
.
.
On my machine the output is the same apart from the /dev/shm reference to /dev/shm
Offline
Actually, the problem is gone now. Not sure what did it -- I did just today uninstall clyde, install packer, and did a full sync and upgrade, so I suppose one of those updates must have done it.
Offline
Right, you might want to remove the /dev/shm and /dev/pts entries as these are done automatically by rc.initscripts :-)
Offline