You are not logged in.
Pages: 1
Hi,
Will there be a new release of Arch (.8) to handle the switch to udev? Or maybe a pacman-accessible program to make all the changes? I realize that there is a wiki page about it but a lot of people won't be able to implement the change properly.
Oh yeah, how close is it to happening??
Jim
Offline
why does there need to be a program to do this? it's what, two files to change... here's your howto:
add devfs=nomount to the kernel boot parameters
change /etc/fstab from /dev/discs/discX/partY to /dev/hdZ or /dev/sdZOffline
Hi Phrakture
There's a section of the wiki that deals with the kernel hanging when booting. At that point most people with a low to middle linux knowledge will be stumped.
Just trying to suggest a way to minimize the support headaches. That's all.
![]()
Offline
ok, well if the kernel hangs, I'll deal with that on a case by case basis....
People get so upset about this switch to udev which isn't hard at all
Offline
I think the wiki makes it sound harder than it is... back when that was written, the switch to udev was tough, but now its pretty simple. I do add one change to phrakture's howto: edit lilo.conf/grub.1st to use the proper root device.
Dusty
Offline
i have not had any problems at all switching, did exactly what phrature and dusty alrerady said, (but looong before
)
no problems here at all
http://www.linuxportalen.com -> Linux Help portal for Linux and ArchLinux (in swedish)
Dell Inspiron 8500
Kernel 2.6.14-archck1 (selfcompiled)
Enlightenment 17
Offline
Hi Phrakture
There's a section of the wiki that deals with the kernel hanging when booting. At that point most people with a low to middle linux knowledge will be stumped.
Just trying to suggest a way to minimize the support headaches. That's all.
That would be a difficult fix to automate. You could make a rescue floppy that did it for you, but even then, different partition information would either have to be supplied, or do an auto-search for the partitions. Pretty easy to bung the whole thing up at that point. Not to mention the different filesystem types might make the kernel too big for anything other than a CD.
best to print out the howto and stick it beside your monitor.
Offline
Hello,
I switched to udev without any problems but I don't exactly understand what udev does.
I read that I have to change /dev/discs* to /dev/hd* in fstab but I haven't done this and it works anyway
Could someone please explaine how udev is related with the naming of /dev/*? I currently have both hda and the discs stuff in /dev?
Also I use k3b to burn and konqueror to browse media, I know the usb stuff is handled automatic (usbfs does this) does this also happen for cd stations?
This is my cd line in fstab, do I need that one?
/dev/hdc /mnt/cd iso9660 ro,user,noauto,unhide 0 0
Also I commented the line for tmpfs, does this mean arch is currently using my swap partition? (which I want it to do)
I hope you don't mind me asking all these question in this thread, thanks in advance
david
edit: I forgot one question
Judd wrote that devfs will leave the kernel, does that mean that the line devfs=nomount will not be needed anymore in the future?
Offline
edit: I forgot one question
Judd wrote that devfs will leave the kernel, does that mean that the line devfs=nomount will not be needed anymore in the future?
Once arch starts shipping kernels that don't support both devfs and udev, then yes.
Offline
I switched to udev without any problems but I don't exactly understand what udev does.
Exhaustive detail here - make a cup of cocoa and take it to bed.
I read that I have to change /dev/discs* to /dev/hd* in fstab but I haven't done this and it works anyway
Arch's udev implementation includes default rules that replicate the devfs device naming conventions, for compatibility purposes. I would still recommend changing to /dev/hd* etc as in a little while there will be no need for that compatibility.
Could someone please explaine how udev is related with the naming of /dev/*? I currently have both hda and the discs stuff in /dev?
It's in the pdf (I think - never actually read it myself....)
devfs will leave the kernel, does that mean that the line devfs=nomount will not be needed anymore in the future?
Yes.
The best way to understand it is to use it - try writing some rules.
Offline
For Phrakture;
The quote below is from a post by Gullible Jones where I had a problem with the latest kernel. Maybe the wiki needs to be updated??
Jim
Quote;
Oh... I got the same problem when I upgraded to that kernel...
Apparently, it has to do with DevFS being phased out. Here's how to solve it: before rebooting, open up /boot/grub/menu.lst and change the path specified in "root=foo" so that it uses the static /dev path instead of the DevFS path. For example, root=/dev/discs/disc0/part1 would be changed to /dev/hda1.
Offline
For Phrakture;
The quote below is from a post by Gullible Jones where I had a problem with the latest kernel. Maybe the wiki needs to be updated??
Jim
Quote;
Oh... I got the same problem when I upgraded to that kernel...Apparently, it has to do with DevFS being phased out. Here's how to solve it: before rebooting, open up /boot/grub/menu.lst and change the path specified in "root=foo" so that it uses the static /dev path instead of the DevFS path. For example, root=/dev/discs/disc0/part1 would be changed to /dev/hda1.
Um yeah... read my Dusty's ammendment to my "howto" - I forgot about grub/lilo.
Offline
I also had no trouble switching to udev. If I can do it first try without breaking anything, than anyone can.
Offline
I also had no trouble switching to udev. If I can do it first try without breaking anything, than anyone can.
Well, I'm about ready to put that to the test. I'm so messed up that I can't get Enemy Territory to run under a normal user. I think that it is either alsa- oss permission errors, or my user can't use the HW acceleration of my nvidia card. Either way, I'm hoping udev and the rules fix that.
And I thought I knew linux...
Offline
I also had no trouble switching to udev. If I can do it first try without breaking anything, than anyone can.
Even Mr. Green, do you suppose?
8) 8) 8)
Dusty
Offline
I thought switching to udev was really easy too until I compililed devfs out of the kernel. Then I had a hanging boot related to my sound modules (emu-10k1). I tried everything I could think of. In the end I got it working although I still don't know for sure what it was that actually did it. It was all very strange.
Offline
Thanks TheDoctor and tomk for explaining more about udev. I read the pdf and I know now how the naming of /dev is related to udev.
Also I removed all lines out fstab that have to do with the cd station and browsing the cd with konqueror and burning with k3b still works! The program fstab-sync added a line for the dvd-burner automatic
Cheers,
David
Offline
I got udev working fine but I had issues with the wrong root device in grub - i guess i was probably one of the first and that was ages ago!
I've never been clear which one dev naming scheme is related to which.
My old distro used /dev/hda - and cos it was old and not bleeding edge I assumed that was the devfs way but it seems not and the /dev/discs is actually the devs fs way and i now need to use all /dev/hd* stuff with udev - is that right?
Offline
@dibble
yes that's right, kernels compiled without devfs don't recognise /dev/discs/' naming scheme so you "must use /dev/hdx scheme in you bootmanagers conf,
arch + gentoo + initng + python = enlisy
Offline
The switch from devfs to udev went seamlessly for me. I put more time reading the wiki page and understanding what was going on, and preparing for the worst-case scenario, than actually changing over to udev. Now I can attach over 4000 hard discs to my machine
But the problem that I was trying to resolve with udev is still there (Enemy territory only running as root, failing for user logons). I've ruled out a permission problem, and it seems to be an alsa/kde problem. Time for more reading.
Offline
The program fstab-sync added a line for the dvd-burner automatic
$ pacman -Qo /usr/sbin/fstab-sync
/usr/sbin/fstab-sync is owned by hal 0.5.2-3That's hal working for you David, not udev - very handy alright.
My old distro used /dev/hda - and cos it was old and not bleeding edge I assumed that was the devfs way but it seems not and the /dev/discs is actually the devs fs way and i now need to use all /dev/hd* stuff with udev - is that right?
Before udev, before devfs, there was static dev, although nobody called it that back then - it was (and still is) the /dev directory - here's a small excerpt from the one on my Debian server:
$ ls /dev/hd*
/dev/hda /dev/hda2 /dev/hdb11 /dev/hdb4 /dev/hdc14 /dev/hdc7 /dev/hdd17 /dev/hde /dev/hde2 /dev/hdf11 /dev/hdf4 /dev/hdg14 /dev/hdg7 /dev/hdh17
/dev/hda1 /dev/hda20 /dev/hdb12 /dev/hdb5 /dev/hdc15 /dev/hdc8 /dev/hdd18 /dev/hde1 /dev/hde20 /dev/hdf12 /dev/hdf5 /dev/hdg15 /dev/hdg8 /dev/hdh18
/dev/hda10 /dev/hda3 /dev/hdb13 /dev/hdb6 /dev/hdc16 /dev/hdc9 /dev/hdd19 /dev/hde10 /dev/hde3 /dev/hdf13 /dev/hdf6 /dev/hdg16 /dev/hdg9 /dev/hdh19
/dev/hda11 /dev/hda4 /dev/hdb14 /dev/hdb7 /dev/hdc17 /dev/hdd /dev/hdd2 /dev/hde11 /dev/hde4 /dev/hdf14 /dev/hdf7 /dev/hdg17 /dev/hdh /dev/hdh2
/dev/hda12 /dev/hda5 /dev/hdb15 /dev/hdb8 /dev/hdc18 /dev/hdd1 /dev/hdd20 /dev/hde12 /dev/hde5 /dev/hdf15 /dev/hdf8 /dev/hdg18 /dev/hdh1 /dev/hdh20
/dev/hda13 /dev/hda6 /dev/hdb16 /dev/hdb9 /dev/hdc19 /dev/hdd10 /dev/hdd3 /dev/hde13 /dev/hde6 /dev/hdf16 /dev/hdf9 /dev/hdg19 /dev/hdh10 /dev/hdh3
/dev/hda14 /dev/hda7 /dev/hdb17 /dev/hdc /dev/hdc2 /dev/hdd11 /dev/hdd4 /dev/hde14 /dev/hde7 /dev/hdf17 /dev/hdg /dev/hdg2 /dev/hdh11 /dev/hdh4
/dev/hda15 /dev/hda8 /dev/hdb18 /dev/hdc1 /dev/hdc20 /dev/hdd12 /dev/hdd5 /dev/hde15 /dev/hde8 /dev/hdf18 /dev/hdg1 /dev/hdg20 /dev/hdh12 /dev/hdh5
/dev/hda16 /dev/hda9 /dev/hdb19 /dev/hdc10 /dev/hdc3 /dev/hdd13 /dev/hdd6 /dev/hde16 /dev/hde9 /dev/hdf19 /dev/hdg10 /dev/hdg3 /dev/hdh13 /dev/hdh6
/dev/hda17 /dev/hdb /dev/hdb2 /dev/hdc11 /dev/hdc4 /dev/hdd14 /dev/hdd7 /dev/hde17 /dev/hdf /dev/hdf2 /dev/hdg11 /dev/hdg4 /dev/hdh14 /dev/hdh7
/dev/hda18 /dev/hdb1 /dev/hdb20 /dev/hdc12 /dev/hdc5 /dev/hdd15 /dev/hdd8 /dev/hde18 /dev/hdf1 /dev/hdf20 /dev/hdg12 /dev/hdg5 /dev/hdh15 /dev/hdh8
/dev/hda19 /dev/hdb10 /dev/hdb3 /dev/hdc13 /dev/hdc6 /dev/hdd16 /dev/hdd9 /dev/hde19 /dev/hdf10 /dev/hdf3 /dev/hdg13 /dev/hdg6 /dev/hdh16 /dev/hdh9Only hda and hdb actually exist.......
Offline
Only hda and hdb actually exist.......
Ahh, those were the days. "Hey, to install your new hardware, just recompile the kernel, mknod the dev entries if they don't already exist, shutdown, install the hardware, power up, dmesg to see if the device installed correctly, then google to see why it didn't install correctly. Three easy steps!"
Assuming you didn't hose your system with mknod...
Offline
I think the reason there are 1404 (yes, really) entries in my /dev is to try and avoid the use of mknod. Murphy's law applies, of course
By way of comparison, my laptop's /dev has 93 devices, courtesy of udev.
Offline
I think the reason there are 1404 (yes, really) entries in my /dev is to try and avoid the use of mknod. Murphy's law applies, of course
![]()
By way of comparison, my laptop's /dev has 93 devices, courtesy of udev.
Yep, most distros that use /dev try to create the devices so the end user doesn't have to. That means that the hardware is supported up to the release of the distro, and it's up to the distro to guess what hardware will be in the system. If you were running an old release and new hardware came out, then you'd have to mknod or makedev yourself. It's not a big deal to do it, but in the old UNIX days, you'd have to do it quite a bit. There are horror stories about admins creating discs with the same major/minor numbers that were already in the system and hosing the boot disk. Also, with Linux, the major device numbers were in a state of flux for the bleeding edge stuff, and if you were reading old documentation, then you'd be pulling your hair out figuring out lockups, kernel panics, module errors, and whatnot.
Offline
Pages: 1