| === Cale [n=cale@CPE004854805910-CM000e5cdd834a.cpe.net.cable.rogers.com] has joined #upstart | ||
| Cale | Hi, how do I get upstart to display what it is doing as it does it, during bootup and shutdown? I'd just like to be made aware of what's actually happening as it goes on. | 01:43 |
|---|---|---|
| Cale | The little progress bar is cute, but it's not really all that informative. | 01:45 |
| Cale | (I'm using Edgy) | 01:47 |
| _ion | less /var/log/boot | 02:00 |
| Cale | yeah, how do I get that printed as the machine is actually booting? | 02:01 |
| _ion | Probably by adding 'console output' to /etc/event.d files that contain 'exec /etc/init.d/rc...' | 02:03 |
| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === Cale [n=cale@CPE004854805910-CM000e5cdd834a.cpe.net.cable.rogers.com] has left #upstart ["Leaving"] | ||
| === hunger [n=tobias@pd95b0676.dip0.t-ipconnect.de] has joined #upstart | ||
| === nibil [n=nibil@adsl-static-3-105.uklinux.net] has joined #upstart | ||
| === juergbi [n=juerg@80-219-26-249.dclient.hispeed.ch] has joined #upstart | ||
| === johnnybuoy [n=johnny@unaffiliated/johnnybuoy] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Md_ [i=md@freenode/staff/md] has joined #upstart | ||
| === Md_ is now known as Md | ||
| === jc-denton [n=nils@ztnw648.ztl.ch] has joined #upstart | ||
| jc-denton | hi all | 11:18 |
| jc-denton | i have the strange problem that / is sometimes suddenly mounted read only | 11:19 |
| jc-denton | and i cannout mount it rw with -o remount | 11:19 |
| jc-denton | also / is uncommented in /etc/fstab | 11:19 |
| jc-denton | why? | 11:19 |
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| johnnybuoy | why is commented? | 01:15 |
| Keybuk | commented? | 01:25 |
| jc-denton | yes | 01:49 |
| jc-denton | http://rafb.net/paste/results/9TtK1412.html | 01:50 |
| Keybuk | I don't understand? | 01:51 |
| jc-denton | # /dev/hda1 UUID=2232ef2d-5684-429b-8618-d31a881e55ab / ext3 defaults,errors=remount-ro 0 1 | 01:51 |
| jc-denton | it's commented out | 01:51 |
| Keybuk | you've edited the file and pressed "j" on that line, then saved it | 01:51 |
| Keybuk | (in vi) | 01:52 |
| jc-denton | no | 01:52 |
| Keybuk | or edited it in some other editor, and joined the two lines, however you did that | 01:52 |
| jc-denton | i did a fresh install of edgy | 01:52 |
| jc-denton | and did nothing with /etc/fstab until i got trouble | 01:52 |
| Keybuk | "until you got into trouble" ? | 01:52 |
| jc-denton | however i installed it when rc2 was out | 01:52 |
| jc-denton | it was suddenly mounted read only | 01:52 |
| Keybuk | so you edited /etc/fstab | 01:53 |
| Keybuk | and broke it | 01:53 |
| jc-denton | the lin break is just there because i copied that thing | 01:53 |
| jc-denton | look i also checked it out on some other edgy installtion | 01:53 |
| Keybuk | all I'm hearing here is "it was working fine until I broke it" | 01:53 |
| Keybuk | if the edgy system booted the first time, then the file must have been correct on first installation | 01:54 |
| Keybuk | (and, btw, this has nothing to do with upstart) | 01:54 |
| === johnnybuoy [n=johnny@unaffiliated/johnnybuoy] has joined #upstart | ||
| === Amaranth_ [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| jc-denton | ok | 02:27 |
| jc-denton | so is /etc/fstab generated by something | 02:27 |
| jc-denton | or can i simply edit it by hand | 02:27 |
| jc-denton | and also what is this UUID? | 02:27 |
| Keybuk | generated by the installer, but then edited by hand | 02:30 |
| Keybuk | the UUID is the UUID of the filesystem you want to mount | 02:30 |
| Keybuk | you can get it with "vol_id", e.g. "vol_id /dev/hda1" | 02:30 |
| === johnnybuoy [n=johnny@unaffiliated/johnnybuoy] has joined #upstart | ||
| === johnnybuoy [n=johnny@unaffiliated/johnnybuoy] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| jc-denton | Keybuk: thx so far.. | 03:37 |
| jc-denton | humm | 03:48 |
| jc-denton | but mount doesn't get these UUIDs | 03:48 |
| jc-denton | so what does edgy use to mount it | 03:49 |
| Keybuk | mount | 03:50 |
| jc-denton | if i remove the # at the beginning | 03:58 |
| jc-denton | and type mount -a | 03:58 |
| Keybuk | then you'll get an invalid /etc/fstab | 03:58 |
| jc-denton | yes | 03:58 |
| jc-denton | so it cannot be mounted by mount | 03:58 |
| Keybuk | # /dev/hda1 | 03:59 |
| Keybuk | UUID=2232ef2d-5684-429b-8618-d31a881e55ab / ext3 defaults,errors=remount-ro 0 1 | 03:59 |
| jc-denton | maybe i need to ask different | 03:59 |
| Keybuk | # /dev/hda2 | 03:59 |
| jc-denton | what reads these lines? | 03:59 |
| Keybuk | UUID=ab2da10b-b58d-4f52-9291-2c39391e9996 none swap sw 0 0 | 03:59 |
| Keybuk | is what that should look like | 03:59 |
| Keybuk | jc-denton: mount. | 03:59 |
| Keybuk | the problem isn't that there's a "#" before "/dev/hda1" | 04:00 |
| Keybuk | the problem is that you've joined that line ("# /dev/hda1" with the line that should appear below it "UUID=..../...ext3..." etc.) | 04:00 |
| jc-denton | now i'm completely confused | 04:01 |
| Keybuk | evidently | 04:01 |
| jc-denton | http://rafb.net/paste/results/9TtK1412.html | 04:01 |
| jc-denton | so the line for /dev/hda2 is correct | 04:01 |
| wasabi_ | Am I the only one who doesn't really like UUIDs? | 04:01 |
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| jc-denton | but the one for /dev/hda1 not | 04:01 |
| Keybuk | jc-denton: the TWO LINES for /dev/hda2 are correct | 04:01 |
| Keybuk | wasabi_: what would you prefer? | 04:01 |
| jc-denton | ok | 04:01 |
| Keybuk | jc-denton: the fact there's only one line for /dev/hda1 is what's wrong | 04:02 |
| wasabi_ | Keybuk: Unfortunatly I have no answer to that. Probably static device names. ;0 | 04:02 |
| jc-denton | but | 04:02 |
| Keybuk | jc-denton: tip: make it look like the /dev/hda2 TWO LINES | 04:02 |
| Keybuk | wasabi_: device names aren't static | 04:02 |
| jc-denton | that's not how the syntax for /etc/fstab is defined | 04:02 |
| Keybuk | jc-denton: yes it is | 04:02 |
| wasabi_ | Why shouldn't they be though? | 04:02 |
| wasabi_ | My problem with UUIDs is they ignore some odd corner cases. | 04:02 |
| wasabi_ | Such as md1 vols. | 04:02 |
| Keybuk | wasabi_: because part of the name is a number, which implies enumeration of devices, which implies a fixed device set | 04:03 |
| _ion | wasabi: If we want everything to just work with static device names, the device names must contain some kind of a UUID. :-) | 04:03 |
| wasabi_ | but they don't just ignore it in a way as to make it not work, it continues to work, wrong. | 04:03 |
| Keybuk | wasabi_: hmm? md volumes contain an equivalent to a UUID or LABEL which can be used to mount them | 04:03 |
| wasabi_ | Sure... I guess my main complaint is that the UUIDs come from the FS itself. | 04:03 |
| wasabi_ | Which may actually have multiple paths to reach it. | 04:03 |
| Keybuk | wasabi_: multiple paths is irrelevant, multiple views is the problem there | 04:03 |
| jc-denton | hrmm | 04:04 |
| wasabi_ | Sure? You've got the underlying md device... which is mountable! | 04:04 |
| wasabi_ | But you should never mount it. | 04:04 |
| jc-denton | UUID=asdfasdf is a device or what | 04:04 |
| Keybuk | wasabi: what decides that one md is 0 and the other is 1 ? | 04:04 |
| jc-denton | and what i would like to know | 04:04 |
| jc-denton | is this documented somewhere | 04:04 |
| wasabi_ | Keybuk: Hmm? | 04:04 |
| Keybuk | jc-denton: yes | 04:04 |
| Keybuk | jc-denton: yes | 04:04 |
| Keybuk | wasabi_: well, if you're going to rely on something which is md0 and something which is md1 | 04:05 |
| Keybuk | wasabi_: what decides which is 0 and which is 1? :) | 04:05 |
| wasabi_ | Well, either way, it's a problem. When edgy switched to UUIDs, I couldn't boot. With my weird ass md + lvm + evms setup. :0 | 04:05 |
| Keybuk | wasabi_: we mucked up md/lvm/evms because the developer who's supposed to care about that is a lazy idiot | 04:05 |
| Keybuk | ;) | 04:05 |
| wasabi_ | Keybuk: I'd name the md device statically based on the ID of the *md device* | 04:05 |
| wasabi_ | not of the FS on it. | 04:05 |
| Keybuk | wasabi_: right, where's that ID stored? | 04:05 |
| wasabi_ | In the MD metadata hopefully. | 04:06 |
| jc-denton | Keybuk: i did man fstab | 04:06 |
| wasabi_ | Which is unviewbale unless the md vol is composed. | 04:06 |
| Keybuk | wasabi_: so that should be picked up, and placed in /dev/disk/by-id ? | 04:06 |
| jc-denton | and there is still the page from 2004 | 04:06 |
| jc-denton | Keybuk: where? | 04:06 |
| Keybuk | jc-denton: yes... fstab has supposed mounting by UUID or LABEL for a long time | 04:06 |
| _ion | wasabi: If you're using LVM, why use UUIDs instead of /dev/vgname-lvname? They already have a unique, static identifier. | 04:07 |
| wasabi_ | Maybe I'm mis understanding something. Where *does* the uuid come from? | 04:07 |
| Keybuk | wasabi_: make sure you're subscribed to the udev-* specs for MTV :p | 04:07 |
| wasabi_ | _ion: Mostly because it forced me too. ;) | 04:07 |
| Keybuk | wasabi_: the filesystem/device/block device/container/whatever's appropriate | 04:07 |
| wasabi_ | I have subscribed. | 04:07 |
| wasabi_ | Hmm. | 04:07 |
| === mbiebl [n=michael@e180101102.adsl.alicedsl.de] has joined #upstart | ||
| wasabi_ | I guess that's maybe my core question. | 04:07 |
| wasabi_ | In my case, where does the uuid come from. | 04:07 |
| wasabi_ | The FS, the container, etc? | 04:07 |
| Keybuk | wasabi_: right now, errrr | 04:07 |
| Keybuk | ls -l /dev/disk/by-id | 04:07 |
| Keybuk | sorry | 04:08 |
| wasabi_ | At some point in the past it came from the FS, because I had two, that conflicted. | 04:08 |
| Keybuk | ls -l /dev/disk/by-uuid | 04:08 |
| wasabi_ | And it mounted the wrong one. | 04:08 |
| wasabi_ | Looking in /dev/disk/bu-uuid looks right now. | 04:08 |
| wasabi_ | only one pointer to md1, no pointers to it's underlying devices. | 04:08 |
| Keybuk | you had two, identical, Universally UNIQUE Ids? :p | 04:08 |
| wasabi_ | Yes. Two paths to the same file system. | 04:08 |
| wasabi_ | It's was a MIRROR | 04:08 |
| Keybuk | right | 04:08 |
| wasabi_ | MD metadata is at the end. | 04:08 |
| wasabi_ | The underlying devices are still usable. | 04:09 |
| Keybuk | so the MD itself should have an ID different to any of its exposed filesystems | 04:09 |
| Keybuk | e.g. | 04:09 |
| Keybuk | MD = abcdef, composed of two disks | 04:09 |
| jc-denton | Keybuk: ok | 04:09 |
| Keybuk | hda1 = 123456 | 04:09 |
| Keybuk | hda2 = 123456 | 04:09 |
| jc-denton | but this is the first time i see that | 04:09 |
| Keybuk | you'd mount root=UUID=abcdef | 04:09 |
| wasabi_ | In the past, it wasn't like that. | 04:09 |
| jc-denton | is that linux only? | 04:09 |
| Keybuk | jc-denton: yes | 04:09 |
| wasabi_ | Keybuk: In the past, I had UUID=12345, which was valid for 3 different devices... /dev/sda3, /dev/sdb3, and /dev/md0 | 04:09 |
| Keybuk | unless, of course, there's a way to tell by just looking at hda1 that it's part of an MD | 04:09 |
| wasabi_ | And I guess the link was whatever the last one detected was. ;) | 04:10 |
| Keybuk | (without having yet composed the MD) | 04:10 |
| wasabi_ | Or first one? | 04:10 |
| wasabi_ | Also, I use XFS, which does have it's own UUID. | 04:10 |
| wasabi_ | Maybe it decided to use that. | 04:10 |
| Keybuk | this is precisely what we need to discuss at MTV, and understand how it fits together | 04:10 |
| wasabi_ | It looks fine now though. ;) | 04:10 |
| Keybuk | and then make sure it works | 04:10 |
| wasabi_ | Yeah. | 04:10 |
| jc-denton | ok i think i got it | 04:10 |
| jc-denton | thanks so far for the infos | 04:10 |
| jc-denton | but it should be mentioned somewhere | 04:10 |
| jc-denton | does edgy has release notes or so | 04:10 |
| Keybuk | jc-denton: it is mentioned, in many places | 04:10 |
| wasabi_ | It made no UUIDs to my evms devices at all though | 04:11 |
| jc-denton | but i could not find it | 04:11 |
| wasabi_ | But it did overwrite fstab to use uuids. | 04:11 |
| Keybuk | wasabi_: yeah, we don't migrate MD, EVMS, LVM, etc. because we took the safety approach | 04:11 |
| Keybuk | jc-denton: it's in the man page for fstab! | 04:11 |
| wasabi_ | Heh. You did migrate them. ;) | 04:11 |
| Keybuk | wasabi_: at first, yes | 04:11 |
| wasabi_ | "oops" | 04:11 |
| Keybuk | then we decided that it was a bad idea given we didn't understand them | 04:11 |
| jc-denton | ah ok | 04:12 |
| jc-denton | :) | 04:12 |
| wasabi_ | Well, to be clear, I don't mind UUIDs in the sense that I believe using a universally unique id is the right approach. | 04:12 |
| wasabi_ | I just know I was burned a few times during the migration. | 04:12 |
| Keybuk | sure | 04:12 |
| wasabi_ | Shit. I'm a MS guy. I'm used to GUIDs all over the place. | 04:12 |
| jc-denton | This will make the system more robust: adding or removing a SCSI disk changes the disk device name but not the filesystem volume label. | 04:12 |
| Keybuk | that's cause we don't understand LVM, EVMS, MD, etc. | 04:12 |
| jc-denton | ah ok | 04:13 |
| wasabi_ | Can't wait to talk about em. :0 | 04:13 |
| Keybuk | we have specs to understand them, write it down, and then fix it :p | 04:13 |
| jc-denton | so that ensures that another disk is not mounted on a specified mount point | 04:13 |
| wasabi_ | I do some crazy shit with md/lvm/evms. I'd love to see that crazy shit supportable. | 04:13 |
| Keybuk | jc-denton: and, more pointedly, it makes your system robust against installing (for example) another controller card | 04:13 |
| Keybuk | it should be | 04:13 |
| Keybuk | from what I understand, we basically just need to make sure | 04:13 |
| Keybuk | a) uevents are generated | 04:13 |
| Keybuk | b) which uevents mean we need to run certain tools | 04:14 |
| Keybuk | c) how to obtain a unique identifier for the fs/container/device/wibble | 04:14 |
| _ion | jc-denton: Also, in (maybe not so) distant future, the kernel may switch to the libata PATA implementation. Then hd* will change to sd*. | 04:14 |
| Keybuk | _ion: RSN | 04:15 |
| Keybuk | I believe it was merged into 2.6.19 | 04:15 |
| _ion | Ok, cool. | 04:15 |
| _ion | The edgy kernel already uses libata for PATA disks connected to my SATA+PATA controller. | 04:16 |
| wasabi_ | I guess the trick is figuring out which information from which devices to seed a uuid with. | 04:16 |
| wasabi_ | For a md device, it should be the md metadata of the composed vol. | 04:16 |
| wasabi_ | evms, it should be the evms metadata of the composed volume. | 04:17 |
| wasabi_ | etc etc | 04:17 |
| wasabi_ | Which is interesting because you can't actually obtain the MD metadata by looking at the md device itself. | 04:19 |
| === mbiebl [n=michael@e180101102.adsl.alicedsl.de] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === Jameson1234 [n=napkin@ip503c00d9.speed.planet.nl] has joined #upstart | ||
| === Jameson1234 [n=napkin@ip503c00d9.speed.planet.nl] has joined #upstart | ||
| hunger | Keybuk: Things get interesting with encrypted devices I think. | 05:52 |
| hunger | Keybuk: block device comes up -> need to check whether it contains files for loopback -> those turn into new block devs -> get mapped to yet another blockdev -> that needs to get mounted. | 05:52 |
| Keybuk | this is easy :) | 05:58 |
| Keybuk | it's a nice logical sequence of events | 05:59 |
| wasabi_ | Keybuk: I have some questions about UMV. Curious how this plays out. These specs are driving out schedules and stuff right? | 06:14 |
| wasabi_ | What do we all just end up in a room at a certain time sitting around a table? | 06:15 |
| wasabi_ | And then the guy who registered the specs speaks up or something? | 06:16 |
| === phsdv [n=kvirc@83.152.239.207] has joined #upstart | ||
| === johnnybuoy [n=johnny@unaffiliated/johnnybuoy] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === Md_ [i=md@freenode/staff/md] has joined #upstart | ||
| === Md_ is now known as Md | ||
| === phsdv [n=kvirc@83.152.239.207] has left #upstart ["So] | ||
| === mbiebl [n=michael@e180101102.adsl.alicedsl.de] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!