| cagmz | is it safe to statically allocate 256k bytes in my kernel module? | 00:50 |
|---|---|---|
| === yuning-afk is now known as yuning | ||
| === Guest11953 is now known as alvesadrian | ||
| === alvesadrian is now known as adrian | ||
| === yuning is now known as yuning-afk | ||
| === mamarley_ is now known as mamarley | ||
| === Guest48104 is now known as adrian | ||
| === tinoco is now known as tinocoff | ||
| === alvesadrian is now known as adrian | ||
| === tinocoff is now known as tinoco | ||
| cinch | where can i get a CK enabled kernel for 16.04? | 19:13 |
| cinch | with the BFQ scheduler | 19:13 |
| TJ- | anyone around? got a sysadmin 'on the line' with a server that is failing to install the kernel package for ubuntu-server 16.04, we're in the /target/ and have managed to narrow it down to a problem with the linux-image-4.4.0-21-generic postinst script | 19:16 |
| DJVG | Hi :-) | 19:17 |
| TJ- | DJVG: now we know we can manually cause the initrd.img to be generated, it makes it possible to remove it and rerun the postinst script with -x and try to capture the error. Let's wait 5 minutes see if apw or timg or someone is interested in this. If you want to set up the ssh shell in the meantime that'd be really useful | 19:19 |
| DJVG | TJ-: Do you prefer a shell inside or outside the chroot? | 19:20 |
| TJ- | DJVG: outside :) | 19:20 |
| cinch | TJ-, any idea what might cause the problem? | 19:28 |
| cinch | odd that a kernel fails to install | 19:28 |
| TJ- | cinch: yes, the postinst script is calling the initrd script with incorrect arguments. | 19:29 |
| cinch | a-ha! | 19:30 |
| TJ- | DJVG: its 20:30 here and I need to go to dinner. I'll return in ~20 minutes if you want to wait around. If not, no worries, I can still write up a bug report although we won't have an identified cause | 19:33 |
| DJVG | TJ-: I've got the time, no worries! | 19:34 |
| DJVG | TJ-: Took me a while to put this machine in a different vlan and compile dropbear static but it's working now :) | 19:48 |
| DJVG | TJ-: You can ssh as root to 91.148.253.252 without a password (I know dangerous but it's a tmp solution) :-) | 19:49 |
| DJVG | And ofcourse I monitor haha | 19:49 |
| cinch | oh cool ill login ;) | 19:50 |
| DJVG | cinch: Seeing anything interesting? ;) | 19:52 |
| cinch | i see systemd and a debian installer ^.^ | 19:52 |
| DJVG | cinch: Great! ;) Hopefully the kernel devs can figure out later why the installer does not pass the right parameters to update-initramfs | 19:54 |
| cinch | the kernel sources are unpacked in /usr/src | 19:54 |
| TJ- | I'm back. DJVG you could relay me through a shared tmux if you wanted :) | 19:59 |
| DJVG | TJ-: Meh, I know, but this way you can do whatever you want. This machine is not in production and has no data on it | 20:01 |
| DJVG | TJ-: So it's fine | 20:01 |
| DJVG | TJ-: I had to compile dropbear anyway | 20:02 |
| TJ- | DJVG: I was thinking more along the lines of 'more eyes' | 20:02 |
| TJ- | I thought dropbear was in the repos :) | 20:02 |
| DJVG | TJ-: Maybe it is but I'm sure I had to change my PATH to get the libs etc... | 20:02 |
| DJVG | To be able to run it outside the chroot | 20:03 |
| TJ- | ahhh, yes it is DLed, I thought it was static. Must have been thinking about busybox for initrd | 20:04 |
| TJ- | Right, I'll connect now | 20:04 |
| DJVG | TJ-: 10-4 | 20:06 |
| TJ- | ok, little problem... dropbear seems to be limiting what I can get. no "which" no "chroot" :D | 20:06 |
| TJ- | oh, PATH :) | 20:07 |
| DJVG | Yeah | 20:07 |
| TJ- | I'm in a chroot now, will mess with the installer postinst script now | 20:08 |
| DJVG | TJ-: Go ahead, she's all yours ;) | 20:10 |
| TJ- | interesting! since we generated a good initrd.img it won't fail | 20:11 |
| TJ- | So, some flag is expected to exist but doesn't on first install, breaks it | 20:12 |
| DJVG | TJ-: If you want I can re-run the install to the point it fails and give you access again | 20:12 |
| TJ- | DJVG: I'm just reading the postinst Perl script, see if I can spot anything obvious | 20:13 |
| cinch | reading perl | 20:16 |
| DJVG | TJ-: Quite funny to see it fails in a virtualbox machine too with the same error | 20:17 |
| cinch | perl -> deobfuscator -> brain | 20:17 |
| TJ- | going to focus on the core error from the original syslog: "mkinitramfs: failed to determine device for /" | 20:17 |
| DJVG | TJ-: I'm getting the idea that there's something wrong with the installer itself. Not sure though, I'm not really into the inner workings of the installer | 20:19 |
| TJ- | looking at /usr/share/initramfs-tools/hook-functions:386: echo "mkinitramfs: failed to determine device for $dir" >&2 | 20:20 |
| cinch | let's say i want to log each process that was started (with its command line parameters), how would i go about it | 20:22 |
| TJ- | damn! the UUIDs are different | 20:23 |
| TJ- | see http://paste.ubuntu.com/16481625/ | 20:24 |
| DJVG | TJ-: That's interesting | 20:25 |
| TJ- | and the code in hook-functions:dep_add_modules_mount() relies on the /dev/disk/by-uuid/ symlinks | 20:25 |
| TJ- | which explains why it failed with the error "failed to determine device for /" | 20:25 |
| cinch | why is the uuid different? | 20:25 |
| DJVG | TJ-: Yes, it was trying to use the old(?) UUID | 20:26 |
| DJVG | TJ-: That's quite weird | 20:26 |
| DJVG | TJ-: Wasn't it refreshed after a mkfs? | 20:26 |
| TJ- | DJVG: there were existing partitions on /dev/sda and you replaced them? | 20:28 |
| TJ- | DJVG: were they the same (3 parts, same size) ? | 20:28 |
| DJVG | TJ-: It might be possible yes, I can't be entirly sure because I tried to install it multiple times and it's possible I didn't re-init the part. table | 20:28 |
| TJ- | but whatever, if you repartitioned then partprobe should have been called, and that should have triggered udev to re-do the symlinks | 20:30 |
| TJ- | let me see if there's a hidden udev dlog file | 20:30 |
| TJ- | hmmm, nothing I can find, so that doesn't help. I wonder if there's some clue in syslog though | 20:36 |
| TJ- | when it booted: 17:32:31 kernel: [ 2.576702] sda: sda1 sda2 sda3 | 20:38 |
| DJVG | TJ-: It's possible that I didn't remove the part. table and only assigned the right mountpoints + mkfs on thos part's | 20:39 |
| DJVG | parts* | 20:39 |
| TJ- | right, but if that's all you did then the UUIDs would be correct. This looks as if there were partitions on sda, udev creates the symlinks, the installer re-partitions and/or re-formats the file-systems in sda1 and sda2 but udev doesn't get informed and therefore the /dev/disk/by-uuid/ symlink names are not updated | 20:44 |
| TJ- | so, when allocating existing partitions/file-systems for mountpoints maybe if you set to 'format' it doesn't cause/trigger the symlinks to be updated | 20:45 |
| TJ- | that sounds like a scenario that could be reproduced easily, too | 20:45 |
| TJ- | I'll pull in the -server ISO and try it in a VM here | 20:46 |
| DJVG | TJ-: Yes, if you want me to do anything let me know. I might need to grab some sleep soon but I can keep this machine running if you want. Again, no important data on that thing | 20:47 |
| TJ- | the bit that has me stumped right now though, is why it now works since the UUIDs are the same | 20:47 |
| TJ- | DJVG: if you could keep it as-is that would be great, I can hopefully pull some more diagnostics off it into a bug report | 20:47 |
| DJVG | TJ-: I don't know how how the installer performs the kernel thing but I can suspect a change in behaviour if you want to run it inside or outside the chroot | 20:48 |
| TJ- | DJVG: and I'll try to reproduce here in a VM too, once its reproducable you can get on with completing the install on that machine :) | 20:48 |
| DJVG | TJ-: That's fine, I can keep it up as long as you want :) | 20:49 |
| TJ- | DJVG: let me open a bug report now and give you the ref. so you can check on progress if you need to go sleep | 20:50 |
| DJVG | TJ-: If I get disconnected from this you can alway reach me at djvg@djvg.net (pgp: 213FEC83) | 20:50 |
| DJVG | Sure | 20:51 |
| cinch | so why didnt initrd get its params | 20:53 |
| cinch | what was the issue, uuids not matching? | 20:53 |
| TJ- | bug 1582899 | 20:57 |
| ubot5 | bug 1582899 in base-installer (Ubuntu) "in-target: mkinitramfs: failed to determine device for /" [Undecided,New] https://launchpad.net/bugs/1582899 | 20:57 |
| cinch | so the installer failed to detect new UUIDs | 21:01 |
| TJ- | well that's udev's job, when a device is added/changed | 21:02 |
| cinch | kinda obvious bug... could have been easily avoided | 21:03 |
| TJ- | but the reformat didn't repartition so presumably it needs triggering manually to update the UUID link names | 21:03 |
| TJ- | Still got to be able to reproduce it to be sure this is the cause, it's only a hypothesis for now | 21:03 |
| TJ- | DJVG: I've copied off syslog and partman and attached them to the bug report. I'll look for other useful logs that might help | 21:04 |
| DJVG | TJ-: Sure, no problem. I'm going to get some rest now. Thanks for all your help and I've subscribed to the bug to keep me posted. Thanks again! | 21:05 |
| DJVG | TJ-: Btw, if you want to le me know something just touch something in /tmp or you can always contact me by e-mail (like if you're done with the server). | 21:06 |
| TJ- | DJVG: I'll use the email if it's none public none-bug related | 21:08 |
| DJVG | TJ-: Perfect! | 21:08 |
| TJ- | DJVG: I've added your key to my keyring | 21:09 |
| TJ- | Time for a strong coffee I think :) | 21:09 |
| TJ- | great time for launchpad to start generating errors - can't attach files now | 21:14 |
| cinch | strong coffee? what timezone, we sleep here | 21:15 |
| TJ- | UK here | 21:17 |
| cagmz | for character device modules, what does the file * in ssize_t (*read) (struct file *, char *, size_t, loff_t *); refer to? i see calls to these methods with an file descriptor to the device file itself | 21:18 |
| apw | cagmz, right, they should have a kernel file descriptor which points to the chacter device | 21:21 |
| cagmz | why does the device need to be referenced, though? does the kernel find the device using the fd given in read(), write(), etc? | 21:21 |
| apw | cagmz, because these are file operations against a file, passed file* representst the kernel view of teh file | 21:25 |
| apw | that file* is pointed to by the fd numbers given in read/write | 21:25 |
| cagmz | ah!! because the kernel doesn't differentiate between devices and files, right? i keep making them distinct but linux treats them the same | 21:25 |
| apw | the are "files" in the strictest sense in the kernel view | 21:26 |
| cagmz | im supposed to be writing a device that reads/write to an internal data structure in the kernel using IOCTL(). so far, I have created a struct that is passed from user space to kernel space with the # of bytes to write, but I also need to pass the actual string to write. would it be ok to use 2 separate ioctl calls? 1 to set the control register for the device (with # of bytes to write), and ioctl() with a pointer to th | 21:55 |
| cagmz | e actual string? | 21:55 |
| mjg59 | Why not include all of that in the struct? | 22:00 |
| cagmz | ah, true! I have a control struct with * of bytes to write/read. I could use a union to store a pointer to the message. but if I do this, will the kernel be able to access the char *? | 22:01 |
| mjg59 | It'll need to do copy_from_user() | 22:02 |
| mjg59 | You can't directly dereference userspace pointers in the kernel | 22:02 |
| cagmz | for example, in user space, i could have char msg[] = "cat". then I do ctrl.data.message = &msg. if I use copy_from_user, will the kernel copy the message or just a pointer to it? | 22:02 |
| mjg59 | The kernel will get a pointer | 22:03 |
| cagmz | ah ok, so I would need to use strcpy to store the message in teh struct first, right? | 22:03 |
| mjg59 | No | 22:03 |
| cagmz | how about passing in ctrl.data.message = &msg, using copy_from_user to copy that whole struct, then using copy_from_user on cmd.data.msg ptr to copy to the module? | 22:05 |
| mjg59 | Yes | 22:06 |
| mjg59 | That'll work | 22:06 |
| mjg59 | But remember that someone could submit a structure with an invalid length | 22:07 |
| mjg59 | Don't assume that the length passed in corresponds to the real length of the string | 22:07 |
| mjg59 | You'll want to null terminate it yourself before doing anything with it | 22:07 |
| mjg59 | Also probably set some upper bound on the size, otherwise someone can DoS you by just allocating huge quantities of kernel memory | 22:07 |
| cagmz | the data structure inside the device is 256k bytes, so I will check that the ctrl.num_bytes < 256k. and while writing to teh device, I will stop before 256k. this is just academic though | 22:08 |
| cagmz | mjg59: do you think something like this would work? https://bpaste.net/show/6b4b9ff894e8 can i declare a char * alongside bits in a struct? | 22:16 |
| === JanC is now known as Guest42191 | ||
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!