[00:50] is it safe to statically allocate 256k bytes in my kernel module? === 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 [19:13] where can i get a CK enabled kernel for 16.04? [19:13] with the BFQ scheduler [19:16] 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:17] Hi :-) [19:19] 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:20] TJ-: Do you prefer a shell inside or outside the chroot? [19:20] DJVG: outside :) [19:28] TJ-, any idea what might cause the problem? [19:28] odd that a kernel fails to install [19:29] cinch: yes, the postinst script is calling the initrd script with incorrect arguments. [19:30] a-ha! [19:33] 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:34] TJ-: I've got the time, no worries! [19:48] TJ-: Took me a while to put this machine in a different vlan and compile dropbear static but it's working now :) [19:49] 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] And ofcourse I monitor haha [19:50] oh cool ill login ;) [19:52] cinch: Seeing anything interesting? ;) [19:52] i see systemd and a debian installer ^.^ [19:54] cinch: Great! ;) Hopefully the kernel devs can figure out later why the installer does not pass the right parameters to update-initramfs [19:54] the kernel sources are unpacked in /usr/src [19:59] I'm back. DJVG you could relay me through a shared tmux if you wanted :) [20:01] 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] TJ-: So it's fine [20:02] TJ-: I had to compile dropbear anyway [20:02] DJVG: I was thinking more along the lines of 'more eyes' [20:02] I thought dropbear was in the repos :) [20:02] TJ-: Maybe it is but I'm sure I had to change my PATH to get the libs etc... [20:03] To be able to run it outside the chroot [20:04] ahhh, yes it is DLed, I thought it was static. Must have been thinking about busybox for initrd [20:04] Right, I'll connect now [20:06] TJ-: 10-4 [20:06] ok, little problem... dropbear seems to be limiting what I can get. no "which" no "chroot" :D [20:07] oh, PATH :) [20:07] Yeah [20:08] I'm in a chroot now, will mess with the installer postinst script now [20:10] TJ-: Go ahead, she's all yours ;) [20:11] interesting! since we generated a good initrd.img it won't fail [20:12] So, some flag is expected to exist but doesn't on first install, breaks it [20:12] TJ-: If you want I can re-run the install to the point it fails and give you access again [20:13] DJVG: I'm just reading the postinst Perl script, see if I can spot anything obvious [20:16] reading perl [20:17] TJ-: Quite funny to see it fails in a virtualbox machine too with the same error [20:17] perl -> deobfuscator -> brain [20:17] going to focus on the core error from the original syslog: "mkinitramfs: failed to determine device for /" [20:19] 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:20] looking at /usr/share/initramfs-tools/hook-functions:386: echo "mkinitramfs: failed to determine device for $dir" >&2 [20:22] let's say i want to log each process that was started (with its command line parameters), how would i go about it [20:23] damn! the UUIDs are different [20:24] see http://paste.ubuntu.com/16481625/ [20:25] TJ-: That's interesting [20:25] and the code in hook-functions:dep_add_modules_mount() relies on the /dev/disk/by-uuid/ symlinks [20:25] which explains why it failed with the error "failed to determine device for /" [20:25] why is the uuid different? [20:26] TJ-: Yes, it was trying to use the old(?) UUID [20:26] TJ-: That's quite weird [20:26] TJ-: Wasn't it refreshed after a mkfs? [20:28] DJVG: there were existing partitions on /dev/sda and you replaced them? [20:28] DJVG: were they the same (3 parts, same size) ? [20:28] 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:30] but whatever, if you repartitioned then partprobe should have been called, and that should have triggered udev to re-do the symlinks [20:30] let me see if there's a hidden udev dlog file [20:36] hmmm, nothing I can find, so that doesn't help. I wonder if there's some clue in syslog though [20:38] when it booted: 17:32:31 kernel: [ 2.576702] sda: sda1 sda2 sda3 [20:39] 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] parts* [20:44] 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:45] 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] that sounds like a scenario that could be reproduced easily, too [20:46] I'll pull in the -server ISO and try it in a VM here [20:47] 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] the bit that has me stumped right now though, is why it now works since the UUIDs are the same [20:47] 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:48] 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] 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:49] TJ-: That's fine, I can keep it up as long as you want :) [20:50] 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] TJ-: If I get disconnected from this you can alway reach me at djvg@djvg.net (pgp: 213FEC83) [20:51] Sure [20:53] so why didnt initrd get its params [20:53] what was the issue, uuids not matching? [20:57] bug 1582899 [20:57] bug 1582899 in base-installer (Ubuntu) "in-target: mkinitramfs: failed to determine device for /" [Undecided,New] https://launchpad.net/bugs/1582899 [21:01] so the installer failed to detect new UUIDs [21:02] well that's udev's job, when a device is added/changed [21:03] kinda obvious bug... could have been easily avoided [21:03] but the reformat didn't repartition so presumably it needs triggering manually to update the UUID link names [21:03] Still got to be able to reproduce it to be sure this is the cause, it's only a hypothesis for now [21:04] 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:05] 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:06] 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:08] DJVG: I'll use the email if it's none public none-bug related [21:08] TJ-: Perfect! [21:09] DJVG: I've added your key to my keyring [21:09] Time for a strong coffee I think :) [21:14] great time for launchpad to start generating errors - can't attach files now [21:15] strong coffee? what timezone, we sleep here [21:17] UK here [21:18] 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:21] cagmz, right, they should have a kernel file descriptor which points to the chacter device [21:21] why does the device need to be referenced, though? does the kernel find the device using the fd given in read(), write(), etc? [21:25] cagmz, because these are file operations against a file, passed file* representst the kernel view of teh file [21:25] that file* is pointed to by the fd numbers given in read/write [21:25] ah!! because the kernel doesn't differentiate between devices and files, right? i keep making them distinct but linux treats them the same [21:26] the are "files" in the strictest sense in the kernel view [21:55] 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] e actual string? [22:00] Why not include all of that in the struct? [22:01] 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:02] It'll need to do copy_from_user() [22:02] You can't directly dereference userspace pointers in the kernel [22:02] 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:03] The kernel will get a pointer [22:03] ah ok, so I would need to use strcpy to store the message in teh struct first, right? [22:03] No [22:05] 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:06] Yes [22:06] That'll work [22:07] But remember that someone could submit a structure with an invalid length [22:07] Don't assume that the length passed in corresponds to the real length of the string [22:07] You'll want to null terminate it yourself before doing anything with it [22:07] Also probably set some upper bound on the size, otherwise someone can DoS you by just allocating huge quantities of kernel memory [22:08] 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:16] mjg59: do you think something like this would work? https://bpaste.net/show/6b4b9ff894e8 can i declare a char * alongside bits in a struct? === JanC is now known as Guest42191 === JanC_ is now known as JanC